Skip to content
  1. Jul 21, 2012
  2. Jun 01, 2012
  3. May 19, 2012
    • H. Peter Anvin's avatar
      x86, realmode: 16-bit real-mode code support for relocs tool · 6520fe55
      H. Peter Anvin authored
      
      
      A new option is added to the relocs tool called '--realmode'.
      This option causes the generation of 16-bit segment relocations
      and 32-bit linear relocations for the real-mode code. When
      the real-mode code is moved to the low-memory during kernel
      initialization, these relocation entries can be used to
      relocate the code properly.
      
      In the assembly code 16-bit segment relocations must be relative
      to the 'real_mode_seg' absolute symbol. Linear relocations must be
      relative to a symbol prefixed with 'pa_'.
      
      16-bit segment relocation is used to load cs:ip in 16-bit code.
      Linear relocations are used in the 32-bit code for relocatable
      data references. They are declared in the linker script of the
      real-mode code.
      
      The relocs tool is moved to arch/x86/tools/relocs.c, and added new
      target archscripts that can be used to build scripts needed building
      an architecture.  be compiled before building the arch/x86 tree.
      
      [ hpa: accelerating this because it detects invalid absolute
        relocations, a serious bug in binutils 2.22.52.0.x which currently
        produces bad kernels. ]
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.com
      
      
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      6520fe55
  4. May 08, 2012
  5. Apr 30, 2012
  6. Apr 16, 2012
  7. Mar 26, 2012
  8. Mar 16, 2012
  9. Feb 28, 2012
  10. Jan 26, 2012
  11. Dec 16, 2011
  12. Dec 12, 2011
    • Matt Fleming's avatar
      x86, efi: EFI boot stub support · 291f3632
      Matt Fleming authored
      
      
      There is currently a large divide between kernel development and the
      development of EFI boot loaders. The idea behind this patch is to give
      the kernel developers full control over the EFI boot process. As
      H. Peter Anvin put it,
      
      "The 'kernel carries its own stub' approach been very successful in
      dealing with BIOS, and would make a lot of sense to me for EFI as
      well."
      
      This patch introduces an EFI boot stub that allows an x86 bzImage to
      be loaded and executed by EFI firmware. The bzImage appears to the
      firmware as an EFI application. Luckily there are enough free bits
      within the bzImage header so that it can masquerade as an EFI
      application, thereby coercing the EFI firmware into loading it and
      jumping to its entry point. The beauty of this masquerading approach
      is that both BIOS and EFI boot loaders can still load and run the same
      bzImage, thereby allowing a single kernel image to work in any boot
      environment.
      
      The EFI boot stub supports multiple initrds, but they must exist on
      the same partition as the bzImage. Command-line arguments for the
      kernel can be appended after the bzImage name when run from the EFI
      shell, e.g.
      
      Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
      
      v7:
       - Fix checkpatch warnings.
      
      v6:
      
       - Try to allocate initrd memory just below hdr->inird_addr_max.
      
      v5:
      
       - load_options_size is UTF-16, which needs dividing by 2 to convert
         to the corresponding ASCII size.
      
      v4:
      
       - Don't read more than image->load_options_size
      
      v3:
      
       - Fix following warnings when compiling CONFIG_EFI_STUB=n
      
         arch/x86/boot/tools/build.c: In function ‘main’:
         arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
         arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
      
       - As reported by Matthew Garrett, some Apple machines have GOPs that
         don't have hardware attached. We need to weed these out by
         searching for ones that handle the PCIIO protocol.
      
       - Don't allocate memory if no initrds are on cmdline
       - Don't trust image->load_options_size
      
      Maarten Lankhorst noted:
       - Don't strip first argument when booted from efibootmgr
       - Don't allocate too much memory for cmdline
       - Don't update cmdline_size, the kernel considers it read-only
       - Don't accept '\n' for initrd names
      
      v2:
      
       - File alignment was too large, was 8192 should be 512. Reported by
         Maarten Lankhorst on LKML.
       - Added UGA support for graphics
       - Use VIDEO_TYPE_EFI instead of hard-coded number.
       - Move linelength assignment until after we've assigned depth
       - Dynamically fill out AddressOfEntryPoint in tools/build.c
       - Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
       - The bzImage may need to be relocated as it may have been loaded at
         a high address address by the firmware. This was required to get my
         macbook booting because the firmware loaded it at 0x7cxxxxxx, which
         triggers this error in decompress_kernel(),
      
      	if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
      		error("Destination address too large");
      
      Cc: Mike Waychison <mikew@google.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Tested-by: default avatarHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
      
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      291f3632
  13. Mar 02, 2011
  14. Jan 13, 2011
    • Lasse Collin's avatar
      x86: support XZ-compressed kernel · 30314804
      Lasse Collin authored
      
      
      This integrates the XZ decompression code to the x86 pre-boot code.
      
      mkpiggy.c is updated to reserve about 32 KiB more buffer safety margin for
      kernel decompression.  It is done unconditionally for all decompressors to
      keep the code simpler.
      
      The XZ decompressor needs around 30 KiB of heap, so the heap size is
      increased to 32 KiB on both x86-32 and x86-64.
      
      Documentation/x86/boot.txt is updated to list the XZ magic number.
      
      With the x86 BCJ filter in XZ, XZ-compressed x86 kernel tends to be a few
      percent smaller than the equivalent LZMA-compressed kernel.
      
      Signed-off-by: default avatarLasse Collin <lasse.collin@tukaani.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alain Knaff <alain@knaff.lu>
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      30314804
  15. Dec 17, 2010
  16. Nov 10, 2010
  17. Oct 08, 2010
    • Zhao Yakui's avatar
      x86, setup: Use string copy operation to optimze copy in kernel compression · 68f4d5a0
      Zhao Yakui authored
      
      
      The kernel decompression code parses the ELF header and then copies
      the segment to the corresponding destination.  Currently it uses slow
      byte-copy code.  This patch makes it use the string copy operations
      instead.
      
      In the test the copy performance can be improved very significantly after using
      the string copy operation mechanism.
              1. The copy time can be reduced from 150ms to 20ms on one Atom machine
      	2. The copy time can be reduced about 80% on another machine
      		The time is reduced from 7ms to 1.5ms when using 32-bit kernel.
      		The time is reduced from 10ms to 2ms when using 64-bit kernel.
      
      Signed-off-by: default avatarZhao Yakui <yakui.zhao@intel.com>
      LKML-Reference: <1286502453-7043-1-git-send-email-yakui.zhao@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      68f4d5a0
  18. Aug 03, 2010
  19. Aug 02, 2010
  20. May 26, 2010
    • Linus Torvalds's avatar
      Revert "endian: #define __BYTE_ORDER" · 13da9e20
      Linus Torvalds authored
      
      
      This reverts commit b3b77c8c, which was
      also totally broken (see commit 0d2daf5c that reverted the crc32
      version of it).  As reported by Stephen Rothwell, it causes problems on
      big-endian machines:
      
      > In file included from fs/jfs/jfs_types.h:33,
      >                  from fs/jfs/jfs_incore.h:26,
      >                  from fs/jfs/file.c:22:
      > fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined
      
      The kernel has never had that crazy "__BYTE_ORDER == __LITTLE_ENDIAN"
      model.  It's not how we do things, and it isn't how we _should_ do
      things.  So don't go there.
      
      Requested-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      13da9e20
  21. May 25, 2010
  22. Mar 03, 2010
  23. Feb 19, 2010
  24. Feb 05, 2010
  25. Jan 11, 2010
  26. Dec 25, 2009
    • H. Peter Anvin's avatar
      x86, compress: Force i386 instructions for the decompressor · 17a2a9b5
      H. Peter Anvin authored
      
      
      Recently, some distros have started shipping versions of gcc which
      default to -march=i686.  This breaks building kernels for pre-i686
      machines, even if they have been selected in Kconfig, due to the
      generation of CMOV instructions.
      
      There isn't enough benefit to try to preserve the generation of these
      instructions even when selected, so simply force -march=i386 for the
      decompressor when building a 32-bit kernel.
      
      Reported-and-tested-by: default avatarChris Rankin <rankincj@yahoo.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <219280.97558.qm@web52907.mail.re2.yahoo.com>
      17a2a9b5
  27. Dec 14, 2009
    • H. Peter Anvin's avatar
      x86: Regex support and known-movable symbols for relocs, fix _end · 873b5271
      H. Peter Anvin authored
      
      
      This adds a new category of symbols to the relocs program: symbols
      which are known to be relative, even though the linker emits them as
      absolute; this is the case for symbols that live in the linker script,
      which currently applies to _end.
      
      Unfortunately the previous workaround of putting _end in its own empty
      section was defeated by newer binutils, which remove empty sections
      completely.
      
      This patch also changes the symbol matching to use regular expressions
      instead of hardcoded C for specific patterns.
      
      This is a decidedly non-minimal patch: a modified version of the
      relocs program is used as part of the Syslinux build, and this 	is
      basically a backport to Linux of some of those changes; they have
      thus been well tested.
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <4AF86211.3070103@zytor.com>
      Acked-by: default avatarMichal Marek <mmarek@suse.cz>
      Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      873b5271
  28. Nov 19, 2009
    • Jan Beulich's avatar
      x86: Eliminate redundant/contradicting cache line size config options · 350f8f56
      Jan Beulich authored
      
      
      Rather than having X86_L1_CACHE_BYTES and X86_L1_CACHE_SHIFT
      (with inconsistent defaults), just having the latter suffices as
      the former can be easily calculated from it.
      
      To be consistent, also change X86_INTERNODE_CACHE_BYTES to
      X86_INTERNODE_CACHE_SHIFT, and set it to 7 (128 bytes) for NUMA
      to account for last level cache line size (which here matters
      more than L1 cache line size).
      
      Finally, make sure the default value for X86_L1_CACHE_SHIFT,
      when X86_GENERIC is selected, is being seen before that for the
      individual CPU model options (other than on x86-64, where
      GENERIC_CPU is part of the choice construct, X86_GENERIC is a
      separate option on ix86).
      
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Acked-by: default avatarRavikiran Thirumalai <kiran@scalex86.org>
      Acked-by: default avatarNick Piggin <npiggin@suse.de>
      LKML-Reference: <4AFD5710020000780001F8F0@vpn.id2.novell.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      350f8f56
  29. Oct 24, 2009
  30. Sep 18, 2009
  31. Aug 20, 2009
  32. Jun 18, 2009
    • Peter Oberparleiter's avatar
      gcov: enable GCOV_PROFILE_ALL for x86_64 · 7bf99fb6
      Peter Oberparleiter authored
      
      
      Enable gcov profiling of the entire kernel on x86_64. Required changes
      include disabling profiling for:
      
      * arch/kernel/acpi/realmode and arch/kernel/boot/compressed:
        not linked to main kernel
      * arch/vdso, arch/kernel/vsyscall_64 and arch/kernel/hpet:
        profiling causes segfaults during boot (incompatible context)
      
      Signed-off-by: default avatarPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Li Wei <W.Li@Sun.COM>
      Cc: Michael Ellerman <michaele@au1.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Heiko Carstens <heicars2@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <mschwid2@linux.vnet.ibm.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: WANG Cong <xiyou.wangcong@gmail.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7bf99fb6
Loading