| aeffc4928ea21aab3c7be72f00e257799b661c29 |
|
10-Jul-2014 |
Michael Brown <mbrown@fensystems.co.uk> |
x86/efi: Request desired alignment via the PE/COFF headers
The EFI boot stub goes to great pains to relocate the kernel image to
an appropriately aligned address, as indicated by the ->kernel_alignment
field in the bzImage header. However, for the PE stub entry case, we
can request that the EFI PE/COFF loader do the work for us.
Fix by exposing the desired alignment via the SectionAlignment field
in the PE/COFF headers. Despite its name, this field provides an
overall alignment requirement for the loaded file. (Naturally, the
FileAlignment field describes the alignment for individual sections.)
There is no way in the PE/COFF headers to express the concept of
min_alignment; we therefore do not expose the minimum (as opposed to
preferred) alignment.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| c7fb93ec51d462ec3540a729ba446663c26a0505 |
|
10-Jul-2014 |
Michael Brown <mbrown@fensystems.co.uk> |
x86/efi: Include a .bss section within the PE/COFF headers
The PE/COFF headers currently describe only the initialised-data
portions of the image, and result in no space being allocated for the
uninitialised-data portions. Consequently, the EFI boot stub will end
up overwriting unexpected areas of memory, with unpredictable results.
Fix by including a .bss section in the PE/COFF headers (functionally
equivalent to the init_size field in the bzImage header).
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Cc: Thomas Bächler <thomas@archlinux.org>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| 745c51673e289acf4d9ffc2835524de73ef923fd |
|
07-Jun-2014 |
Matt Fleming <matt.fleming@intel.com> |
x86/boot: EFI_MIXED should not prohibit loading above 4G
commit 7d453eee36ae ("x86/efi: Wire up CONFIG_EFI_MIXED") introduced a
regression for the functionality to load kernels above 4G. The relevant
(incorrect) reasoning behind this change can be seen in the commit
message,
"The xloadflags field in the bzImage header is also updated to reflect
that the kernel supports both entry points by setting both of
XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y.
XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
guaranteed to be addressable with 32-bits."
This is obviously bogus since 32-bit EFI loaders will never place the
kernel above the 4G mark. So this restriction is entirely unnecessary.
But things are worse than that - since we want to encourage people to
always compile with CONFIG_EFI_MIXED=y so that their kernels work out of
the box for both 32-bit and 64-bit firmware, commit 7d453eee36ae
effectively disables XLF_CAN_BE_LOADED_ABOVE_4G completely.
Remove the overzealous and superfluous restriction and restore the
XLF_CAN_BE_LOADED_ABOVE_4G functionality.
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1402140380-15377-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| 3e920b532a0f49d05e4c0f7d1b46b0ab8f471e09 |
|
12-Mar-2014 |
Borislav Petkov <bp@suse.de> |
x86, boot: Correct max ramdisk size name
The name in struct bootparam is ->initrd_addr_max and not ramdisk_max.
Fix that.
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/1394633584-5509-2-git-send-email-bp@alien8.de
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
| 7d453eee36ae4cf30fc2f2faae54f634c4f863b7 |
|
10-Jan-2014 |
Matt Fleming <matt.fleming@intel.com> |
x86/efi: Wire up CONFIG_EFI_MIXED
Add the Kconfig option and bump the kernel header version so that boot
loaders can check whether the handover code is available if they want.
The xloadflags field in the bzImage header is also updated to reflect
that the kernel supports both entry points by setting both of
XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y.
XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
guaranteed to be addressable with 32-bits.
Note that no boot loaders should be using the bits set in xloadflags to
decide which entry point to jump to. The entire scheme is based on the
concept that 32-bit bootloaders always jump to ->handover_offset and
64-bit loaders always jump to ->handover_offset + 512. We set both bits
merely to inform the boot loader that it's safe to use the native
handover offset even if the machine type in the PE/COFF header claims
otherwise.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| 86134a1b39fd056a7b6778608a5882f0ea1bc705 |
|
01-Aug-2013 |
Matt Fleming <matt.fleming@intel.com> |
x86/boot: Cleanup header.S by removing some #ifdefs
handover_offset is now filled out by build.c. Don't set a default value
as it will be overwritten anyway.
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| 456a29ddada79198c5965300e04103c40c481f62 |
|
20-Dec-2013 |
Dave Young <dyoung@redhat.com> |
x86: Add xloadflags bit for EFI runtime support on kexec
Old kexec-tools can not load new kernels. The reason is kexec-tools does
not fill efi_info in x86 setup header previously, thus EFI failed to
initialize. In new kexec-tools it will by default to fill efi_info and
pass other EFI required infomation to 2nd kernel so kexec kernel EFI
initialization can succeed finally.
To prevent from breaking userspace, add a new xloadflags bit so
kexec-tools can check the flag and switch to old logic.
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| ee92d815027a76ef92f3ec7b155b0c8aa345f239 |
|
29-Jan-2013 |
Yinghai Lu <yinghai@kernel.org> |
x86, boot: Support loading bzImage, boot_params and ramdisk above 4G
xloadflags bit 1 indicates that we can load the kernel and all data
structures above 4G; it is set if kernel is relocatable and 64bit.
bootloader will check if xloadflags bit 1 is set to decide if
it could load ramdisk and kernel high above 4G.
bootloader will fill value to ext_ramdisk_image/size for high 32bits
when it load ramdisk above 4G.
kernel use get_ramdisk_image/size to use ext_ramdisk_image/size to get
right positon for ramdisk.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Rob Landley <rob@landley.net>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Gokul Caushik <caushik1@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joe Millenbach <jmillenbach@gmail.com>
Link: http://lkml.kernel.org/r/1359058816-7615-26-git-send-email-yinghai@kernel.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
| 09c205afde70c15f20ca76ba0a57409dad175fd0 |
|
27-Jan-2013 |
H. Peter Anvin <hpa@linux.intel.com> |
x86, boot: Define the 2.12 bzImage boot protocol
Define the 2.12 bzImage boot protocol: add xloadflags and additional
fields to allow the command line, initramfs and struct boot_params to
live above the 4 GiB mark.
The xloadflags now communicates if this is a 64-bit kernel with the
legacy 64-bit entry point and which of the EFI handover entry points
are supported.
Avoid adding new read flags to loadflags because of claimed
bootloaders testing the whole byte for == 1 to determine bzImageness
at least until the issue can be researched further.
This is based on patches by Yinghai Lu and David Woodhouse.
Originally-by: Yinghai Lu <yinghai@kernel.org>
Originally-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/1359058816-7615-26-git-send-email-yinghai@kernel.org
Cc: Rob Landley <rob@landley.net>
Cc: Gokul Caushik <caushik1@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Joe Millenbach <jmillenbach@gmail.com>
|
| caaa8c6339ccefee6e834c4a8b0bec7e721e7357 |
|
28-Oct-2012 |
Cesar Eduardo Barros <cesarb@cesarb.net> |
x86: remove dummy long from EFI stub
Commit 2e064b1 (x86, efi: Fix issue of overlapping .reloc section for
EFI_STUB) removed a dummy reloc added by commit 291f363 (x86, efi: EFI
boot stub support), but forgot to remove the dummy long used by that
reloc.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Lee G Rosenbaum <lee.g.rosenbaum@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
| 0570a365a6b8ccbfe7baa459de2b7396ddf2de90 |
|
19-Aug-2012 |
Paul Bolle <pebolle@tiscali.nl> |
x86, boot: Remove obsolete and unused constant RAMDISK
The named constant RAMDISK is unused. It used to set the (obsolete)
kernel boot header field ram_size, but its usage for that purpose got
dropped in commit 5e47c478b0b69bc9bc3ba544e4b1ca3268f98fef ("x86: remove
zImage support"). Now remove this constant too.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Link: http://lkml.kernel.org/r/1345396003.1771.9.camel@x61.thuisdomein
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
| 9ca8f72a9297f2052d806bd1111e176533aa69bd |
|
19-Jul-2012 |
Matt Fleming <matt.fleming@intel.com> |
x86, efi: Handover Protocol
As things currently stand, traditional EFI boot loaders and the EFI
boot stub are carrying essentially the same initialisation code
required to setup an EFI machine for booting a kernel. There's really
no need to have this code in two places and the hope is that, with
this new protocol, initialisation and booting of the kernel can be
left solely to the kernel's EFI boot stub. The responsibilities of the
boot loader then become,
o Loading the kernel image from boot media
File system code still needs to be carried by boot loaders for the
scenario where the kernel and initrd files reside on a file system
that the EFI firmware doesn't natively understand, such as ext4, etc.
o Providing a user interface
Boot loaders still need to display any menus/interfaces, for example
to allow the user to select from a list of kernels.
Bump the boot protocol number because we added the 'handover_offset'
field to indicate the location of the handover protocol entry point.
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Acked-and-Tested-by: Matthew Garrett <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1342689828-16815-1-git-send-email-matt@console-pimps.org
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| e5a7286b5f1b0b5beb97275f2152bf10c4aa4204 |
|
21-Jun-2012 |
Paul Bolle <pebolle@tiscali.nl> |
x86, boot: Remove ancient, unconditionally #ifdef'd out dead code
Release v1.3.82 wrapped a few lines of code in an "#ifdef
SAFE_RESET_DISK_CONTROLLER" and "#endif" pair. Since
SAFE_RESET_DISK_CONTROLLER was never defined anywhere that was basically
a verbose "#ifdef 0" and "#endif" pair. These dead lines have been in
the tree for sixteen years but now the time has come to remove them.
I guess the main lesson here is that if you want your dead code in the
tree for a very long time you'd better be creative. A plain old "#ifdef
0" and "#endif" pair just doesn't cut it!
See: http://lkml.kernel.org/r/199603301718.LAA00178@craie.inetnebr.com
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Link: http://lkml.kernel.org/r/1340230589.1773.7.camel@x61.thuisdomein
Acked-by: Jeff Epler <jepler@unpythonic.net>
Acked-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
| 743628e868c5992354fc80b4d1e9a6143da1c0e6 |
|
07-Jun-2012 |
Jordan Justen <jordan.l.justen@intel.com> |
x86, efi stub: Add .reloc section back into image
Some UEFI firmware will not load a .efi with a .reloc section
with a size of 0.
Therefore, we create a .efi image with 4 main areas and 3 sections.
1. PE/COFF file header
2. .setup section (covers all setup code following the first sector)
3. .reloc section (contains 1 dummy reloc entry, created in build.c)
4. .text section (covers the remaining kernel image)
To make room for the new .setup section data, the header
bugger_off_msg had to be shortened.
Reported-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Link: http://lkml.kernel.org/r/1339085121-12760-1-git-send-email-jordan.l.justen@intel.com
Tested-by: Lee G Rosenbaum <lee.g.rosenbaum@intel.com>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Cc: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| e47bb0bda46bf50f81671db502d0c903e0a32604 |
|
23-Mar-2012 |
Matt Fleming <matt.fleming@intel.com> |
x86, efi: Fix NumberOfRvaAndSizes field in PE32 header for EFI_STUB
We've actually got six data directories in the header, not one. Even
though the firmware loader doesn't seem to mind, when we come to sign
the kernel image the signing tool thinks that there is no Certificate
Table data directory, even though we've allocated space for one.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1332520506-6472-4-git-send-email-jordan.l.justen@intel.com
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
| e31be363df3092821bf179cf4baa076f501b8ae6 |
|
23-Mar-2012 |
Matt Fleming <matt.fleming@intel.com> |
x86, efi: Fix .text section overlapping image header for EFI_STUB
This change modifes the PE .text section to start after
the first sector of the kernel image.
The header may be modified by the UEFI secure boot signing,
so it is not appropriate for it to be included in one of the
image sections. Since the sections are part of the secure
boot hash, this modification to the .text section contents
would invalidate the secure boot signed hash.
Note: UEFI secure boot does hash the image header, but
fields that are changed by the signing process are excluded
from the hash calculation. This exclusion process is only
handled for the image header, and not image sections.
Luckily, we can still easily boot without the first sector
by initializing a few fields in arch/x86/boot/compressed/eboot.c.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1332520506-6472-3-git-send-email-jordan.l.justen@intel.com
[jordan.l.justen@intel.com: set .text vma & file offset]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
| 2e064b1e131eba262c0ba4268cb79dbc72edeece |
|
23-Mar-2012 |
Jordan Justen <jordan.l.justen@intel.com> |
x86, efi: Fix issue of overlapping .reloc section for EFI_STUB
Previously the .reloc section was embedded in the .text
section.
No relocations are required during the PE/COFF loading phase
for the kernel using the EFI_STUB UEFI loader. To fix the
issue of overlapping sections, create a .reloc section with a
zero length.
The .reloc section header must exist to make sure the image
will be loaded by the UEFI firmware, but a zero-length
section header seems to be sufficient.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Link: http://lkml.kernel.org/r/1332520506-6472-2-git-send-email-jordan.l.justen@intel.com
Acked-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
| 291f36325f9f252bd76ef5f603995f37e453fc60 |
|
12-Dec-2011 |
Matt Fleming <matt.fleming@intel.com> |
x86, efi: EFI boot stub support
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: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
| 395cf9691d72173d8cdaa613c5f0255f993af94b |
|
15-Aug-2011 |
Paul Bolle <pebolle@tiscali.nl> |
doc: fix broken references
There are numerous broken references to Documentation files (in other
Documentation files, in comments, etc.). These broken references are
caused by typo's in the references, and by renames or removals of the
Documentation files. Some broken references are simply odd.
Fix these broken references, sometimes by dropping the irrelevant text
they were part of.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
| 273b281fa22c293963ee3e6eec418f5dda2dbc83 |
|
18-Oct-2009 |
Sam Ravnborg <sam@ravnborg.org> |
kbuild: move utsrelease.h to include/generated
Fix up all users of utsrelease.h
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
| c6ac4c18fbc92a26df71ece609b082bc3099676b |
|
20-May-2009 |
H. Peter Anvin <hpa@zytor.com> |
x86, boot: correct the calculation of ZO_INIT_SIZE
Correct the calculation of ZO_INIT_SIZE (the amount of memory we need
during decompression). One symbol (ZO_startup_32) was missing from
zoffset.h, and another (ZO_z_extract_offset) was misspelled.
[ Impact: build fix ]
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| 5031296c57024a78ddad4edfc993367dbf4abb98 |
|
08-May-2009 |
H. Peter Anvin <hpa@zytor.com> |
x86: add extension fields for bootloader type and version
A long ago, in days of yore, it all began with a god named Thor.
There were vikings and boats and some plans for a Linux kernel
header. Unfortunately, a single 8-bit field was used for bootloader
type and version. This has generally worked without *too* much pain,
but we're getting close to flat running out of ID fields.
Add extension fields for both type and version. The type will be
extended if it the old field is 0xE; the version is a simple MSB
extension.
Keep /proc/sys/kernel/bootloader_type containing
(type << 4) + (ver & 0xf) for backwards compatiblity, but also add
/proc/sys/kernel/bootloader_version which contains the full version
number.
[ Impact: new feature to support more bootloaders ]
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| 37ba7ab5e33cebc25c68fffe33e9f21e7c2014e8 |
|
12-May-2009 |
H. Peter Anvin <hpa@zytor.com> |
x86, boot: make kernel_alignment adjustable; new bzImage fields
Make the kernel_alignment field adjustable; this allows us to set it
to a large value (intended to be 16 MB to avoid ZONE_DMA contention,
memory holes and other weirdness) while a smart bootloader can still
force a loading at a lesser alignment if absolutely necessary.
Also export pref_address (preferred loading address, corresponding to
the link-time address) and init_size, the total amount of linear
memory the kernel will require during initialization.
[ Impact: allows better kernel placement, gives bootloader more info ]
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| 77d1a4999502c260df0eb2de437d320bf8c64b36 |
|
11-May-2009 |
H. Peter Anvin <hpa@zytor.com> |
x86, boot: make symbols from the main vmlinux available
Make symbols from the main vmlinux, as opposed to just
compressed/vmlinux, available to header.S. Also, export a few
additional symbols.
This will be used in a subsequent patch to export the total memory
footprint of the kernel.
[ Impact: enable future enhancement ]
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| 7a734e7dd93b9aea08ed51036a9a0e2c9dfd8dac |
|
02-Apr-2009 |
H. Peter Anvin <hpa@linux.intel.com> |
x86, setup: "glove box" BIOS calls -- infrastructure
Impact: new interfaces (not yet used)
For all the platforms out there, there is an infinite number of buggy
BIOSes. This adds infrastructure to treat BIOS interrupts more like
toxic waste and "glove box" them -- we switch out the register set,
perform the BIOS interrupt, and then restore the previous state.
LKML-Reference: <49DE7F79.4030106@zytor.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
|
| 5e47c478b0b69bc9bc3ba544e4b1ca3268f98fef |
|
11-Mar-2009 |
H. Peter Anvin <hpa@zytor.com> |
x86: remove zImage support
Impact: obsolete feature removal
The zImage kernel format has been functionally unused for a very long
time. It is just barely possible to build a modern kernel that still
fits within the zImage size limit, but it is highly unlikely that
anyone ever uses it. Furthermore, although it is still supported by
most bootloaders, it has been at best poorly tested (or not tested at
all); some bootloaders are even known to not support zImage at all and
not having even noticed.
Also remove some really obsolete constants that no longer have any
meaning.
LKML-Reference: <49B703D4.1000008@zytor.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| 0341c14da49e7b93d2998926f6ac89a3129e3fa1 |
|
13-Feb-2009 |
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> |
x86: use _types.h headers in asm where available
In general, the only definitions that assembly files can use
are in _types.S headers (where available), so convert them.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
|
| 998564789137921acae9e367b61c5a1dc295653d |
|
16-Sep-2008 |
Paul Bolle <pebolle@tiscali.nl> |
x86 setup: drop SWAP_DEV
Impact: None (cleanup)
SWAP_DEV is unused since 2.6.23-rc1. The comment was already incorrect
since (at least) 2.6.12.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| 8b664aa66e824a0ddf4ec56d41fa0cf7bb374de6 |
|
28-Mar-2008 |
Huang, Ying <ying.huang@intel.com> |
x86, boot: add linked list of struct setup_data
This patch adds a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
| 87253d1b4f2b5a29bdfc6275b9fb52a47d72df64 |
|
19-Feb-2008 |
Ian Campbell <ijc@hellion.org.uk> |
x86: boot protocol updates
Also update field names to simply payload_{offset,length} so as to not rule
out uncompressed images.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
| 52b387197beb5c89f734f057553fdf7d417b448c |
|
17-Feb-2008 |
Ingo Molnar <mingo@elte.hu> |
x86: bump image header to version 2.08.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
| 099e1377269a47ed30a00ee131001988e5bcaa9c |
|
13-Feb-2008 |
Ian Campbell <ijc@hellion.org.uk> |
x86: use ELF format in compressed images.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: virtualization@lists.linux-foundation.org
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
| cf8fa920cb4271f17e0265c863d64bea1b31941a |
|
30-Jan-2008 |
H. Peter Anvin <hpa@zytor.com> |
i386: handle an initrd in highmem (version 2)
The boot protocol has until now required that the initrd be located in
lowmem, which makes the lowmem/highmem boundary visible to the boot
loader. This was exported to the bootloader via a compile-time
field. Unfortunately, the vmalloc= command-line option breaks this
part of the protocol; instead of adding yet another hack that affects
the bootloader, have the kernel relocate the initrd down below the
lowmem boundary inside the kernel itself.
Note that this does not rely on HIGHMEM being enabled in the kernel.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
| 16252da654800461e0e1c32697cb59f4cda15aa9 |
|
27-Nov-2007 |
Jens Rottmann <JRottmann@lippert-at.de> |
x86 setup: don't recalculate ss:esp unless really necessary
In order to work around old LILO versions providing an invalid ss
register, the current setup code always sets up a new stack,
immediately following .bss and the heap. But this breaks LOADLIN.
This rewrite of the workaround checks for an invalid stack (ss!=ds)
first, and leaves ss:sp alone otherwise (apart from aligning esp).
[hpa note: LOADLIN has a number of arbitrary hard-coded limits that
are being pushed up against. Without some major revision of LOADLIN
itself it will not be sustainable keeping it alive. This gives it
another brief lease on life, however. This patch also helps the
cmdline truncation problem with old versions of SYSLINUX.]
Signed-off-by: Jens Rottmann <JRottmann at LiPPERT-AT. de>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| 6b6815c6d5d1dc209701d1661a7a0e09a295db2f |
|
26-Oct-2007 |
H. Peter Anvin <hpa@zytor.com> |
x86 setup: handle boot loaders which set up the stack incorrectly
Apparently some specific versions of LILO enter the kernel with a
stack pointer that doesn't match the rest of the segments. Make our
best attempt at untangling the resulting mess.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
|
| a24e785111a32ccb7cebafd24b1b1cb474ea8e5d |
|
22-Oct-2007 |
Rusty Russell <rusty@rustcorp.com.au> |
i386: paravirt boot sequence
This patch uses the updated boot protocol to do paravirtualized boot.
If the boot version is >= 2.07, then it will do two things:
1. Check the bootparams loadflags to see if we should reload the
segment registers and clear interrupts. This is appropriate
for normal native boot and some paravirtualized environments, but
inapproprate for others.
2. Check the hardware architecture, and dispatch to the appropriate
kernel entrypoint. If the bootloader doesn't set this, then we
simply do the normal boot sequence.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Zachary Amsden <zach@vmware.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| 96ae6ea0be1b902c28b3b463c27da42b41e2b63a |
|
11-Oct-2007 |
Thomas Gleixner <tglx@linutronix.de> |
i386: move boot
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|