blob: e157469882614ae96ddced101a5fc77315d49043
1 | The EFI Boot Stub |
2 | --------------------------- |
3 | |
4 | On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade |
5 | as a PE/COFF image, thereby convincing EFI firmware loaders to load |
6 | it as an EFI executable. The code that modifies the bzImage header, |
7 | along with the EFI-specific entry point that the firmware loader |
8 | jumps to are collectively known as the "EFI boot stub", and live in |
9 | arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, |
10 | respectively. For ARM the EFI stub is implemented in |
11 | arch/arm/boot/compressed/efi-header.S and |
12 | arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared |
13 | between architectures is in drivers/firmware/efi/libstub. |
14 | |
15 | For arm64, there is no compressed kernel support, so the Image itself |
16 | masquerades as a PE/COFF image and the EFI stub is linked into the |
17 | kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S |
18 | and drivers/firmware/efi/libstub/arm64-stub.c. |
19 | |
20 | By using the EFI boot stub it's possible to boot a Linux kernel |
21 | without the use of a conventional EFI boot loader, such as grub or |
22 | elilo. Since the EFI boot stub performs the jobs of a boot loader, in |
23 | a certain sense it *IS* the boot loader. |
24 | |
25 | The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option. |
26 | |
27 | |
28 | **** How to install bzImage.efi |
29 | |
30 | The bzImage located in arch/x86/boot/bzImage must be copied to the EFI |
31 | System Partition (ESP) and renamed with the extension ".efi". Without |
32 | the extension the EFI firmware loader will refuse to execute it. It's |
33 | not possible to execute bzImage.efi from the usual Linux file systems |
34 | because EFI firmware doesn't have support for them. For ARM the |
35 | arch/arm/boot/zImage should be copied to the system partition, and it |
36 | may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image |
37 | should be copied but not necessarily renamed. |
38 | |
39 | |
40 | **** Passing kernel parameters from the EFI shell |
41 | |
42 | Arguments to the kernel can be passed after bzImage.efi, e.g. |
43 | |
44 | fs0:> bzImage.efi console=ttyS0 root=/dev/sda4 |
45 | |
46 | |
47 | **** The "initrd=" option |
48 | |
49 | Like most boot loaders, the EFI stub allows the user to specify |
50 | multiple initrd files using the "initrd=" option. This is the only EFI |
51 | stub-specific command line parameter, everything else is passed to the |
52 | kernel when it boots. |
53 | |
54 | The path to the initrd file must be an absolute path from the |
55 | beginning of the ESP, relative path names do not work. Also, the path |
56 | is an EFI-style path and directory elements must be separated with |
57 | backslashes (\). For example, given the following directory layout, |
58 | |
59 | fs0:> |
60 | Kernels\ |
61 | bzImage.efi |
62 | initrd-large.img |
63 | |
64 | Ramdisks\ |
65 | initrd-small.img |
66 | initrd-medium.img |
67 | |
68 | to boot with the initrd-large.img file if the current working |
69 | directory is fs0:\Kernels, the following command must be used, |
70 | |
71 | fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img |
72 | |
73 | Notice how bzImage.efi can be specified with a relative path. That's |
74 | because the image we're executing is interpreted by the EFI shell, |
75 | which understands relative paths, whereas the rest of the command line |
76 | is passed to bzImage.efi. |
77 | |
78 | |
79 | **** The "dtb=" option |
80 | |
81 | For the ARM and arm64 architectures, we also need to be able to provide a |
82 | device tree to the kernel. This is done with the "dtb=" command line option, |
83 | and is processed in the same manner as the "initrd=" option that is |
84 | described above. |
85 |