u-boot.git/arch/arm/include/asm/arch-meson/boot.h, branch main

arm: meson: add support for EFI capsule updates

2025-12-11T16:27:15Z

Previously, few Amlogic devices supported EFI capsule updates. Generally only the Libre Computer ones with SPI flash supported it, thanks to board-specific code. This commit commonises capsule update support across supported Amlogic boards. Similar to Qualcomm's support for it, the dfu string and firmware name is automatically generated at runtime depending on which device we are booted from. Right now this supports flashing to the eMMC/SD and SPI flash. As usual, the capsule UUID is automatically generated. You can get it by enabling CONFIG_CMD_EFIDEBUG and running: => efidebug capsule esrt ======================================== ESRT: fw_resource_count=1 ESRT: fw_resource_count_max=1 ESRT: fw_resource_version=1 [entry 0]============================== ESRT: fw_class=796180D4-AAB2-50F1-B16A-53DFF9CA89B2 ESRT: fw_type=unknown ESRT: fw_version=0 ESRT: lowest_supported_fw_version=0 ESRT: capsule_flags=0 ESRT: last_attempt_version=0 ESRT: last_attempt_status=success ======================================== Reviewed-by: Evgeny Bachinin Reviewed-by: Neil Armstrong Signed-off-by: Ferass El Hafidi Link: https://patch.msgid.link/20251211-meson-capsule-v4-1-59f126ba4115@postmarketos.org Signed-off-by: Neil Armstrong

arch: arm: meson: support Amlogic chip_id v1 and v2

2025-03-18T14:27:25Z

Patch introduces: * chip_id API - useful for various things, but used now for device_id (did) generation as mentioned in [1] on our private board code. Our device_id is calculated by means of permutations of chip_id value. * new SoCs (a1, s4, etc) are usually coming with the support of chip_id v2 right away, whereas secure monitors on old SoCs (like axg, g12b, g12a, etc) may support only chip_id v1. Chip_id API handles both cases * meson_sm_get_serial() is described via chip_id API. Links: [1] https://lore.kernel.org/linux-arm-kernel/202311242104.RjBPI3uI-lkp@intel.com/T/#m630fbeea6a6e7d531290b5c0af205af4fb979757 Signed-off-by: Viacheslav Bocharov Co-developed-by: Arseniy Krasnov Signed-off-by: Arseniy Krasnov Signed-off-by: Evgeny Bachinin Link: https://lore.kernel.org/r/20250210-meson_chip_id_all_vers-v1-3-b98f8b6880b8@salutedevices.com Signed-off-by: Neil Armstrong

meson: Add soc_rev to environment

2021-01-11T13:59:54Z

Add SoC revision to environment. This can be useful to select the correct device tree at runtime (N2/N2+). Signed-off-by: Pascal Vizeli Signed-off-by: Stefan Agner Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong

ARM: meson: Add boot device discovery

2018-11-26T13:40:52Z

The Amlogic Meson SoCs ROM supports a boot over USB with a custom protocol. When no other boot medium are available (or by forcing the USB mode), the ROM sets the primary USB port as device mode and waits for a Host to enumerate. When enumerated, a custom protocol described at [1] permits writing to memory and execute some specific FIP init code to run the loaded Arm Trusted Firmware BL2 and BL3 stages before running the BL33 stage. In this mode, we can load different binaries that can be used by U-boot like a script image file. This adds support for a custom USB boot stage only available when the boot mode is USB and the script file at a pre-defined address is valid. This support was heavily copied from the Sunxi Allwinner FEL U-Boot support. The tool pyamlboot described at [2], permits using this boot mode on boards exposing the first USB port, either as OTG or Host port. [1] https://github.com/superna9999/pyamlboot/blob/master/PROTOCOL.md [2] https://github.com/superna9999/pyamlboot/blob/master/README.md Signed-off-by: Jerome Brunet Signed-off-by: Neil Armstrong