projects / GitHub / mt8127 / android_kernel_alcatel_ttab.git / blame
| Commit | Line | Data |
|---|---|---|
| 0c759662 MF |
1 | The EFI Boot Stub |
| 2 | --------------------------- | |
| 3 | ||
| 4 | On the x86 platform, a bzImage can masquerade as a PE/COFF image, | |
| 5 | thereby convincing EFI firmware loaders to load it as an EFI | |
| 6 | executable. The code that modifies the bzImage header, along with the | |
| 7 | EFI-specific entry point that the firmware loader jumps to are | |
| 8 | 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. | |
| 11 | ||
| 12 | By using the EFI boot stub it's possible to boot a Linux kernel | |
| 13 | without the use of a conventional EFI boot loader, such as grub or | |
| 14 | elilo. Since the EFI boot stub performs the jobs of a boot loader, in | |
| 15 | a certain sense it *IS* the boot loader. | |
| 16 | ||
| 17 | The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option. | |
| 18 | ||
| 19 | ||
| 20 | **** How to install bzImage.efi | |
| 21 | ||
| 22 | The bzImage located in arch/x86/boot/bzImage must be copied to the EFI | |
| 23 | System Partiion (ESP) and renamed with the extension ".efi". Without | |
| 24 | the extension the EFI firmware loader will refuse to execute it. It's | |
| 25 | not possible to execute bzImage.efi from the usual Linux file systems | |
| 26 | because EFI firmware doesn't have support for them. | |
| 27 | ||
| 28 | ||
| 29 | **** Passing kernel parameters from the EFI shell | |
| 30 | ||
| 31 | Arguments to the kernel can be passed after bzImage.efi, e.g. | |
| 32 | ||
| 33 | fs0:> bzImage.efi console=ttyS0 root=/dev/sda4 | |
| 34 | ||
| 35 | ||
| 36 | **** The "initrd=" option | |
| 37 | ||
| 38 | Like most boot loaders, the EFI stub allows the user to specify | |
| 39 | multiple initrd files using the "initrd=" option. This is the only EFI | |
| 40 | stub-specific command line parameter, everything else is passed to the | |
| 41 | kernel when it boots. | |
| 42 | ||
| 43 | The path to the initrd file must be an absolute path from the | |
| 44 | beginning of the ESP, relative path names do not work. Also, the path | |
| 45 | is an EFI-style path and directory elements must be separated with | |
| 46 | backslashes (\). For example, given the following directory layout, | |
| 47 | ||
| 48 | fs0:> | |
| 49 | Kernels\ | |
| 50 | bzImage.efi | |
| 51 | initrd-large.img | |
| 52 | ||
| 53 | Ramdisks\ | |
| 54 | initrd-small.img | |
| 55 | initrd-medium.img | |
| 56 | ||
| 57 | to boot with the initrd-large.img file if the current working | |
| 58 | directory is fs0:\Kernels, the following command must be used, | |
| 59 | ||
| 60 | fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img | |
| 61 | ||
| 62 | Notice how bzImage.efi can be specified with a relative path. That's | |
| 63 | because the image we're executing is interpreted by the EFI shell, | |
| 64 | which understands relative paths, whereas the rest of the command line | |
| 65 | is passed to bzImage.efi. |