| Leif Lindholm | e197746 | 2013-11-28 16:41:21 +0000 | [diff] [blame^] | 1 | UEFI, the Unified Extensible Firmware Interface, is a specification |
| 2 | governing the behaviours of compatible firmware interfaces. It is |
| 3 | maintained by the UEFI Forum - http://www.uefi.org/. |
| 4 | |
| 5 | UEFI is an evolution of its predecessor 'EFI', so the terms EFI and |
| 6 | UEFI are used somewhat interchangeably in this document and associated |
| 7 | source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers |
| 8 | to legacy code or specifications. |
| 9 | |
| 10 | UEFI support in Linux |
| 11 | ===================== |
| 12 | Booting on a platform with firmware compliant with the UEFI specification |
| 13 | makes it possible for the kernel to support additional features: |
| 14 | - UEFI Runtime Services |
| 15 | - Retrieving various configuration information through the standardised |
| 16 | interface of UEFI configuration tables. (ACPI, SMBIOS, ...) |
| 17 | |
| 18 | For actually enabling [U]EFI support, enable: |
| 19 | - CONFIG_EFI=y |
| 20 | - CONFIG_EFI_VARS=y or m |
| 21 | |
| 22 | The implementation depends on receiving information about the UEFI environment |
| 23 | in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF. |
| 24 | |
| 25 | UEFI stub |
| 26 | ========= |
| 27 | The "stub" is a feature that extends the Image/zImage into a valid UEFI |
| 28 | PE/COFF executable, including a loader application that makes it possible to |
| 29 | load the kernel directly from the UEFI shell, boot menu, or one of the |
| 30 | lightweight bootloaders like Gummiboot or rEFInd. |
| 31 | |
| 32 | The kernel image built with stub support remains a valid kernel image for |
| 33 | booting in non-UEFI environments. |
| 34 | |
| 35 | UEFI kernel support on ARM |
| 36 | ========================== |
| 37 | UEFI kernel support on the ARM architectures (arm and arm64) is only available |
| 38 | when boot is performed through the stub. |
| 39 | |
| 40 | When booting in UEFI mode, the stub deletes any memory nodes from a provided DT. |
| 41 | Instead, the kernel reads the UEFI memory map. |
| 42 | |
| 43 | The stub populates the FDT /chosen node with (and the kernel scans for) the |
| 44 | following parameters: |
| 45 | ________________________________________________________________________________ |
| 46 | Name | Size | Description |
| 47 | ================================================================================ |
| 48 | linux,uefi-system-table | 64-bit | Physical address of the UEFI System Table. |
| 49 | -------------------------------------------------------------------------------- |
| 50 | linux,uefi-mmap-start | 64-bit | Physical address of the UEFI memory map, |
| 51 | | | populated by the UEFI GetMemoryMap() call. |
| 52 | -------------------------------------------------------------------------------- |
| 53 | linux,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map |
| 54 | | | pointed to in previous entry. |
| 55 | -------------------------------------------------------------------------------- |
| 56 | linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI |
| 57 | | | memory map. |
| 58 | -------------------------------------------------------------------------------- |
| 59 | linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. |
| 60 | -------------------------------------------------------------------------------- |
| 61 | linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. |
| 62 | -------------------------------------------------------------------------------- |
| 63 | |
| 64 | For verbose debug messages, specify 'uefi_debug' on the kernel command line. |