path: root/Documentation/x86/efi-stub.txt
diff options
authorLinus Torvalds <torvalds@linux-foundation.org>2012-06-02 16:17:03 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2012-06-02 16:17:03 -0700
commit63004afa718b1506fe9a286075b3b2d8c6ca2b9b (patch)
tree2ca957b939f36c7b6a8d85e162fec9d5a4bcca99 /Documentation/x86/efi-stub.txt
parenttty: Revert the tty locking series, it needs more work (diff)
parentMerge remote-tracking branch 'rostedt/tip/perf/urgent-2' into x86-urgent-for-linus (diff)
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull straggler x86 fixes from Peter Anvin: "Three groups of patches: - EFI boot stub documentation and the ability to print error messages; - Removal for PTRACE_ARCH_PRCTL for x32 (obsolete interface which should never have been ported, and the port is broken and potentially dangerous.) - ftrace stack corruption fixes. I'm not super-happy about the technical implementation, but it is probably the least invasive in the short term. In the future I would like a single method for nesting the debug stack, however." * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, x32, ptrace: Remove PTRACE_ARCH_PRCTL for x32 x86, efi: Add EFI boot stub documentation x86, efi; Add EFI boot stub console support x86, efi: Only close open files in error path ftrace/x86: Do not change stacks in DEBUG when calling lockdep x86: Allow nesting of the debug stack IDT setting x86: Reset the debug_stack update counter ftrace: Use breakpoint method to update ftrace caller ftrace: Synchronize variable setting with breakpoints
Diffstat (limited to 'Documentation/x86/efi-stub.txt')
1 files changed, 65 insertions, 0 deletions
diff --git a/Documentation/x86/efi-stub.txt b/Documentation/x86/efi-stub.txt
new file mode 100644
index 000000000000..44e6bb6ead10
--- /dev/null
+++ b/Documentation/x86/efi-stub.txt
@@ -0,0 +1,65 @@
+ The EFI Boot Stub
+ ---------------------------
+On the x86 platform, a bzImage can masquerade as a PE/COFF image,
+thereby convincing EFI firmware loaders to load it as an EFI
+executable. The code that modifies the bzImage header, along with the
+EFI-specific entry point that the firmware loader jumps to are
+collectively known as the "EFI boot stub", and live in
+arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
+By using the EFI boot stub it's possible to boot a Linux kernel
+without the use of a conventional EFI boot loader, such as grub or
+elilo. Since the EFI boot stub performs the jobs of a boot loader, in
+a certain sense it *IS* the boot loader.
+The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
+**** How to install bzImage.efi
+The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
+System Partiion (ESP) and renamed with the extension ".efi". Without
+the extension the EFI firmware loader will refuse to execute it. It's
+not possible to execute bzImage.efi from the usual Linux file systems
+because EFI firmware doesn't have support for them.
+**** Passing kernel parameters from the EFI shell
+Arguments to the kernel can be passed after bzImage.efi, e.g.
+ fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
+**** The "initrd=" option
+Like most boot loaders, the EFI stub allows the user to specify
+multiple initrd files using the "initrd=" option. This is the only EFI
+stub-specific command line parameter, everything else is passed to the
+kernel when it boots.
+The path to the initrd file must be an absolute path from the
+beginning of the ESP, relative path names do not work. Also, the path
+is an EFI-style path and directory elements must be separated with
+backslashes (\). For example, given the following directory layout,
+ Kernels\
+ bzImage.efi
+ initrd-large.img
+ Ramdisks\
+ initrd-small.img
+ initrd-medium.img
+to boot with the initrd-large.img file if the current working
+directory is fs0:\Kernels, the following command must be used,
+ fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
+Notice how bzImage.efi can be specified with a relative path. That's
+because the image we're executing is interpreted by the EFI shell,
+which understands relative paths, whereas the rest of the command line
+is passed to bzImage.efi.