u-boot.git/arch/arm/lib, branch v2025.04

arm: riscv: efi: Export _start symbol from crt0_*_efi stubs

2025-03-17T08:22:03Z

While the _start label is only intended for use locally to populate the (hand-written) PE header, the linker script includes ENTRY(_start) which designates it as the entry point in the output ELF, resulting in linker warnings under some linkers (e.g. LLVM's lld) due to _start not being a globally-visible symbol. Since ELF is only an intermediary build format, and the aforementioned PE header correctly points to _start, the ENTRY(_start) directive could easily be removed to silence this warning. However, since some developers who are debugging EFI by analyzing the intermediary ELF may appreciate having correct entry-point information, this patch instead promotes the _start labels to global symbols, silencing the linker warning and making the intermediary ELF reflect the true entry point. This patch doesn't affect the final output binaries in any way. Signed-off-by: Sam Edwards

efi_loader: use include in ARM EFI linker script

2025-01-17T19:31:26Z

Use the same include as arm64 for the linker script. Adjust the 32-bit ARM PE-COFF header accordingly and harmonize it with the 64-bit ARM header. Reviewed-by: Ilias Apalodimas Signed-off-by: Heinrich Schuchardt

efi_loader: correct SizeOfCode, SizeOfInitializedData

2025-01-17T19:31:26Z

The fields SizeOfCode, SizeOfInitializedData, and SizeOfUninitializedData are define in the PE-COFF specification [1]. * SizeOfCode must match the size of all .text sections. * SizeOfInitializedData must match the size of all .data sections. * SizeOfUninitializedData must match the size of all .bss sections. We only have one .text and one .data section. SizeOfCode and SizeOfInitializedData have to be calculated as the difference between the end and the start of the respective section. As we don't have any .bss sections in the generated EFI binaries. SizeOfUninitializedData must remain 0. [1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format Reviewed-by: Ilias Apalodimas Signed-off-by: Heinrich Schuchardt

efi_loader: use INCLUDE in EFI linker scripts

2025-01-17T19:31:26Z

Except for the architecture specific lines ARM and RISC-V can use the same linker script. Move the common lines to an include. Reviewed-by: Ilias Apalodimas Signed-off-by: Heinrich Schuchardt

efi_loader: Fix section alignment on EFI binaries

2025-01-17T19:31:25Z

When creating EFI binaries, the alignment of the text section isn't correctly factored in. As a result trying to load signed EFI binaries throws an error with: efi_image_region_add() efi_image_region_add: new region already part of another Image not authenticated Running the binary through sbverify has a similar warning sbverify ./lib/efi_loader/helloworld.efi warning: gap in section table: .text : 0x00001000 - 0x00001c00, .data : 0x00002000 - 0x00002200, gaps in the section table may result in different checksums warning: data remaining[7680 vs 12720]: gaps between PE/COFF sections? ..... If we include the alignment in the text section, the signed binary boots fine, and the relevant sbverify warning goes away sbverify ./lib/efi_loader/helloworld.efi warning: data remaining[8704 vs 12720]: gaps between PE/COFF sections? ..... We should look into the remaining warning at some point as well regarding the gaps between PE/COFF sections. Signed-off-by: Ilias Apalodimas Reviewed-by: Heinrich Schuchardt

dm: Add dm_remove_devices_active() for ordered device removal

2024-11-24T21:41:28Z

This replaces dm_remove_devices_flags() calls in all boot implementations to ensure non vital devices are consistently removed first. All boot implementation except arch/arm/lib/bootm.c currently just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result in crashes when dependencies between devices exists. The driver model's design document describes DM_FLAG_VITAL as "indicates that the device is 'vital' to the operation of other devices". Device removal at boot should follow this. Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which does this. Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI boot. The xhci-pci (driver which depends on the IOMMU to work) removes its mapping on removal. This explodes when the IOMMU device was removed first. dm_remove_devices_flags() is kept since it is used for testing of device_remove() calls in dm. Signed-off-by: Janne Grunau

Merge patch series "Implement ACPI on aarch64"

2024-10-28T00:44:13Z

Patrick Rudolph says: Based on the existing work done by Simon Glass this series adds support for booting aarch64 devices using ACPI only. As first target QEMU SBSA support is added, which relies on ACPI only to boot an OS. As secondary target the Raspberry Pi4 was used, which is broadly available and allows easy testing of the proposed solution. The series is split into ACPI cleanups and code movements, adding Arm specific ACPI tables and finally SoC and mainboard related changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the mandatory ACPI tables are supported, allowing to boot into Linux without errors. The QEMU SBSA support is feature complete and provides the same functionality as the EDK2 implementation. The changes were tested on real hardware as well on QEMU v9.0: qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \ -pflash secure-world.rom \ -pflash unsecure-world.rom qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \ -smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \ -dtb bcm2711-rpi-4-b.dtb -nographic Tested against FWTS V24.03.00. Known issues: - The QEMU rpi4 support is currently limited as it doesn't emulate PCI, USB or ethernet devices! - The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly cache related). - PCI on RPI4 isn't working on real hardware since the pcie_brcmstb Linux kernel module doesn't support ACPI yet. Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com

arm: cpu: Add ACPI parking protocol support

2024-10-27T23:24:13Z

On Arm platforms that use ACPI they cannot rely on the "spin-table" CPU bringup usually defined in the FDT. Thus implement the 'ACPI Multi-processor Startup for ARM Platforms', also referred to as 'ACPI parking protocol'. The ACPI parking protocol works similar to the spin-table mechanism, but the specification also covers lots of shortcomings of the spin-table implementations. Every CPU defined in the ACPI MADT table has it's own 4K page where the spinloop code and the OS mailbox resides. When selected the U-Boot board code must make sure that the secondary CPUs enter u-boot after relocation as well, so that they can enter the spinloop code residing in the ACPI parking protocol pages. The OS will then write to the mailbox and generate an IPI to release the CPUs from the spinloop code. For now it's only implemented on ARMv8, but can easily be extended to other platforms, like ARMv7. TEST: Boots all CPUs on qemu-system-aarch64 -machine raspi4b Signed-off-by: Patrick Rudolph Reviewed-by: Simon Glass Cc: Simon Glass Cc: Tom Rini

drivers/arm: Implement acpi_fill_madt

2024-10-27T23:24:13Z

Fill the MADT table in the GIC driver and armv8 CPU driver to drop SoC specific code. While the GIC only needs devicetree data, the CPU driver needs additional information stored in the cpu_plat struct. While on it update the only board making use of the existing drivers and writing ACPI MADT in mainboard code. TEST: Booted on QEMU sbsa-ref using GICV3 driver model generated MADT. Booted on QEMU raspb4 using GICV2 driver model generated MADT. Signed-off-by: Patrick Rudolph Reviewed-by: Simon Glass Cc: Simon Glass

arm: lib: Add GICV2 driver

2024-10-27T23:24:13Z

Add a generic GICV2 driver that: - parses the DT and generates the ACPI MADT subtables - implement of_xlate() and allows irq_get_by_index() to return the correct interrupt mappings Map DT interrupts to ARM GIC interrupts as follows: - Interrupt numbers ID32-ID1019 are used for SPIs - ID0-ID15 are used for SGIs - ID16-ID31 are used for PPIs TEST: Booted on QEMU raspb4 using GICV2 driver model generated MADT. Signed-off-by: Patrick Rudolph Reviewed-by: Simon Glass