kernel/git/stable/linux.git/drivers/firmware/efi/arm-init.c, branch master

efi: Rename arm-init to efi-init common for all arch

2020-09-11T06:31:07+00:00

arm-init is responsible for setting up efi runtime and doesn't actually do any ARM specific stuff. RISC-V can use the same source code as it is. Rename it to efi-init so that RISC-V can use it. Signed-off-by: Atish Patra Link: https://lore.kernel.org/r/20200819222425.30721-8-atish.patra@wdc.com Signed-off-by: Ard Biesheuvel

efi/libstub: arm: Print CPU boot mode and MMU state at boot

2020-06-17T13:29:11+00:00

On 32-bit ARM, we may boot at HYP mode, or with the MMU and caches off (or both), even though the EFI spec does not actually support this. While booting at HYP mode is something we might tolerate, fiddling with the caches is a more serious issue, as disabling the caches is tricky to do safely from C code, and running without the Dcache makes it impossible to support unaligned memory accesses, which is another explicit requirement imposed by the EFI spec. So take note of the CPU mode and MMU state in the EFI stub diagnostic output so that we can easily diagnose any issues that may arise from this. E.g., EFI stub: Entering in SVC mode with MMU enabled Also, capture the CPSR and SCTLR system register values at EFI stub entry, and after ExitBootServices() returns, and check whether the MMU and Dcache were disabled at any point. If this is the case, a diagnostic message like the following will be emitted: efi: [Firmware Bug]: EFI stub was entered with MMU and Dcache disabled, please fix your firmware! efi: CPSR at EFI stub entry : 0x600001d3 efi: SCTLR at EFI stub entry : 0x00c51838 efi: CPSR after ExitBootServices() : 0x600001d3 efi: SCTLR after ExitBootServices(): 0x00c50838 Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm

efi/libstub: arm: Omit arch specific config table matching array on arm64

2020-06-17T13:29:11+00:00

On arm64, the EFI stub is built into the kernel proper, and so the stub can refer to its symbols directly. Therefore, the practice of using EFI configuration tables to pass information between them is never needed, so we can omit any code consuming such tables when building for arm64. Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm

efi: Clean up config table description arrays

2020-04-24T12:52:16+00:00

Increase legibility by adding whitespace to the efi_config_table_type_t arrays that describe which EFI config tables we look for when going over the firmware provided list. While at it, replace the 'name' char pointer with a char array, which is more space efficient on relocatable 64-bit kernels, as it avoids a 8 byte pointer and the associated relocation data (24 bytes when using RELA format) Signed-off-by: Ard Biesheuvel

Merge branch 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-03-30T23:13:08+00:00

Pull EFI updates from Ingo Molnar: "The EFI changes in this cycle are much larger than usual, for two (positive) reasons: - The GRUB project is showing signs of life again, resulting in the introduction of the generic Linux/UEFI boot protocol, instead of x86 specific hacks which are increasingly difficult to maintain. There's hope that all future extensions will now go through that boot protocol. - Preparatory work for RISC-V EFI support. The main changes are: - Boot time GDT handling changes - Simplify handling of EFI properties table on arm64 - Generic EFI stub cleanups, to improve command line handling, file I/O, memory allocation, etc. - Introduce a generic initrd loading method based on calling back into the firmware, instead of relying on the x86 EFI handover protocol or device tree. - Introduce a mixed mode boot method that does not rely on the x86 EFI handover protocol either, and could potentially be adopted by other architectures (if another one ever surfaces where one execution mode is a superset of another) - Clean up the contents of 'struct efi', and move out everything that doesn't need to be stored there. - Incorporate support for UEFI spec v2.8A changes that permit firmware implementations to return EFI_UNSUPPORTED from UEFI runtime services at OS runtime, and expose a mask of which ones are supported or unsupported via a configuration table. - Partial fix for the lack of by-VA cache maintenance in the decompressor on 32-bit ARM. - Changes to load device firmware from EFI boot service memory regions - Various documentation updates and minor code cleanups and fixes" * 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (114 commits) efi/libstub/arm: Fix spurious message that an initrd was loaded efi/libstub/arm64: Avoid image_base value from efi_loaded_image partitions/efi: Fix partition name parsing in GUID partition entry efi/x86: Fix cast of image argument efi/libstub/x86: Use ULONG_MAX as upper bound for all allocations efi: Fix a mistype in comments mentioning efivar_entry_iter_begin() efi/libstub: Avoid linking libstub/lib-ksyms.o into vmlinux efi/x86: Preserve %ebx correctly in efi_set_virtual_address_map() efi/x86: Ignore the memory attributes table on i386 efi/x86: Don't relocate the kernel unless necessary efi/x86: Remove extra headroom for setup block efi/x86: Add kernel preferred address to PE header efi/x86: Decompress at start of PE image load address x86/boot/compressed/32: Save the output address instead of recalculating it efi/libstub/x86: Deal with exit() boot service returning x86/boot: Use unsigned comparison for addresses efi/x86: Avoid using code32_start efi/x86: Make efi32_pe_entry() more readable efi/x86: Respect 32-bit ABI in efi32_pe_entry() efi/x86: Annotate the LOADED_IMAGE_PROTOCOL_GUID with SYM_DATA ...

efi/arm: Start using fw_devlink_get_flags()

2020-03-04T16:58:48+00:00

The fw_devlink_get_flags() provides the right flags to use when creating mandatory device links derived from information provided by the firmware. So, use that. Acked-by: Ard Biesheuvel Signed-off-by: Saravana Kannan Link: https://lore.kernel.org/r/20200222014038.180923-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman

efi/arm: Move FDT specific definitions into fdtparams.c

2020-02-23T20:59:42+00:00

Push the FDT params specific types and definition into fdtparams.c, and instead, pass a reference to the memory map data structure and populate it directly, and return the system table address as the return value. Signed-off-by: Ard Biesheuvel

efi/arm: Drop unnecessary references to efi.systab

2020-02-23T20:59:42+00:00

Instead of populating efi.systab very early during efi_init() with a mapping that is released again before the function exits, use a local variable here. Now that we use efi.runtime to access the runtime services table, this removes the only reference efi.systab, so there is no need to populate it anymore, or discover its virtually remapped address. So drop the references entirely. Tested-by: Tony Luck # arch/ia64 Signed-off-by: Ard Biesheuvel

efi: Add 'runtime' pointer to struct efi

2020-02-23T20:59:42+00:00

Instead of going through the EFI system table each time, just copy the runtime services table pointer into struct efi directly. This is the last use of the system table pointer in struct efi, allowing us to drop it in a future patch, along with a fair amount of quirky handling of the translated address. Note that usually, the runtime services pointer changes value during the call to SetVirtualAddressMap(), so grab the updated value as soon as that call returns. (Mixed mode uses a 1:1 mapping, and kexec boot enters with the updated address in the system table, so in those cases, we don't need to do anything here) Tested-by: Tony Luck # arch/ia64 Signed-off-by: Ard Biesheuvel

efi/x86: Make fw_vendor, config_table and runtime sysfs nodes x86 specific

2020-02-23T20:59:42+00:00

There is some code that exposes physical addresses of certain parts of the EFI firmware implementation via sysfs nodes. These nodes are only used on x86, and are of dubious value to begin with, so let's move their handling into the x86 arch code. Tested-by: Tony Luck # arch/ia64 Signed-off-by: Ard Biesheuvel