1. 24 7月, 2013 1 次提交
  2. 26 4月, 2013 3 次提交
  3. 13 3月, 2013 1 次提交
    • A
      powerpc: Fix -mcmodel=medium breakage in prom_init.c · 1674400a
      Anton Blanchard 提交于
      Commit 5ac47f7a (powerpc: Relocate prom_init.c on 64bit) made
      prom_init.c position independent by manually relocating its entries
      in the TOC.
      
      We get the address of the TOC entries with the __prom_init_toc_start
      linker symbol. If __prom_init_toc_start ends up as an entry in the
      TOC then we need to add an offset to get the current address. This is
      the case for older toolchains.
      
      On the other hand, if we have a newer toolchain that supports
      -mcmodel=medium then __prom_init_toc_start will be created by a
      relative offset from r2 (the TOC pointer). Since r2 has already been
      relocated, nothing more needs to be done.  Adding an offset in this
      case is wrong and Aaro Koskinen and Alexander Graf have noticed noticed
      G5 and OpenBIOS breakage.
      
      Alan Modra suggested we just use r2 to get at the TOC which is simpler
      and works with both old and new toolchains.
      Reported-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1674400a
  4. 10 1月, 2013 2 次提交
    • A
      powerpc: Remove RELOC() macro · 5827d416
      Anton Blanchard 提交于
      Now we relocate prom_init.c on 64bit we can finally remove the
      nasty RELOC() macro.
      
      Finally a patch that I can claim has a net positive effect on
      the kernel. It doesn't happen very often.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5827d416
    • A
      powerpc: Relocate prom_init.c on 64bit · 5ac47f7a
      Anton Blanchard 提交于
      The ppc64 kernel can get loaded at any address which means
      our very early init code in prom_init.c must be relocatable. We do
      this with a pretty nasty RELOC() macro that we wrap accesses of
      variables with. It is very fragile and sometimes we forget to add a
      RELOC() to an uncommon path or sometimes a compiler change breaks it.
      
      32bit has a much more elegant solution where we build prom_init.c
      with -mrelocatable and then process the relocations manually.
      Unfortunately we can't do the equivalent on 64bit and we would
      have to build the entire kernel relocatable (-pie), resulting in a
      large increase in kernel footprint (megabytes of relocation data).
      The relocation data will be marked __initdata but it still creates
      more pressure on our already tight memory layout at boot.
      
      Alan Modra pointed out that the 64bit ABI is relocatable even
      if we don't build with -pie, we just need to relocate the TOC.
      This patch implements that idea and relocates the TOC entries of
      prom_init.c. An added bonus is there are very few relocations to
      process which helps keep boot times on simulators down.
      
      gcc does not put 64bit integer constants into the TOC but to be
      safe we may want a build time script which passes through the
      prom_init.c TOC entries to make sure everything looks reasonable.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      5ac47f7a
  5. 15 11月, 2012 1 次提交
  6. 05 9月, 2012 1 次提交
  7. 23 8月, 2012 1 次提交
  8. 01 8月, 2012 1 次提交
  9. 29 6月, 2012 1 次提交
  10. 16 5月, 2012 1 次提交
  11. 14 5月, 2012 2 次提交
  12. 29 3月, 2012 1 次提交
  13. 28 3月, 2012 1 次提交
  14. 07 3月, 2012 1 次提交
    • N
      powerpc/prom: Remove limit on maximum size of properties · e9daf2ad
      Nishanth Aravamudan 提交于
      On a 16TB system (using AMS/CMO), I get:
      
      WARNING: ignoring large property [/ibm,dynamic-reconfiguration-memory] ibm,dynamic-memory length 0x000000000017ffec
      
      and significantly less memory is thus shown to the partition. As far as
      I can tell, the constant used is arbitrary. Ben Herrenschmidt provided
      additional background that
      
      > The limit was originally set because of Apple machines carrying ROM
      > images in the device-tree, at a time where we were much more memory
      > constrained than we are now.
      
      and that it is likely not very useful any longer.
      Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e9daf2ad
  15. 20 12月, 2011 1 次提交
    • S
      powerpc: Rename mapping based RELOCATABLE to DYNAMIC_MEMSTART for BookE · 0f890c8d
      Suzuki Poulose 提交于
      The current implementation of CONFIG_RELOCATABLE in BookE is based
      on mapping the page aligned kernel load address to KERNELBASE. This
      approach however is not enough for platforms, where the TLB page size
      is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used
      currently in BookE to DYNAMIC_MEMSTART to reflect the actual method.
      
      The CONFIG_RELOCATABLE for PPC32(BookE) based on processing of the
      dynamic relocations will be introduced in the later in the patch series.
      
      This change would allow the use of the old method of RELOCATABLE for
      platforms which can afford to enforce the page alignment (platforms with
      smaller TLB size).
      
      Changes since v3:
      
      * Introduced a new config, NONSTATIC_KERNEL, to denote a kernel which is
        either a RELOCATABLE or DYNAMIC_MEMSTART(Suggested by: Josh Boyer)
      Suggested-by: NScott Wood <scottwood@freescale.com>
      Tested-by: NScott Wood <scottwood@freescale.com>
      Signed-off-by: NSuzuki K. Poulose <suzuki@in.ibm.com>
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: linux ppc dev <linuxppc-dev@lists.ozlabs.org>
      Signed-off-by: NJosh Boyer <jwboyer@gmail.com>
      0f890c8d
  16. 19 12月, 2011 2 次提交
  17. 08 12月, 2011 1 次提交
  18. 07 12月, 2011 1 次提交
  19. 16 11月, 2011 1 次提交
  20. 29 9月, 2011 1 次提交
  21. 20 9月, 2011 3 次提交
  22. 05 8月, 2011 2 次提交
  23. 04 5月, 2011 1 次提交
  24. 20 4月, 2011 1 次提交
  25. 31 7月, 2010 1 次提交
  26. 08 7月, 2010 1 次提交
  27. 28 4月, 2010 1 次提交
    • A
      powerpc/numa: Add form 1 NUMA affinity · 4b83c330
      Anton Blanchard 提交于
      Firmware changed the way it represents memory and cpu affinity on POWER7.
      Unfortunately the old method now caps the topology to work around issues
      with legacy operating systems. For Linux to get the correct topology we
      need to use the new form 1 affinity information.
      
      We set the form 1 field in the client architecture, and if we see "1" in the
      ibm,associativity-form property firmware supports form 1 affinity and
      we should look at the first field in the ibm,associativity-reference-points
      array. If not we use the second field as we always have.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      4b83c330
  28. 04 2月, 2010 1 次提交
  29. 03 2月, 2010 1 次提交
  30. 24 9月, 2009 1 次提交
    • A
      powerpc: Fix ibm,client-architecture-support printout · 049d0497
      Anton Blanchard 提交于
      On machines without the ibm,client-architecture-support call we were missing a
      newline. We may as well print the full name in all its glory too - its
      ibm,client-architecture-support, not ibm,client-architecture as I mistakenly
      wrote (a name only an IBM architect could love).
      
      For my penance I will write out ibm,client-architecture-support 100 times.
      
      Before:
      
      Calling ibm,client-architecture...command line: root=/dev/sda6 console=hvc0  quiet
      
      After:
      
      Calling ibm,client-architecture-support... not implemented
      command line: root=/dev/sda6 console=hvc0
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      049d0497
  31. 20 8月, 2009 2 次提交