1. 17 Apr, 2008 35 commits
  2. 16 Apr, 2008 5 commits
    • Manish Ahuja's avatar
      [POWERPC] pseries/phyp dump: Reserve a variable amount of space at boot · 37ddd5d0
      Manish Ahuja authored
      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: default avatarManish Ahuja <mahuja@us.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      37ddd5d0
    • Kumar Gala's avatar
      [POWERPC] Cleanup pgtable-ppc32.h · af892e0f
      Kumar Gala authored
      * Removed defines KERNEL_PGD_PTRS & USER_PGD_PTRS since they aren't
        used anywhere
      * Changed pmd_page macro to use pfn_to_page so we get proper behavior
        if ARCH_PFN_OFFSET is set as well if we use a different memory model
        on ppc32.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      af892e0f
    • Kumar Gala's avatar
      [POWERPC] bootwrapper: Use physical address in PHDR for uImage · b18796d3
      Kumar Gala authored
      Now that we properly set the physical address in the program header of the
      vmlinux ELF we can extract it to properly set the load and entry point for
      u-boot uImages.  Before we always hard coded the load & entry point to 0.
      However there are situations that the kernel may be built with a non-zero
      physical address.
      
      We use objdump to extract the PHDR.  We assume that there is only one
      PHDR in the vmlinux of type LOAD.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      b18796d3
    • Kumar Gala's avatar
      [POWERPC] Update linker script to properly set physical addresses · 366234f6
      Kumar Gala authored
      We can set LOAD_OFFSET and use the AT attribute on sections and the
      linker will properly set the physical address of the LOAD program
      header for us.
      
      This allows us to know how the PHYSICAL_START the user configured a
      kernel with by just looking at the resulting vmlinux ELF.
      
      This is pretty much stolen from how x86 does things in their linker
      scripts.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      366234f6
    • Kumar Gala's avatar
      [POWERPC] Move phys_addr_t definition into asm/types.h · d04ceb3f
      Kumar Gala authored
      Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in
      places that before would have caused recursive includes.
      
      For example to use phys_addr_t in <asm/page.h> we would have included
      <asm/mmu.h> which would have possibly included <asm/mmu-hash64.h> which
      includes <asm/page.h>.  Wheeee recursive include.
      
      CONFIG_PHYS_64BIT is a bit counterintuitive in light of ppc64 systems
      and thus the config option is only used for ppc32 systems with >32-bit
      physical addresses (44x, 85xx, 745x, etc.).
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      d04ceb3f