aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/efi-stub.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/efi-stub.txt')
-rw-r--r--Documentation/efi-stub.txt33
1 files changed, 26 insertions, 7 deletions
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index c628788d5b47..7747024d3bb7 100644
--- a/Documentation/efi-stub.txt
+++ b/Documentation/efi-stub.txt
@@ -1,13 +1,21 @@
1 The EFI Boot Stub 1 The EFI Boot Stub
2 --------------------------- 2 ---------------------------
3 3
4On the x86 platform, a bzImage can masquerade as a PE/COFF image, 4On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
5thereby convincing EFI firmware loaders to load it as an EFI 5as a PE/COFF image, thereby convincing EFI firmware loaders to load
6executable. The code that modifies the bzImage header, along with the 6it as an EFI executable. The code that modifies the bzImage header,
7EFI-specific entry point that the firmware loader jumps to are 7along with the EFI-specific entry point that the firmware loader
8collectively known as the "EFI boot stub", and live in 8jumps to are collectively known as the "EFI boot stub", and live in
9arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, 9arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
10respectively. 10respectively. For ARM the EFI stub is implemented in
11arch/arm/boot/compressed/efi-header.S and
12arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
13between architectures is in drivers/firmware/efi/efi-stub-helper.c.
14
15For arm64, there is no compressed kernel support, so the Image itself
16masquerades as a PE/COFF image and the EFI stub is linked into the
17kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S
18and arch/arm64/kernel/efi-stub.c.
11 19
12By using the EFI boot stub it's possible to boot a Linux kernel 20By using the EFI boot stub it's possible to boot a Linux kernel
13without the use of a conventional EFI boot loader, such as grub or 21without the use of a conventional EFI boot loader, such as grub or
@@ -23,7 +31,10 @@ The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
23System Partition (ESP) and renamed with the extension ".efi". Without 31System Partition (ESP) and renamed with the extension ".efi". Without
24the extension the EFI firmware loader will refuse to execute it. It's 32the extension the EFI firmware loader will refuse to execute it. It's
25not possible to execute bzImage.efi from the usual Linux file systems 33not possible to execute bzImage.efi from the usual Linux file systems
26because EFI firmware doesn't have support for them. 34because EFI firmware doesn't have support for them. For ARM the
35arch/arm/boot/zImage should be copied to the system partition, and it
36may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image
37should be copied but not necessarily renamed.
27 38
28 39
29**** Passing kernel parameters from the EFI shell 40**** Passing kernel parameters from the EFI shell
@@ -63,3 +74,11 @@ Notice how bzImage.efi can be specified with a relative path. That's
63because the image we're executing is interpreted by the EFI shell, 74because the image we're executing is interpreted by the EFI shell,
64which understands relative paths, whereas the rest of the command line 75which understands relative paths, whereas the rest of the command line
65is passed to bzImage.efi. 76is passed to bzImage.efi.
77
78
79**** The "dtb=" option
80
81For the ARM and arm64 architectures, we also need to be able to provide a
82device tree to the kernel. This is done with the "dtb=" command line option,
83and is processed in the same manner as the "initrd=" option that is
84described above.