May 2024 - U-Boot

[PATCH 1/2] ARM: dts: stm32: add PWR regulators support on stm32mp131
by Marek Vasut 14 Jun '24

14 Jun '24

This patch adds STM32 PWR regulators DT support on stm32mp131. This requires TFA to clear RCC_SECCFGR, is disabled by default and can only be enabled on board DT level. Signed-off-by: Marek Vasut <marex(a)denx.de> --- Cc: Patrice Chotard <patrice.chotard(a)foss.st.com> Cc: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Cc: Tom Rini <trini(a)konsulko.com> Cc: u-boot(a)dh-electronics.com Cc: u-boot(a)lists.denx.de Cc: uboot-stm32(a)st-md-mailman.stormreply.com --- arch/arm/dts/stm32mp131.dtsi | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi index 81d99a7582b..ad331b73d18 100644 --- a/arch/arm/dts/stm32mp131.dtsi +++ b/arch/arm/dts/stm32mp131.dtsi @@ -1092,6 +1092,30 @@ <&scmi_clk CK_SCMI_LSI>; }; + pwr_regulators: pwr@50001000 { + compatible = "st,stm32mp1,pwr-reg"; + reg = <0x50001000 0x10>; + status = "disabled"; + + reg11: reg11 { + regulator-name = "reg11"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + }; + + reg18: reg18 { + regulator-name = "reg18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + usb33: usb33 { + regulator-name = "usb33"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + }; + exti: interrupt-controller@5000d000 { compatible = "st,stm32mp13-exti", "syscon"; interrupt-controller; -- 2.43.0

2 7

[PATCH v2] stm32mp: Reserve OPTEE area in EFI memory map
by Patrice Chotard 14 Jun '24

14 Jun '24

Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory") memory region above ram_top is tagged in EFI memory map as EFI_BOOT_SERVICES_DATA. In case of STM32MP1/STM32MP13 platforms, above ram_top, there is one reserved-memory region tagged "no-map" dedicated to OP-TEE : _ addr=de000000 size=2000000 for stm32mp157x-dkx and stm32mp135f-dk _ addr=fe000000 size=2000000 for stm32mp157c-ev1 Before booting kernel, EFI memory map is first built, the OPTEE region is tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE is used. Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions() which try to add again the same OPTEE region (addr=de000000 size=2000000 in case of stm32mp157x-dkx / stm32mp135f-dk or addr=fe000000 size=2000000 in case for stm2mp157c-ev1) but now with LMB_NOMAP tag which produces the following error message : _ for stm32mp157x-dkx / stm32mp135f-dk : "ERROR: reserving fdt memory region failed (addr=de000000 size=2000000 flags=4)" _ for stm32mp157c-ev1 : "ERROR: reserving fdt memory region failed (addr=fe000000 size=2000000 flags=4)" To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark it as reserved. Signed-off-by: Patrice Chotard <patrice.chotard(a)foss.st.com> --- Changes in v2: _ update commit message by adding information about memory area dedicated for OPTEE for various STM32MP1/STM32MP13 boards. arch/arm/mach-stm32mp/dram_init.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/arch/arm/mach-stm32mp/dram_init.c b/arch/arm/mach-stm32mp/dram_init.c index fb1208fc5d5..f67f54f2ae0 100644 --- a/arch/arm/mach-stm32mp/dram_init.c +++ b/arch/arm/mach-stm32mp/dram_init.c @@ -7,6 +7,7 @@ #include <common.h> #include <dm.h> +#include <efi_loader.h> #include <image.h> #include <init.h> #include <lmb.h> @@ -75,3 +76,14 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size) return reg + size; } + +void efi_add_known_memory(void) +{ + if (IS_ENABLED(CONFIG_EFI_LOADER)) + /* + * Memory over ram_top is reserved to OPTEE. + * Declare to EFI only memory area below ram_top + */ + efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base, + EFI_CONVENTIONAL_MEMORY); +} -- 2.25.1

3 2

[PATCH next v2 0/8] rockchip: px30: migrate to common bss and stack addresses and OF_UPSTREAM
by Quentin Schulz 14 Jun '24

14 Jun '24

Following up on migrating PX30 Ringneck to the new common bss and stack addresses as done in https://lore.kernel.org/u-boot/20240523-px30-2024-07-rc-v2-0-e46782d5520c@c… let's migrate all other px30 boards to this new memory layout so that it aligns with other Rockchip SoCs (TPL excluded). This also migrates all (but firefly-px30) PX30-based boards to use OF_UPSTREAM. firefly-px30 doesn't have an upstream kernel device tree so it is left untouched. All but Odroid-Go2 were straightforward to migrate. While at it, also fix a few issues related to UART on the PX30 Mini EVB I could test. This was boot tested on PX30 Ringneck and PX30 Mini EVB, U-Boot CLI and Linux kernel userspace are reached. This is based on next + https://lore.kernel.org/u-boot/20240523-px30-2024-07-rc-v2-0-e46782d5520c@c… To: Kever Yang <kever.yang(a)rock-chips.com> To: Tom Rini <trini(a)konsulko.com> To: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> To: Jagan Teki <jagan(a)amarulasolutions.com> To: Suniel Mahesh <sunil(a)amarulasolutions.com> To: Simon Glass <sjg(a)chromium.org> To: Philipp Tomsich <philipp.tomsich(a)vrull.eu> To: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> To: Klaus Goger <klaus.goger(a)theobroma-systems.com> Cc: u-boot(a)lists.denx.de Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> Changes in v2: - remove px30-base and ringneck patches, they were sent for master - migrate boards to OF_UPSTREAM - Link to v1: https://lore.kernel.org/r/20240521-px30-2024-07-rc-v1-0-62109c84d44f@cherry… independently: https://lore.kernel.org/u-boot/20240523-px30-2024-07-rc-v2-0-e46782d5520c@c… --- Quentin Schulz (8): rockchip: evb-px30: Use common bss and stack addresses rockchip: firefly-px30: Use common bss and stack addresses rockchip: odroid-go2: Use common bss and stack addresses rockchip: px30-core-*: Use common bss and stack addresses rockchip: px30: make UART pinmux accessible to TPL/SPL DTB rockchip: evb-px30: do not remove pinctrl nodes from SPL DTB rockchip: evb-px30: make UART5 the debug UART rockchip: px30/rk3326: migrate to OF_UPSTREAM arch/arm/dts/Makefile | 8 - arch/arm/dts/px30-engicam-common.dtsi | 129 ----- arch/arm/dts/px30-engicam-ctouch2.dtsi | 30 - arch/arm/dts/px30-engicam-edimm2.2.dtsi | 66 --- .../dts/px30-engicam-px30-core-ctouch2-of10.dts | 77 --- arch/arm/dts/px30-engicam-px30-core-ctouch2.dts | 22 - arch/arm/dts/px30-engicam-px30-core-edimm2.2.dts | 43 -- arch/arm/dts/px30-engicam-px30-core.dtsi | 241 -------- arch/arm/dts/px30-evb.dts | 634 -------------------- arch/arm/dts/px30-ringneck-haikou.dts | 232 -------- arch/arm/dts/px30-ringneck.dtsi | 382 ------------ arch/arm/dts/px30-u-boot.dtsi | 16 + arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 15 + arch/arm/dts/rk3326-odroid-go2.dts | 642 --------------------- arch/arm/mach-rockchip/Kconfig | 1 + configs/evb-px30_defconfig | 24 +- configs/firefly-px30_defconfig | 19 +- configs/odroid-go2_defconfig | 20 +- configs/px30-core-ctouch2-of10-px30_defconfig | 20 +- configs/px30-core-ctouch2-px30_defconfig | 20 +- configs/px30-core-edimm2.2-px30_defconfig | 20 +- configs/ringneck-px30_defconfig | 2 +- 22 files changed, 59 insertions(+), 2604 deletions(-) --- base-commit: 5e9aa577480ffbb6d3d0af6b972f227e087eef49 change-id: 20240508-px30-of_upstream-18bdbae87c98 Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

2 9

[PATCH] Fix typo in NVME show command
by Thomas Perl 13 Jun '24

13 Jun '24

Foramt -> Format Signed-off-by: Thomas Perl <m(a)thp.io> --- drivers/nvme/nvme_show.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/nvme_show.c b/drivers/nvme/nvme_show.c index 72cbac82bc..8dc03fe5bb 100644 --- a/drivers/nvme/nvme_show.c +++ b/drivers/nvme/nvme_show.c @@ -68,7 +68,7 @@ static void print_formats(struct nvme_id_ns *id, struct nvme_ns *ns) printf("Blk device %d: LBA Format Support:\n", ns->devnum); for (i = 0; i < id->nlbaf; i++) { - printf("\tLBA Foramt %d Support: ", i); + printf("\tLBA Format %d Support: ", i); if (i == ns->flbas) printf("(current)\n"); else -- 2.45.0

2 1

[PATCH v2 0/7] Add AVS support for J721S2
by Manorit Chawdhry 13 Jun '24

13 Jun '24

This series adds support for AVS on J721S2. AVS Test for J721S2: https://gist.github.com/manorit2001/d7690ded6ef685aa8ffa5b16746cc529 Boot Test results: https://gist.github.com/manorit2001/6775d721b3df5a690497d94d012b93c4 Signed-off-by: Manorit Chawdhry <m-chawdhry(a)ti.com> --- Changes in v2: - Move AVS Initialization point to after do_dt_magic ( Otherwise AM68 unknowingly ends up probing AVS and fails ) - Rebase on top of OF_UPSTREAM Support - Link to v1: https://lore.kernel.org/r/20240206-b4-upstream-j721s2-avs-v1-0-b75043c59969… --- Manorit Chawdhry (7): power: pmic: tps65941: Add DM_PMIC dependency drivers: misc: k3_avs: Use soc_match_device instead of compatible. drivers: misc: k3_avs: Check return code while programming AVS drivers: misc: k3_avs: Add AVS Support for J721S2. arm: mach-k3: j721s2_init: Initialize AVS Class 0 arm: dts: j721s2: Add VTM node in R5 configs: j721s2_evm_r5_defconfig: Add AVS Configs arch/arm/dts/k3-j721s2-r5-common-proc-board.dts | 9 + arch/arm/mach-k3/j721s2/j721s2_init.c | 10 ++ configs/am68_sk_r5_defconfig | 4 + configs/j721s2_evm_r5_defconfig | 6 + drivers/misc/k3_avs.c | 216 ++++++++++++++---------- drivers/power/pmic/Kconfig | 1 + 6 files changed, 159 insertions(+), 87 deletions(-) --- base-commit: 377e91c162ab09ec20f96f966f380cb55c590edd change-id: 20240130-b4-upstream-j721s2-avs-8c187d3fe26a Best regards, -- Manorit Chawdhry <m-chawdhry(a)ti.com>

4 12

[PATCH v2 0/4] Generate capsules from config files
by Sughosh Ganu 11 Jun '24

11 Jun '24

Add support for generating capsules through a config file. Multiple capsules can be generated through a single invocation of the mkeficapsule tool, where the capsule parameters are fetched from the config file. The format of the config file pretty similar to the one used by the capsule generation tool in EDKII. The functionality is enabled on the sandbox variant and the EFI capsule update test is now configured to generate the capsules through a config file. The sandbox_flattree variant generates capsules through binman, thus covering both the paths. This is a rebased version of the earlier patch series that was sent to the mailing list [1]. That series was not getting merged as Simon had asked for generation of capsules as part of the sandbox platform build. Those patches have since been merged. Moreover, there has been adoption of the capsule generation logic by TI platforms as well, so that should address the concern which Tom had about it's usage. These patches are more of a step in the direction of adding support for generation of a multi-payload capsule. There has been a request for it's support for a platform [2]. [1] - https://lists.denx.de/pipermail/u-boot/2023-November/538223.html [2] - https://lists.denx.de/pipermail/u-boot/2024-March/548126.html Sughosh Ganu (4): tools: mkeficapsule: Add support for parsing capsule params from config file doc: Document capsule generation through a config file sandbox: capsule: Add a config file for generating capsules test: capsule: Generate capsules through config file configs/sandbox_defconfig | 2 + doc/develop/uefi/uefi.rst | 70 ++++ .../test_efi_capsule/capsule_gen_binman.dts | 2 + test/py/tests/test_efi_capsule/conftest.py | 7 + .../test_efi_capsule/sandbox_capsule_cfg.txt | 73 ++++ tools/Kconfig | 15 + tools/Makefile | 1 + tools/eficapsule.h | 114 ++++++ tools/mkeficapsule.c | 87 +++-- tools/mkeficapsule_parse.c | 352 ++++++++++++++++++ 10 files changed, 692 insertions(+), 31 deletions(-) create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt create mode 100644 tools/mkeficapsule_parse.c -- 2.34.1

3 9

Proposal: U-Boot memory management
by Simon Glass 11 Jun '24

11 Jun '24

Hi, This records my thoughts after a discussion with Ilias & Heinrich re memory allocation in U-Boot. 1. malloc() malloc() is used for programmatic memory allocation. It allows memory to be freed. It is not designed for very large allocations (e.g. a 10MB kernel or 100MB ramdisk). 2. lmb lmb is used for large blocks of memory, such as those needed for a kernel or ramdisk. Allocation is only transitory, for the purposes of loading some images and booting. If the boot fails, then all lmb allocations go away. lmb is set up by getting all available memory and then removing what is used by U-Boot (code, data, malloc() space, etc.) lmb reservations have a few flags so that areas of memory can be provided with attributes There are some corner cases...e.g. loading a file does an lmb allocation but only for the purpose of avoiding a file being loaded over U-Boot code/data. The allocation is dropped immediately after the file is loaded. Within the bootm command, or when using standard boot, this would be fairly easy to solve. Linux has renamed lmb to memblock. We should consider doing the same. 3. EFI EFI has its own memory-allocation tables. Like lmb, EFI is able to deal with large allocations. But via a 'pool' function it can also do smaller allocations similar to malloc(), although each one uses at least 4KB at present. EFI allocations do not go away when a boot fails. With EFI it is possible to add allocations post facto, in which case they are added to the allocation table just as if the memory was allocated with EFI to begin with. The EFI allocations and the lmb allocations use the same memory, so in principle could conflict. EFI allocations are sometimes used to allocate internal U-Boot data as well, if needed by the EFI app. For example, while efi_image_parse() uses malloc(), efi_var_mem.c uses EFI allocations since the code runs in the app context and may need to access the memory after U-Boot has exited. Also efi_smbios.c uses allocate_pages() and then adds a new mapping as well. EFI memory has attributes, including what the memory is used for (to some degree of granularity). See enum efi_memory_type and struct efi_mem_desc. In the latter there are also attribute flags - whether memory is cacheable, etc. EFI also has the x86 idea of 'conventional' memory, meaning (I believe) that below 4GB that isn't reserved for the hardware/system. This is meaningless, or at least confusing, on ARM systems. 4. reservations It is perhaps worth mentioning a fourth method of memory management, where U-Boot reserves chunks of memory before relocation (in board_init_f.c), e.g. for the framebuffer, U-Boot code, the malloc() region, etc. Problems —------- There are no urgent problems, but here are some things that could be improved: 1. EFI should attach most of its data structures to driver model. This work has started, with the partition support, but more effort would help. This would make it easier to see which memory is related to devices and which is separate. 2. Some drivers do EFI reservations today, whether EFI is used for booting or not (e.g. rockchip video rk_vop_probe()). 3. U-Boot doesn't really map arch-specific memory attributes (e.g. armv8's struct mm_region) to EFI ones. 4. EFI duplicates some code from bootm, some of which relates to memory allocation (e.g. FDT fixup). 5. EFI code is used even if EFI is never used to boot 6. EFI allocations can result in the same memory being used as has already been allocated by lmb. Users may load files which overwrite memory allocated by EFI. Lifetime -------- We have three different memory allocators with different purposes. Can we unify them a little? Within U-Boot: - malloc() space lives forever - lmb lives while setting out images for booting - EFI (mostly) lives while booting an EFI app In practice, EFI is set up early in U-Boot. Some of this is necessary, some not. EFI allocations stay around forever. This works OK since large allocations are normally not done in EFI, so memory isn't really consumed to any great degree by the boot process. What happens to EFI allocations if the app returns? They are still present, in case another app is run. This seems fine. API –-- Can we unify some APIs? It should be possible to use lmb for large EFI memory allocations, so long as they are only needed for booting. We effectively do this today, since EFI does not manage the arrangement of loaded images in memory. for the most part. It would not make sense to use EFI allocation to replace lmb and malloc(), of course. Could we use a common (lower-level) API for allocation, used by both lmb and EFI? They do have some similarities. However they have different lifetime constraints (EFI allocations are never dropped, unlikely lmb). ** Overall, it seems that the existence of memory allocation in boot-time services has created confusion. Memory allocation is muddled, with both U-Boot code and boot-time services calling the same memory allocator. This just has not been clearly thought out. Proposal —------- Here are some ideas: 1. For video, use the driver model API to locate the video regions, or block off the entire framebuffer memory, for all devices as a whole. Use efi_add_memory_map() 2. Add memory attributes to UCLASS_RAM and use them in EFI, mapping to the EFI_MEMORY_... attributes in struct efi_mem_desc. 3. Add all EFI reservations just before booting the app, as we do with devicetree fixup. With this model, malloc() and lmb are used for all allocation. Then efi_add_memory_map() is called for each region in turn just before booting. Memory attributes are dealt with above. The type (enum efi_memory_type) can be determined simply by the data structure stored in it, as is done today. For example, SMBIOS tables can use EFI_ACPI_RECLAIM_MEMORY. Very few types are used and EFI code understands the meaning of each. 4. Avoid setting up EFI memory at the start of U-Boot. Do it only when booting. This looks to require very little effort. 5. Avoid calling efi_allocate_pages() and efi_allocate_pool() outside boot-time services. This solves the problem 6. If memory is needed by an app, allocate it with malloc() and see 3. There are only two efi_allocate_pages() (smbios and efi_runtime). There are more calls of efi_allocate_pool(), but most of these seem easy to fix up. For example, efi_init_event_log() allocates a buffer, but this can be allocated in normal malloc() space or in a bloblist. 6. Don't worry too much about whether EFI will be used for booting. The cost is likely not that great: use bootstage to measure it as is done for driver model. Try to minmise the cost of its tables, particularly for execution time, but otherwise just rely on the ability to disable EFI_LOADER. – Regards, Simon

6 51

[PATCH 0/7] MIPS: Enable EFI support
by Jiaxun Yang 11 Jun '24

11 Jun '24

Hi all, This series enabled EFI support to MIPS platform. Although MIPS is not defined by UEFI specification, there are quite a few firmware implementations available, including MIPS-EFI[1] for Loongson-2F, Lemote's proprietary EDK2 implementation on Loongson-3[2], Kunlun firmware for Loongson-3[3], efiffy[4] for MIPS Creator CI20 and another mystery EDK implementation shipped with some Creator CI20 board. Available applications including gnu-efi, Loongson's GRUB fork[5], Ventoy[6]. My implementation in U-Boot is aiming to follow conventions made by other implementations for architecture stuff and remain compliance with spec for general aspects. bootefi hello and selftest passed on both 32 and 64 bit system, gnu-efi, grub and ventoy are tested on mips64el with my pending platform works. mips32el efi executable from efiffy is tested as well. Please review. Thanks [1]: https://github.com/kontais/EFI-MIPS [2]: https://github.com/loongson-community/firmware-nonfree [3]: http://www.kunluntech.com.cn/klbiosxl [4]: https://sourceforge.net/projects/efify/ [5]: https://github.com/loongson-community/grub [6]: https://www.ventoy.net/en/index.html Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Jiaxun Yang (7): MIPS: Implement setjmp efi: Allow runtime relocate to be disabled Makefile.lib: Preserve .rodata section for EFI file Makefile.lib: Enforce EFI CFLAGS/AFLAGS MIPS: Add smbios_start to arch_global_data MIPS: Define MIPS EFI related bits everywhere MIPS: Implement EFI supporting stuff Makefile | 3 + arch/mips/config.mk | 9 + arch/mips/include/asm/global_data.h | 3 + arch/mips/include/asm/setjmp.h | 36 ++++ arch/mips/lib/Makefile | 15 ++ arch/mips/lib/crt0_mips_efi.S | 239 ++++++++++++++++++++++ arch/mips/lib/elf_mips_efi.lds | 113 ++++++++++ arch/mips/lib/reloc_mips_efi.c | 99 +++++++++ arch/mips/lib/setjmp32.S | 51 +++++ arch/mips/lib/setjmp64.S | 56 +++++ include/asm-generic/pe.h | 5 + include/config_distro_bootcmd.h | 6 + include/efi_default_filename.h | 8 + include/efi_loader.h | 26 ++- include/elf.h | 8 + lib/efi_loader/Kconfig | 12 +- lib/efi_loader/efi_image_loader.c | 18 ++ lib/efi_loader/efi_memory.c | 14 +- lib/efi_loader/efi_runtime.c | 11 +- lib/efi_loader/efi_var_mem.c | 6 +- lib/efi_selftest/Makefile | 2 +- lib/efi_selftest/efi_selftest_miniapp_exception.c | 2 + scripts/Makefile.lib | 10 +- 23 files changed, 734 insertions(+), 18 deletions(-) --- base-commit: ad7dce5abd49ef3b5c93da5303e15449c8c162b4 change-id: 20240517-mips-efi-c9a1ad819c2d Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

4 27

[PATCH 00/13] Arm64 big endian enablement
by Jiaxun Yang 11 Jun '24

11 Jun '24

Hi all, This series enabled big endian support for arm64, enabled qemu-arm board for arm64be and slightly adjusted our Kconfig handling on endianness. In practical I think most Arm SoCs do support little endian only, for those SoCs with big endian support they are usually bi-endian and expected bootloader in little endian. The only big-endian only Arm SoC I know is a network processor from ZTE ZXIC, I doubt if upstream U-Boot will ever support it. However enabling arm64be can enable us to take more care on big endian targets, given that arm64 is the most feature rich arch in U-Boot, we can run more test on big endian systems. Boot tested on qemu. Please review. Thanks Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Jiaxun Yang (13): tools/relocate-rela: Fix Big Endian elf64 handling arm: Don't select ARM_ASM_UNIFIED on arm64 arm: Fix assembler.h for arm64 arm: Introduce CPU_LE/CPU_BE macros arm: Define endian related bits in system.h armv8: Big Endian enablement for compiler and linker arm: Perform byte swap for read and write in io.h armv8: Allow endianness to be setted at reset entry armv8: spin_table: Perform byte swap for jump address lib/crc32: Don't perform byte swap for arm64 crc32b Kconfig: Unify endian support option config: Use CONFIG_SYS_BIG_ENDIAN in code whenever possible qemu-arm: Big endian enablement for arm64 Makefile | 2 +- arch/Kconfig | 34 ++++++++--- arch/arc/include/asm/arc-bcr.h | 10 +-- arch/arm/Kconfig | 3 +- arch/arm/config.mk | 14 +++++ arch/arm/cpu/armv8/Kconfig | 9 +++ .../arm/cpu/armv8/linux-kernel-image-header-vars.h | 4 +- arch/arm/cpu/armv8/spin_table_v8.S | 2 + arch/arm/cpu/armv8/start.S | 26 ++++++++ arch/arm/cpu/armv8/u-boot-spl.lds | 6 ++ arch/arm/cpu/armv8/u-boot.lds | 4 ++ arch/arm/include/asm/assembler.h | 25 ++++++++ arch/arm/include/asm/io.h | 12 ++-- arch/arm/include/asm/system.h | 3 + arch/arm/lib/elf_aarch64_efi.lds | 7 +++ arch/mips/Kconfig | 20 +++--- arch/mips/mach-ath79/Kconfig | 8 +-- arch/mips/mach-bmips/Kconfig | 20 +++--- arch/mips/mach-jz47xx/Kconfig | 2 +- arch/mips/mach-mscc/Kconfig | 4 +- arch/mips/mach-pic32/Kconfig | 2 +- board/emulation/qemu-arm/Kconfig | 2 + board/emulation/qemu-arm/MAINTAINERS | 1 + configs/qemu_arm64be_defconfig | 71 ++++++++++++++++++++++ doc/board/emulation/qemu-arm.rst | 7 ++- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 2 +- lib/crc32.c | 3 +- scripts/Makefile.build | 2 +- scripts/Makefile.lib | 3 +- tools/relocate-rela.c | 40 +++++++----- 30 files changed, 271 insertions(+), 77 deletions(-) --- base-commit: 3be9f399e911cfc437a37ac826441f1d96da1c9b change-id: 20240518-aarch64-be-1ec99cf7f28b Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

2 14

[PATCH 0/4] arm64: versal2: Add support for new AMD Versal Gen 2 SoC
by Michal Simek 11 Jun '24

11 Jun '24

Hi, I am sending patches for adding initial support for new AMD Versal Gen 2 SoC. If you want to find out more information please take a look at this page: https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal.html Thanks, Michal Michal Simek (4): arm64: versal2: Add support for AMD Versal Gen 2 soc: versal2: Add SoC driver for AMD Versal Gen 2 mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2 spi: versal2: Enable spi drivers for Versal Gen 2 arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/amd-versal2-virt.dts | 11 + arch/arm/mach-versal2/Kconfig | 55 +++ arch/arm/mach-versal2/Makefile | 10 + arch/arm/mach-versal2/clk.c | 34 ++ arch/arm/mach-versal2/cpu.c | 93 +++++ arch/arm/mach-versal2/include/mach/hardware.h | 97 +++++ .../arm/mach-versal2/include/mach/sys_proto.h | 9 + board/amd/common | 1 + board/amd/versal2/Kconfig | 16 + board/amd/versal2/MAINTAINERS | 7 + board/amd/versal2/Makefile | 11 + board/amd/versal2/board.c | 343 ++++++++++++++++++ board/amd/versal2/cmds.c | 81 +++++ board/xilinx/Kconfig | 6 +- configs/amd_versal2_virt_defconfig | 150 ++++++++ drivers/gpio/Kconfig | 2 +- drivers/mailbox/Kconfig | 2 +- drivers/mmc/zynq_sdhci.c | 22 +- drivers/soc/Kconfig | 8 + drivers/soc/Makefile | 1 + drivers/soc/soc_amd_versal2.c | 77 ++++ drivers/spi/Kconfig | 2 +- drivers/spi/cadence_qspi.c | 3 +- drivers/spi/zynqmp_gqspi.c | 6 +- env/Kconfig | 6 +- include/configs/amd_versal2.h | 143 ++++++++ 29 files changed, 1193 insertions(+), 20 deletions(-) create mode 100644 arch/arm/dts/amd-versal2-virt.dts create mode 100644 arch/arm/mach-versal2/Kconfig create mode 100644 arch/arm/mach-versal2/Makefile create mode 100644 arch/arm/mach-versal2/clk.c create mode 100644 arch/arm/mach-versal2/cpu.c create mode 100644 arch/arm/mach-versal2/include/mach/hardware.h create mode 100644 arch/arm/mach-versal2/include/mach/sys_proto.h create mode 120000 board/amd/common create mode 100644 board/amd/versal2/Kconfig create mode 100644 board/amd/versal2/MAINTAINERS create mode 100644 board/amd/versal2/Makefile create mode 100644 board/amd/versal2/board.c create mode 100644 board/amd/versal2/cmds.c create mode 100644 configs/amd_versal2_virt_defconfig create mode 100644 drivers/soc/soc_amd_versal2.c create mode 100644 include/configs/amd_versal2.h -- 2.40.1

2 9