]>
Commit | Line | Data |
---|---|---|
0c759662 MF |
1 | The EFI Boot Stub |
2 | --------------------------- | |
3 | ||
719e2843 RF |
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 | |
0c759662 | 9 | arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, |
719e2843 RF |
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/efi-stub-helper.c. | |
0c759662 MF |
14 | |
15 | By using the EFI boot stub it's possible to boot a Linux kernel | |
16 | without the use of a conventional EFI boot loader, such as grub or | |
17 | elilo. Since the EFI boot stub performs the jobs of a boot loader, in | |
18 | a certain sense it *IS* the boot loader. | |
19 | ||
20 | The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option. | |
21 | ||
22 | ||
23 | **** How to install bzImage.efi | |
24 | ||
25 | The bzImage located in arch/x86/boot/bzImage must be copied to the EFI | |
bf651883 | 26 | System Partition (ESP) and renamed with the extension ".efi". Without |
0c759662 MF |
27 | the extension the EFI firmware loader will refuse to execute it. It's |
28 | not possible to execute bzImage.efi from the usual Linux file systems | |
719e2843 RF |
29 | because EFI firmware doesn't have support for them. For ARM the |
30 | arch/arm/boot/zImage should be copied to the system partition, and it | |
31 | may not need to be renamed. | |
0c759662 MF |
32 | |
33 | ||
34 | **** Passing kernel parameters from the EFI shell | |
35 | ||
36 | Arguments to the kernel can be passed after bzImage.efi, e.g. | |
37 | ||
38 | fs0:> bzImage.efi console=ttyS0 root=/dev/sda4 | |
39 | ||
40 | ||
41 | **** The "initrd=" option | |
42 | ||
43 | Like most boot loaders, the EFI stub allows the user to specify | |
44 | multiple initrd files using the "initrd=" option. This is the only EFI | |
45 | stub-specific command line parameter, everything else is passed to the | |
46 | kernel when it boots. | |
47 | ||
48 | The path to the initrd file must be an absolute path from the | |
49 | beginning of the ESP, relative path names do not work. Also, the path | |
50 | is an EFI-style path and directory elements must be separated with | |
51 | backslashes (\). For example, given the following directory layout, | |
52 | ||
53 | fs0:> | |
54 | Kernels\ | |
55 | bzImage.efi | |
56 | initrd-large.img | |
57 | ||
58 | Ramdisks\ | |
59 | initrd-small.img | |
60 | initrd-medium.img | |
61 | ||
62 | to boot with the initrd-large.img file if the current working | |
63 | directory is fs0:\Kernels, the following command must be used, | |
64 | ||
65 | fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img | |
66 | ||
67 | Notice how bzImage.efi can be specified with a relative path. That's | |
68 | because the image we're executing is interpreted by the EFI shell, | |
69 | which understands relative paths, whereas the rest of the command line | |
70 | is passed to bzImage.efi. | |
719e2843 RF |
71 | |
72 | ||
73 | **** The "dtb=" option | |
74 | ||
75 | For the ARM architecture, we also need to be able to provide a device | |
76 | tree to the kernel. This is done with the "dtb=" command line option, | |
77 | and is processed in the same manner as the "initrd=" option that is | |
78 | described above. |