1. 16 9月, 2008 2 次提交
    • P
      powerpc: Make the 64-bit kernel as a position-independent executable · 549e8152
      Paul Mackerras 提交于
      This implements CONFIG_RELOCATABLE for 64-bit by making the kernel as
      a position-independent executable (PIE) when it is set.  This involves
      processing the dynamic relocations in the image in the early stages of
      booting, even if the kernel is being run at the address it is linked at,
      since the linker does not necessarily fill in words in the image for
      which there are dynamic relocations.  (In fact the linker does fill in
      such words for 64-bit executables, though not for 32-bit executables,
      so in principle we could avoid calling relocate() entirely when we're
      running a 64-bit kernel at the linked address.)
      
      The dynamic relocations are processed by a new function relocate(addr),
      where the addr parameter is the virtual address where the image will be
      run.  In fact we call it twice; once before calling prom_init, and again
      when starting the main kernel.  This means that reloc_offset() returns
      0 in prom_init (since it has been relocated to the address it is running
      at), which necessitated a few adjustments.
      
      This also changes __va and __pa to use an equivalent definition that is
      simpler.  With the relocatable kernel, PAGE_OFFSET and MEMORY_START are
      constants (for 64-bit) whereas PHYSICAL_START is a variable (and
      KERNELBASE ideally should be too, but isn't yet).
      
      With this, relocatable kernels still copy themselves down to physical
      address 0 and run there.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      549e8152
    • C
      powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels · cf00085d
      Chandru 提交于
      Kdump kernel needs to use only those memory regions that it is allowed
      to use (crashkernel, rtas, tce, etc.).  Each of these regions have
      their own sizes and are currently added under 'linux,usable-memory'
      property under each memory@xxx node of the device tree.
      
      The ibm,dynamic-memory property of ibm,dynamic-reconfiguration-memory
      node (on POWER6) now stores in it the representation for most of the
      logical memory blocks with the size of each memory block being a
      constant (lmb_size).  If one or more or part of the above mentioned
      regions lie under one of the lmb from ibm,dynamic-memory property,
      there is a need to identify those regions within the given lmb.
      
      This makes the kernel recognize a new 'linux,drconf-usable-memory'
      property added by kexec-tools.  Each entry in this property is of the
      form of a count followed by that many (base, size) pairs for the above
      mentioned regions.  The number of cells in the count value is given by
      the #size-cells property of the root node.
      Signed-off-by: NChandru Siddalingappa <chandru@in.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cf00085d
  2. 01 7月, 2008 1 次提交
  3. 24 4月, 2008 1 次提交
    • K
      [POWERPC] 85xx: Add support for relocatable kernel (and booting at non-zero) · 37dd2bad
      Kumar Gala 提交于
      Added support to allow an 85xx kernel to be run from a non-zero physical
      address (useful for cooperative asymmetric multiprocessing situations and
      kdump).  The support can be configured at compile time by setting
      CONFIG_PAGE_OFFSET, CONFIG_KERNEL_START, and CONFIG_PHYSICAL_START as
      desired.
      
      Alternatively, the kernel build can set CONFIG_RELOCATABLE.  Setting this
      config option causes the kernel to determine at runtime the physical
      addresses of CONFIG_PAGE_OFFSET and CONFIG_KERNEL_START.  If
      CONFIG_RELOCATABLE is set, then CONFIG_PHYSICAL_START has no meaning.
      However, CONFIG_PHYSICAL_START will always be used to set the LOAD program
      header physical address field in the resulting ELF image.
      
      Currently we are limited to running at a physical address that is a
      multiple of 256M.  This is due to how we map TLBs to cover
      lowmem.  This should be fixed to allow 64M or maybe even 16M alignment
      in the future.  It is considered an error to try and run a kernel at a
      non-aligned physical address.
      
      All the magic for this support is accomplished by proper initialization
      of the kernel memory subsystem and use of ARCH_PFN_OFFSET.
      
      The use of ARCH_PFN_OFFSET only affects normal memory and not IO mappings.
      ioremap uses map_page and isn't affected by ARCH_PFN_OFFSET.
      
      /dev/mem continues to allow access to any physical address in the system
      regardless of how CONFIG_PHYSICAL_START is set.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      37dd2bad
  4. 18 4月, 2008 1 次提交
    • B
      [POWERPC] Fix device-tree locking vs. interrupts · f4ac7b5e
      Benjamin Herrenschmidt 提交于
      Lockdep found out that we can occasionally take the device-tree
      lock for reading from softirq time (from rtas_token called
      by the rtas real time clock code called by the NTP code),
      while we take it occasionally for writing without masking
      interrupts. The combination of those two can thus deadlock.
      
      While some of those cases of interrupt read lock could be fixed
      (such as caching the RTAS tokens) I figured that taking the
      lock for writing is so rare (device-tree modification) that we
      may as well penalize that case and allow reading from interrupts.
      
      Thus, this turns all the writers to take the lock with irqs
      masked to avoid the situation.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f4ac7b5e
  5. 17 4月, 2008 1 次提交
    • M
      [POWERPC] pseries/phyp dump: Reserve a variable amount of space at boot · 37ddd5d0
      Manish Ahuja 提交于
      This changes the way we calculate how much space to reserve for the
      pHyp dump.  Currently we reserve 256MB only.  With this change, the
      code first checks to see if an amount has been specified on the boot
      command line with the "phyp_dump_reserve_size" option, and if so, uses
      that much.
      
      Otherwise it computes 5% of total ram and rounds it down to a multiple
      of 256MB, and uses the larger of that or 256MB.
      
      This is for large systems with a lot of memory (10GB or more).  The
      aim is to have more space available for the kernel on reboot on
      machines with more resources.  Although the dump will be collected
      pretty fast and the memory released really early on allowing the
      machine to have the full memory available, this alleviates any issues
      that can be caused by having way too little memory on very very large
      systems during those few minutes.
      Signed-off-by: NManish Ahuja <mahuja@us.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      37ddd5d0
  6. 01 4月, 2008 1 次提交
  7. 26 3月, 2008 2 次提交
  8. 20 2月, 2008 1 次提交
  9. 14 2月, 2008 1 次提交
  10. 24 12月, 2007 1 次提交
  11. 11 12月, 2007 1 次提交
  12. 01 11月, 2007 1 次提交
    • V
      [POWERPC] 4xx: Workaround for the 440EP(x)/GR(x) processors identical PVR issue. · d1dfc35d
      Valentine Barshak 提交于
      PowerPC 440EP(x) 440GR(x) processors have the same PVR values, since
      they have identical cores. However, FPU is not supported on GR(x) and
      enabling APU instruction broadcast in the CCR0 register (to enable FPU)
      may cause unpredictable results. There's no safe way to detect FPU
      support at runtime. This patch provides a workarund for the issue.
      
      We use a POWER6 "logical PVR approach". First, we identify all EP(x)
      and GR(x) processors as GR(x) ones (which is safe). Then we check
      the device tree cpu path. If we have a EP(x) processor entry,
      we call identify_cpu again with PVR | 0x8. This bit is always 0
      in the real PVR. This way we enable FPU only for 440EP(x).
      Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      d1dfc35d
  13. 09 10月, 2007 1 次提交
    • P
      [POWERPC] Use cache-inhibited large page bit from firmware · 84fdde5a
      Paul Mackerras 提交于
      Discussions with firmware architects have confirmed that the bit in
      the ibm,pa-features property that indicates support for
      cache-inhibited large (>= 64kB) page mappings does in fact mean that
      the hypervisor allows 64kB mappings to I/O devices.
      
      Thus we can now enable the code that tests that bit and sets our
      CPU_FTR_CI_LARGE_PAGE feature bit.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      84fdde5a
  14. 13 9月, 2007 2 次提交
  15. 17 8月, 2007 1 次提交
  16. 22 7月, 2007 1 次提交
  17. 20 7月, 2007 6 次提交
  18. 10 7月, 2007 5 次提交
  19. 28 6月, 2007 1 次提交
  20. 02 6月, 2007 1 次提交
  21. 17 5月, 2007 1 次提交
  22. 10 5月, 2007 1 次提交
  23. 24 4月, 2007 5 次提交
  24. 13 4月, 2007 1 次提交