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