1. 09 5月, 2009 1 次提交
    • H
      x86, boot: align the .bss section in the decompressor · 0b4eb462
      H. Peter Anvin 提交于
      Aligning the .bss section makes it trivial to use large operation
      sizes for moving the initialized sections and clearing the .bss.
      The alignment chosen (L1 cache) is somewhat arbitrary, but should be
      large enough to avoid all known performance traps and small enough to
      not cause troubles.
      
      [ Impact: trivial performance enhancement, future patch prep	]
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      0b4eb462
  2. 30 4月, 2009 1 次提交
  3. 27 4月, 2009 1 次提交
    • L
      x86: unify arch/x86/boot/compressed/vmlinux_*.lds · 51b26ada
      Linus Torvalds 提交于
      Look at the:
      
      	diff -u arch/x86/boot/compressed/vmlinux_*.lds
      
      output and realize that they're basially exactly the same except for
      trivial naming differences, and the fact that the 64-bit version has a
      "pgtable" thing.
      
      So unify them.
      
      There's some trivial cleanup there (make the output format a Kconfig thing
      rather than doing #ifdef's for it, and unify both 32-bit and 64-bit BSS
      end to "_ebss", where 32-bit used to use the traditional "_end"), but
      other than that it's really very mindless and straigt conversion.
      
      For example, I think we should aim to remove "startup_32" vs "startup_64",
      and just call it "startup", and get rid of one more difference. I didn't
      do that.
      
      Also, notice the comment in the unified vmlinux.lds.S talks about
      "head_64" and "startup_32" which is an odd and incorrect mix, but that was
      actually what the old 64-bit only lds file had, so the confusion isn't
      new, and now that mixing is arguably more accurate thanks to the
      vmlinux.lds.S file being shared between the two cases ;)
      
      [ Impact: cleanup, unification ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      51b26ada
  4. 20 4月, 2008 1 次提交
  5. 02 2月, 2008 1 次提交
  6. 30 1月, 2008 2 次提交
  7. 11 10月, 2007 2 次提交
  8. 03 5月, 2007 1 次提交
    • V
      [PATCH] x86-64: Relocatable Kernel Support · 1ab60e0f
      Vivek Goyal 提交于
      This patch modifies the x86_64 kernel so that it can be loaded and run
      at any 2M aligned address, below 512G.  The technique used is to
      compile the decompressor with -fPIC and modify it so the decompressor
      is fully relocatable.  For the main kernel the page tables are
      modified so the kernel remains at the same virtual address.  In
      addition a variable phys_base is kept that holds the physical address
      the kernel is loaded at.  __pa_symbol is modified to add that when
      we take the address of a kernel symbol.
      
      When loaded with a normal bootloader the decompressor will decompress
      the kernel to 2M and it will run there.  This both ensures the
      relocation code is always working, and makes it easier to use 2M
      pages for the kernel and the cpu.
      
      AK: changed to not make RELOCATABLE default in Kconfig
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      1ab60e0f
  9. 07 12月, 2006 1 次提交
    • E
      [PATCH] i386: Relocatable kernel support · 968de4f0
      Eric W. Biederman 提交于
      This patch modifies the i386 kernel so that if CONFIG_RELOCATABLE is
      selected it will be able to be loaded at any 4K aligned address below
      1G.  The technique used is to compile the decompressor with -fPIC and
      modify it so the decompressor is fully relocatable.  For the main
      kernel relocations are generated.  Resulting in a kernel that is relocatable
      with no runtime overhead and no need to modify the source code.
      
      A reserved 32bit word in the parameters has been assigned
      to serve as a stack so we figure out where are running.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      968de4f0