December 2024 - U-Boot

[PATCH 0/7] board: rockchip: add FriendlyElec NanoPi R3S
by Tianling Shen 15 Jan '25

15 Jan '25

The NanoPi R3S(as "R3S") is an open source platform with dual-Gbps Ethernet ports designed and developed by FriendlyElec for IoT applications. Tianling Shen (7): arm64: dts: rockchip: Add FriendlyARM NanoPi R3S board arm64: dts: rockchip: fix model name for FriendlyElec NanoPi R3S arm64: dts: rockchip: replace deprecated snps,reset props for NanoPi R3S arm64: dts: rockchip: sort props in pmu_io_domains node for NanoPi R3S arm64: dts: rockchip: enable eMMC HS200 mode for NanoPi R3S arm64: dts: rockchip: reorder mmc aliases for NanoPi R3S board: rockchip: add FriendlyElec NanoPi R3S arch/arm/dts/rk3566-nanopi-r3s-u-boot.dtsi | 8 + board/rockchip/evb_rk3568/MAINTAINERS | 7 + configs/nanopi-r3s-rk3566_defconfig | 74 +++ doc/board/rockchip/rockchip.rst | 1 + .../src/arm64/rockchip/rk3566-nanopi-r3s.dts | 554 ++++++++++++++++++ 5 files changed, 644 insertions(+) create mode 100644 arch/arm/dts/rk3566-nanopi-r3s-u-boot.dtsi create mode 100644 configs/nanopi-r3s-rk3566_defconfig create mode 100644 dts/upstream/src/arm64/rockchip/rk3566-nanopi-r3s.dts -- 2.47.0

3 23

[PATCH 1/2] board: phytec: common: Add product information to FTD
by Daniel Schultz 15 Jan '25

15 Jan '25

ft_board_setup inside the board code allows to alter device-tree during the boot process. Introduce a new function for the PHYTEC SOM detection to read the product name and part number from the EEPROM content and include both into the device-tree as * phytec,som-part-number * phytec,som-product-name This function can be called from the board code when those values should be exposed to Linux. Signed-off-by: Daniel Schultz <d.schultz(a)phytec.de> --- board/phytec/common/phytec_som_detection.c | 204 ++++++++++++++++----- board/phytec/common/phytec_som_detection.h | 7 + 2 files changed, 168 insertions(+), 43 deletions(-) diff --git a/board/phytec/common/phytec_som_detection.c b/board/phytec/common/phytec_som_detection.c index 166c3eae565..ea439be5163 100644 --- a/board/phytec/common/phytec_som_detection.c +++ b/board/phytec/common/phytec_som_detection.c @@ -271,11 +271,126 @@ err: return ret; } +static int phytec_get_product_name(struct phytec_eeprom_data *data, + char *product) +{ + struct phytec_api2_data *api2; + unsigned int ksp_no, som_type; + int len; + + if (!data) + data = &eeprom_data; + + if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2) + return -EINVAL; + + api2 = &data->payload.data.data_api2; + + if (api2->som_type > 1 && api2->som_type <= 3) { + ksp_no = (api2->ksp_no << 8) | api2->som_no; + len = snprintf(product, PHYTEC_PRODUCT_NAME_LEN, "%s-%04u", + phytec_som_type_str[api2->som_type], ksp_no); + if (len != 8) + return -1; + return 0; + } + + switch (api2->som_type) { + case 0: + som_type = api2->som_type; + break; + case 4: + som_type = 0; + break; + case 5: + som_type = 0; + break; + case 6: + som_type = 1; + break; + case 7: + som_type = 1; + break; + default: + pr_err("%s: Invalid SOM type: %i", __func__, api2->som_type); + return -EINVAL; + }; + + len = snprintf(product, PHYTEC_PRODUCT_NAME_LEN, "%s-%03u", + phytec_som_type_str[som_type], api2->som_no); + if (len != 7) + return -1; + return 0; +} + +static int phytec_get_part_number(struct phytec_eeprom_data *data, + char *part) +{ + char product_name[PHYTEC_PRODUCT_NAME_LEN] = {'\0'}; + struct phytec_api2_data *api2; + unsigned int ksp_type; + int res, len; + + if (!data) + data = &eeprom_data; + + if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2) + return -EINVAL; + + api2 = &data->payload.data.data_api2; + + res = phytec_get_product_name(data, product_name); + if (res) + return res; + + if (api2->som_type <= 1) { + len = snprintf(part, PHYTEC_PART_NUMBER_LEN, "%s-%s.%s", + product_name, api2->opt, api2->bom_rev); + if (len < 11) + return -1; + return 0; + } + if (api2->som_type <= 3) { + snprintf(part, PHYTEC_PART_NUMBER_LEN, "%s.%s", product_name, + api2->bom_rev); + if (len != 11) + return -1; + return 0; + } + + switch (api2->som_type) { + case 4: + ksp_type = 3; + break; + case 5: + ksp_type = 2; + break; + case 6: + ksp_type = 3; + break; + case 7: + ksp_type = 2; + break; + default: + pr_err("%s: Invalid SOM type: %i", __func__, api2->som_type); + return -EINVAL; + }; + + len = snprintf(part, PHYTEC_PART_NUMBER_LEN, "%s-%s%02u.%s", + product_name, phytec_som_type_str[ksp_type], + api2->ksp_no, api2->bom_rev); + if (len < 16) + return -1; + + return 0; +} + void __maybe_unused phytec_print_som_info(struct phytec_eeprom_data *data) { + char part_number[PHYTEC_PART_NUMBER_LEN] = {'\0'}; struct phytec_api2_data *api2; char pcb_sub_rev; - unsigned int ksp_no, sub_som_type1, sub_som_type2; + int res; if (!data) data = &eeprom_data; @@ -289,50 +404,14 @@ void __maybe_unused phytec_print_som_info(struct phytec_eeprom_data *data) pcb_sub_rev = api2->pcb_sub_opt_rev & 0x0f; pcb_sub_rev = pcb_sub_rev ? ((pcb_sub_rev - 1) + 'a') : ' '; - /* print standard product string */ - if (api2->som_type <= 1) { - printf("SoM: %s-%03u-%s.%s PCB rev: %u%c\n", - phytec_som_type_str[api2->som_type], api2->som_no, - api2->opt, api2->bom_rev, api2->pcb_rev, pcb_sub_rev); + res = phytec_get_part_number(data, part_number); + if (res) return; - } - /* print KSP/KSM string */ - if (api2->som_type <= 3) { - ksp_no = (api2->ksp_no << 8) | api2->som_no; - printf("SoM: %s-%u ", - phytec_som_type_str[api2->som_type], ksp_no); - /* print standard product based KSP/KSM strings */ - } else { - switch (api2->som_type) { - case 4: - sub_som_type1 = 0; - sub_som_type2 = 3; - break; - case 5: - sub_som_type1 = 0; - sub_som_type2 = 2; - break; - case 6: - sub_som_type1 = 1; - sub_som_type2 = 3; - break; - case 7: - sub_som_type1 = 1; - sub_som_type2 = 2; - break; - default: - pr_err("%s: Invalid SoM type: %i", __func__, api2->som_type); - return; - }; - - printf("SoM: %s-%03u-%s-%03u ", - phytec_som_type_str[sub_som_type1], - api2->som_no, phytec_som_type_str[sub_som_type2], - api2->ksp_no); - } - printf("Option: %s BOM rev: %s PCB rev: %u%c\n", api2->opt, - api2->bom_rev, api2->pcb_rev, pcb_sub_rev); + printf("SOM: %s\n", part_number); + printf("PCB Rev.: %u%c\n", api2->pcb_rev, pcb_sub_rev); + if (api2->som_type > 1) + printf("Options: %s\n", api2->opt); } char * __maybe_unused phytec_get_opt(struct phytec_eeprom_data *data) @@ -379,6 +458,38 @@ u8 __maybe_unused phytec_get_som_type(struct phytec_eeprom_data *data) return data->payload.data.data_api2.som_type; } +#if IS_ENABLED(CONFIG_OF_LIBFDT) +int phytec_ft_board_fixup(struct phytec_eeprom_data *data, void *blob, + struct bd_info *bd) +{ + char product_name[PHYTEC_PRODUCT_NAME_LEN] = {'\0'}; + char part_number[PHYTEC_PART_NUMBER_LEN] = {'\0'}; + int res; + + if (!data) + data = &eeprom_data; + + if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2) + return -EINVAL; + + res = phytec_get_product_name(data, product_name); + if (res) + return res; + + fdt_setprop(blob, 0, "phytec,som-product-name", product_name, + strlen(product_name) + 1); + + res = phytec_get_part_number(data, part_number); + if (res) + return res; + + fdt_setprop(blob, 0, "phytec,som-part-number", part_number, + strlen(part_number) + 1); + + return 0; +} +#endif /* IS_ENABLED(CONFIG_OF_LIBFDT) */ + #if IS_ENABLED(CONFIG_CMD_EXTENSION) struct extension *phytec_add_extension(const char *name, const char *overlay, const char *other) @@ -458,6 +569,13 @@ inline struct phytec_api3_element * __maybe_unused return NULL; } +#if IS_ENABLED(CONFIG_OF_LIBFDT) +inline int phytec_ft_board_fixup(struct phytec_eeprom_data *data, void *blob, + struct bd_info *bd) +{ + return 0; +} +#endif /* IS_ENABLED(CONFIG_OF_LIBFDT) */ #if IS_ENABLED(CONFIG_CMD_EXTENSION) inline struct extension *phytec_add_extension(const char *name, const char *overlay, diff --git a/board/phytec/common/phytec_som_detection.h b/board/phytec/common/phytec_som_detection.h index 5e35a13cb21..db232cdec48 100644 --- a/board/phytec/common/phytec_som_detection.h +++ b/board/phytec/common/phytec_som_detection.h @@ -8,6 +8,7 @@ #define _PHYTEC_SOM_DETECTION_H #include "phytec_som_detection_blocks.h" +#include <fdtdec.h> #define PHYTEC_MAX_OPTIONS 17 #define PHYTEC_EEPROM_INVAL 0xff @@ -17,6 +18,9 @@ #define PHYTEC_GET_OPTION(option) \ (((option) > '9') ? (option) - 'A' + 10 : (option) - '0') +#define PHYTEC_PRODUCT_NAME_LEN 8 + 1 +#define PHYTEC_PART_NUMBER_LEN PHYTEC_PRODUCT_NAME_LEN + 14 + 1 + enum { PHYTEC_API_REV0 = 0, PHYTEC_API_REV1, @@ -86,6 +90,9 @@ void __maybe_unused phytec_print_som_info(struct phytec_eeprom_data *data); char * __maybe_unused phytec_get_opt(struct phytec_eeprom_data *data); u8 __maybe_unused phytec_get_rev(struct phytec_eeprom_data *data); u8 __maybe_unused phytec_get_som_type(struct phytec_eeprom_data *data); +#if IS_ENABLED(CONFIG_OF_LIBFDT) +int phytec_ft_board_fixup(struct phytec_eeprom_data *data, void *blob, struct bd_info *bd); +#endif /* IS_ENABLED(CONFIG_OF_LIBFDT) */ #if IS_ENABLED(CONFIG_CMD_EXTENSION) struct extension *phytec_add_extension(const char *name, const char *overlay, -- 2.25.1

3 4

[PATCH] chromebook_coral: Move CONFIG_BLOBLIST_ADDR to CAR
by Tom Rini 14 Jan '25

14 Jan '25

Reading doc/board/google/chromebook_coral.rst we can see that at some point it was intended to put the bloblist in CAR, rather than DRAM, at some point during development. This is fine for TPL/SPL stages where we have very minimal information stored in the bloblist and so we can set the limit there to 4KiB and then expand it to 196KiB in U-Boot proper so there's room for ACPI tables and so forth. We also update the documentation to use the same location for CONFIG_BLOBLIST_ADDR in both references. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- Looking at https://source.denx.de/u-boot/u-boot/-/jobs/978027 this brings Coral back to just having the known TPM issue to resolve wrt test cases. Cc: Simon Glass <sjg(a)chromium.org> --- configs/chromebook_coral_defconfig | 5 +++-- doc/board/google/chromebook_coral.rst | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/configs/chromebook_coral_defconfig b/configs/chromebook_coral_defconfig index 0fb730497386..b4f7e61ad0d4 100644 --- a/configs/chromebook_coral_defconfig +++ b/configs/chromebook_coral_defconfig @@ -2,6 +2,7 @@ CONFIG_X86=y CONFIG_TEXT_BASE=0x1110000 CONFIG_SYS_MALLOC_LEN=0x2000000 CONFIG_SYS_MALLOC_F_LEN=0x3d00 +CONFIG_BLOBLIST_SIZE_RELOC=0x30000 CONFIG_NR_DRAM_BANKS=8 CONFIG_MAX_CPUS=8 CONFIG_SPL_DM_SPI=y @@ -44,8 +45,8 @@ CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BLOBLIST=y # CONFIG_TPL_BLOBLIST is not set -CONFIG_BLOBLIST_ADDR=0x100000 -CONFIG_BLOBLIST_SIZE=0x30000 +CONFIG_BLOBLIST_ADDR=0xfef10000 +CONFIG_BLOBLIST_SIZE=0x1000 CONFIG_SPL_NO_BSS_LIMIT=y CONFIG_HANDOFF=y CONFIG_SPL_SEPARATE_BSS=y diff --git a/doc/board/google/chromebook_coral.rst b/doc/board/google/chromebook_coral.rst index 1eda769c7528..b48afb279386 100644 --- a/doc/board/google/chromebook_coral.rst +++ b/doc/board/google/chromebook_coral.rst @@ -243,7 +243,7 @@ board_init_r(), as per the rules, and DRAM is available then. SPL sets up a bloblist and passes the SPL hand-off information to U-Boot proper. This includes a pointer to the HOB list as well as DRAM information. See struct arch_spl_handoff. The bloblist address is set by CONFIG_BLOBLIST_ADDR, -normally 100000. +normally fef10000. SPL uses SPI flash to update the MRC caches in ROM. This speeds up subsequent boots. Be warned that SPL can take 30 seconds without this cache! This is a -- 2.43.0

1 1

[PATCH v3 00/10] SMBIOS improvements
by Raymond Mao 14 Jan '25

14 Jan '25

Motivations for changes: Current SMBIOS library and command-line tool is not fully matching with the requirements: 1. Missing support for other mandatory types (#7, #9, #16, #17, #19). 2. Only a few platforms support SMBIOS node from the device tree. 3. Values of some fields are hardcoded in the library other than fetching from the device hardware. 4. Embedded data with dynamic length is not supported (E.g. Contained Object Handles in Type #2 and Contained Elements in Type #3) Changes: 1. Refactor the SMBIOS library and command-line tool to better align with the SMBIOS spec. 2. Create an arch-specific driver for all aarch64-based platforms to fetch SMBIOS private data from the device hardware (processor and cache). 3. Create a sysinfo driver to poppulate platform SMBIOS private data. 4. Add generic SMBIOS DTS file for arm64 platforms for those common strings and values which cannot be retrieved from the system registers. Vendors can create their own SMBIOS node using this as an example. For those boards without SMBIOS nodes, this DTS file can be included to have a generic SMBIOS information of the system. 5. Add support for Type #7 (Cache Information) and link its handles to Type #4. 6. To minimize size-growth for those platforms which have not sufficient ROM spaces or the platforms which don't need detailed SMBIOS information, new added fields are only being built when kconfig GENERATE_SMBIOS_TABLE_VERBOSE is selected. Once this patch is acceptted, subsequent patch sets will add other missing types (#9, #16, #17, #19). Tests: To test this with QEMU arm64, please follow the guide on dt_qemu.rst to get a merged DT to run with. ``` qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \ | dtc - -o merged.dtb qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \ -dtb merged.dtb ``` Raymond Mao (10): smbios: Refactor the smbios headfile sysinfo: Add sysinfo API for accessing data area test/dm: add sandbox test for sysinfo_get_data sysinfo: Add sysinfo driver and data structure for smbios smbios: Refactor smbios library smbios: add detailed smbios information armv8: Add arch-specific sysinfo platform driver armv8: Add generic smbios information into the device tree cmd: update smbios cmd configs: Enable sysinfo for QEMU Arm64 arch/arm/cpu/armv8/Makefile | 2 + arch/arm/cpu/armv8/sysinfo.c | 292 ++++++++++++++++++++ arch/arm/dts/qemu-arm64.dts | 4 + arch/arm/dts/smbios_generic.dtsi | 82 ++++++ cmd/smbios.c | 348 +++++++++++++++++++++--- configs/qemu_arm64_defconfig | 3 + drivers/misc/Kconfig | 2 +- drivers/sysinfo/sandbox.c | 19 ++ drivers/sysinfo/sandbox.h | 1 + drivers/sysinfo/smbios.c | 228 ++++++++++++++++ drivers/sysinfo/sysinfo-uclass.c | 20 ++ include/smbios.h | 158 ++++++----- include/smbios_def.h | 194 ++++++++++++++ include/smbios_plat.h | 79 ++++++ include/sysinfo.h | 125 ++++++++- lib/Kconfig | 6 + lib/smbios.c | 445 ++++++++++++++++++++++++++----- test/dm/sysinfo.c | 6 + test/py/tests/test_smbios.py | 18 +- 19 files changed, 1863 insertions(+), 169 deletions(-) create mode 100644 arch/arm/cpu/armv8/sysinfo.c create mode 100644 arch/arm/dts/smbios_generic.dtsi create mode 100644 include/smbios_def.h create mode 100644 include/smbios_plat.h -- 2.25.1

5 19

[PATCH v3 0/3] Adjust how autoprobe is implemented
by Simon Glass 14 Jan '25

14 Jan '25

This little series makes a minor change to how autoprobe is implemeneted, as discussed on the list: https://patchwork.ozlabs.org/project/uboot/patch/ 20240626235717.272219-1-marex(a)denx.de/ Changes in v3: - Add a link to the previous discussion - Add a summary of the design challenge in the DM docs - Use a simple return in initr_dm() - Add a comment to dm_probe_devices() - Expand comment to dm_autoprobe() Changes in v2: - Add autoprobe to SPL also - Leave the function name the same - Fix 'Prove' typo - Update cover letter since SPL is now covered also - Update the documentation too, with a discussion link Simon Glass (3): common: Drop check for DM in initf_dm() dm: core: Simplify dm_probe_devices() common: Move autoprobe out to board init common/board_f.c | 9 ++++++-- common/board_r.c | 2 +- common/spl/spl.c | 4 ++++ doc/develop/driver-model/design.rst | 17 ++++++++++++++ drivers/core/root.c | 36 ++++++++++++++++++++--------- include/dm/root.h | 15 ++++++++++++ 6 files changed, 69 insertions(+), 14 deletions(-) -- 2.34.1

4 8

[PATCH 00/20] Support for the RK3576
by Heiko Stuebner 14 Jan '25

14 Jan '25

This adds support for the RK3576 SoC from Rockchip. Currently supported (and tested) features are accessing and reading from sdhci and sdmmc devices as well as pxe-booting via the network interface. As can be seen by the DONOTMERGE labels, this needs to wait a bit still. The core RK3576 devicetrees will be part of 6.13-rc1, but the Firefly board I only submitted last week, so this would only appear in 6.14-rc1 . If someone from Collabora could provide a board patch for the ArmSom board they are working with, this would speed things up a bit ;-) . Checkpatch seems mostly happy too. Detlev Casanova (3): dt-bindings: clock, reset: Add support for rk3576 DONOTMERGE: arm64: dts: rockchip: Add rk3576 SoC base DT arm: rockchip: add RK3576-specific syscon ids Elaine Zhang (2): clk: rockchip: Add rk3576 clk support reset: rockchip: implement rk3576 lookup table Finley Xiao (1): dt-bindings: power: Add support for RK3576 SoC Heiko Stuebner (11): dt-bindings: clock, reset: fix top-comment indentation rk3576 headers DONOTMERGE: arm64: dts: rockchip: add rk3576 otp node DONOTMERGE: dt-bindings: arm: rockchip: Add Firefly ROC-RK3576-PC binding DONOTMERGE: arm64: dts: rockchip: Add devicetree for the ROC-RK3576-PC rockchip: sdram: honor CFG_SYS_SDRAM_BASE when defining ram regions ram: rockchip: Add rk3576 ddr driver support rockchip: otp: Add support for RK3576 mmc: rockchip_sdhci: Add support for RK3576 mmc: rockchip_dw_mmc: Add support for rk3576 net: dwc_eth_qos_rockchip: Add support for RK3576 rockchip: rk3576: Add support for ROC-RK3576-PC board Steven Liu (1): pinctrl: rockchip: support rk3576 pinctrl Xuhui Lin (2): rockchip: mkimage: Add rk3576 support arm: rockchip: Add RK3576 arch core support arch/arm/dts/rk3576-roc-pc-u-boot.dtsi | 12 + arch/arm/dts/rk3576-u-boot.dtsi | 119 + arch/arm/include/asm/arch-rk3576/boot0.h | 11 + arch/arm/include/asm/arch-rk3576/gpio.h | 11 + arch/arm/include/asm/arch-rockchip/clock.h | 12 + .../include/asm/arch-rockchip/cru_rk3576.h | 486 ++ .../include/asm/arch-rockchip/grf_rk3576.h | 225 + .../include/asm/arch-rockchip/ioc_rk3576.h | 244 + arch/arm/mach-rockchip/Kconfig | 46 +- arch/arm/mach-rockchip/Makefile | 1 + arch/arm/mach-rockchip/rk3576/Kconfig | 57 + arch/arm/mach-rockchip/rk3576/Makefile | 9 + arch/arm/mach-rockchip/rk3576/clk_rk3576.c | 32 + arch/arm/mach-rockchip/rk3576/rk3576.c | 169 + arch/arm/mach-rockchip/rk3576/syscon_rk3576.c | 26 + arch/arm/mach-rockchip/sdram.c | 11 +- board/firefly/roc-pc-rk3576/Kconfig | 12 + board/firefly/roc-pc-rk3576/MAINTAINERS | 7 + configs/roc-pc-rk3576_defconfig | 77 + doc/board/rockchip/rockchip.rst | 12 + drivers/clk/rockchip/Makefile | 1 + drivers/clk/rockchip/clk_rk3576.c | 2517 +++++++ drivers/misc/rockchip-otp.c | 11 + drivers/mmc/rockchip_dw_mmc.c | 1 + drivers/mmc/rockchip_sdhci.c | 12 + drivers/net/dwc_eth_qos.c | 4 + drivers/net/dwc_eth_qos_rockchip.c | 141 +- drivers/pinctrl/rockchip/Makefile | 1 + drivers/pinctrl/rockchip/pinctrl-rk3576.c | 287 + drivers/pinctrl/rockchip/pinctrl-rockchip.h | 3 + drivers/ram/rockchip/Makefile | 1 + drivers/ram/rockchip/sdram_rk3576.c | 65 + drivers/reset/Makefile | 2 +- drivers/reset/rst-rk3576.c | 647 ++ dts/upstream/Bindings/arm/rockchip.yaml | 5 + .../Bindings/clock/rockchip,rk3576-cru.yaml | 56 + .../power/rockchip,power-controller.yaml | 1 + .../dt-bindings/clock/rockchip,rk3576-cru.h | 592 ++ .../dt-bindings/power/rockchip,rk3576-power.h | 30 + .../dt-bindings/reset/rockchip,rk3576-cru.h | 564 ++ .../src/arm64/rockchip/rk3576-pinctrl.dtsi | 5775 +++++++++++++++++ .../src/arm64/rockchip/rk3576-roc-pc.dts | 736 +++ dts/upstream/src/arm64/rockchip/rk3576.dtsi | 1717 +++++ include/configs/rk3576_common.h | 42 + include/configs/roc-pc-rk3576.h | 15 + tools/rkcommon.c | 1 + 46 files changed, 14798 insertions(+), 8 deletions(-) create mode 100644 arch/arm/dts/rk3576-roc-pc-u-boot.dtsi create mode 100644 arch/arm/dts/rk3576-u-boot.dtsi create mode 100644 arch/arm/include/asm/arch-rk3576/boot0.h create mode 100644 arch/arm/include/asm/arch-rk3576/gpio.h create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3576.h create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3576.h create mode 100644 arch/arm/include/asm/arch-rockchip/ioc_rk3576.h create mode 100644 arch/arm/mach-rockchip/rk3576/Kconfig create mode 100644 arch/arm/mach-rockchip/rk3576/Makefile create mode 100644 arch/arm/mach-rockchip/rk3576/clk_rk3576.c create mode 100644 arch/arm/mach-rockchip/rk3576/rk3576.c create mode 100644 arch/arm/mach-rockchip/rk3576/syscon_rk3576.c create mode 100644 board/firefly/roc-pc-rk3576/Kconfig create mode 100644 board/firefly/roc-pc-rk3576/MAINTAINERS create mode 100644 configs/roc-pc-rk3576_defconfig create mode 100644 drivers/clk/rockchip/clk_rk3576.c create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3576.c create mode 100644 drivers/ram/rockchip/sdram_rk3576.c create mode 100644 drivers/reset/rst-rk3576.c create mode 100644 dts/upstream/Bindings/clock/rockchip,rk3576-cru.yaml create mode 100644 dts/upstream/include/dt-bindings/clock/rockchip,rk3576-cru.h create mode 100644 dts/upstream/include/dt-bindings/power/rockchip,rk3576-power.h create mode 100644 dts/upstream/include/dt-bindings/reset/rockchip,rk3576-cru.h create mode 100644 dts/upstream/src/arm64/rockchip/rk3576-pinctrl.dtsi create mode 100644 dts/upstream/src/arm64/rockchip/rk3576-roc-pc.dts create mode 100644 dts/upstream/src/arm64/rockchip/rk3576.dtsi create mode 100644 include/configs/rk3576_common.h create mode 100644 include/configs/roc-pc-rk3576.h -- 2.45.2

5 33

rpi: Compute Module 5 doesn't autoboot without debug UART
by Gijs Peskens 14 Jan '25

14 Jan '25

I'm working on getting a compute module working with Yocto using U-Boot as bootloader, which mostly works thanks to previous work to get RPi 5 working. However I'm running into a strange issue: if I turn on the CM5 without the debug UART (which requires soldering a header onto the CM5) attached, the Pi doesn't boot beyond showing the submarine splash screen, if I boot it with the console attached it autoboots correctly. If I attach the UART after the boot halted and press enter I get a U-Boot console, and giving the boot command boots it normally. And setting bootdelay=-2 in the env allows it to correctly boot. Which leads me to believe there is perhaps a spurious input registered by U-Boot which interrupts autobooting. Is there a command that allows me to extract why U-Boot didn't continue autobooting? And anyone have a hint how this could perhaps be fixed in a more elegant way (allowing interruptable autoboot). The hardware I'm testing on is the CM5 devkit, I needed to make small changes to yocto to get it working: https://github.com/agherzan/meta-raspberrypi/pull/1397 No changes were needed in U-Boot to get it to boot Thanks, Gijs

4 4

[PATCH RFC] image: apply FDTOs on FDT image node without a load property
by Quentin Schulz 14 Jan '25

14 Jan '25

From: Quentin Schulz <quentin.schulz(a)cherry.de> A FIT image which is NOT using -E when created by mkimage - that is with image data within the FIT - will fail to apply FDTO if the base FDT image node does not specify a load property (which points to an address in DRAM). This is because we check that the FDT address we want to apply overlay to (i.e. modify and likely increase in size) is not inside the FIT and give up otherwise. This is assumed necessary because we may then overwrite other data when applying in-place. However, we can do better than giving up: relocating the FDT in another place in DRAM where it's safe to increase its size and apply FDTOs. Suggested-by: Marek Vasut <marex(a)denx.de> Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Tested with extlinux with: - conf node with multiple fdt entries - conf node with base fdt + conf node with fdto (stored in fdt property) - FDT image node with load property (behavior unchanged) - FDT image node without load property I'll be frank, I don't really know what I'm doing here and I'm on holidays for a month in a few hours, so take this with a bigger grain of salt than usual (hence the RFC). It works (tm) for now. Cc: Heiko Stuebner <heiko(a)sntech.de> --- boot/image-fit.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/boot/image-fit.c b/boot/image-fit.c index 7d56f0b5e6ed39a75e029b09dc95d605835c0f91..088482c4d5d2e194cce66f10b0acd9e586f826b2 100644 --- a/boot/image-fit.c +++ b/boot/image-fit.c @@ -2392,13 +2392,18 @@ int boot_get_fdt_fit(struct bootm_headers *images, ulong addr, image_end = addr + fit_get_size(fit); /* verify that relocation took place by load address not being in fit */ if (load >= image_start && load < image_end) { - /* check is simplified; fit load checks for overlaps */ - printf("Overlayed FDT requires relocation\n"); - fdt_noffset = -EBADF; - goto out; - } + /* Cannot overlay an FDT stored inside the fitImage, so let's relocate */ + char *of_flat_tree = map_sysmem(load, len); - base = map_sysmem(load, len); + len = ALIGN(fdt_totalsize(load), SZ_4K); + if (boot_relocate_fdt(&of_flat_tree, &len)) { + printf("Required FDT relocation for applying overlays failed..."); + fdt_noffset = -EBADF; + goto out; + } + + load = (ulong)of_flat_tree; + } /* apply extra configs in FIT first, followed by args */ for (i = 1; ; i++) { --- base-commit: 69bd83568c57813cd23bc2d100c066a17e7e349d change-id: 20241219-extlinux-relocate-dtb-when-dtbo-4c7536f880b2 Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

3 3

[PATCH v2 0/6] efi_loader: run bootdev_hunt() to find ESP
by Heinrich Schuchardt 14 Jan '25

14 Jan '25

When initializing the EFI sub-system we need all block devices and the NIC to be probed. Extensions should have been applied to the device-tree. Our current implementation only guarantees that bound block devices are probed. But this misses out devices where binding requires specific routines to be executed, e.g. NVMe (nvme scan), SCSI (scsi start). Invoking bootdev_hunt() allows to find all block devices, probe the network nic, and enable extensions. Reviewers complained that PXE boot was executed unexpectedly with a patch that only added the bootdev_hunt() call to the EFI sub-system initialization. The EFI sub-system does not require the IP address to be set up. We can reduce the boottime by not executing dchp_run() in eth_bootdev_hunt(). Furthermore on the legacy network stack with autostart=yes dhcp_run() tries to download the boot file via TFTP and execute it which seems to be a problem with non-observance of autoload=no. To fix Gitlab CI issues the following changes are necessary: In test_extension.py do not assume that extensions have not been loaded by bootdev hunter in a previous test. Remove CONFIG_AMIGA_PARTITION from sandbox_deconfig to avoid a timeout. Remove CONFIG_USB_DWC3 on the CI from xilinx_versal_virt_defconfig to avoid a boot failure. Add a parameter '-e' to select if UEFI boot options shall be shown by the bootmenu command. v2: disable USB_DWC3 only in CI update commit message for eth_bootdev_hunt() change Heinrich Schuchardt (6): test: fix test_extension.py configs: sandbox_deconfig: remove CONFIG_AMIGA_PARTITION CI: xilinx_versal_virt: disable USB_DWC3 net: eth_bootdev_hunt() must not try to boot cmd: bootmenu: add parameter -e for UEFI boot options efi_loader: run bootdev_hunt() to find ESP .azure-pipelines.yml | 1 + .gitlab-ci.yml | 1 + cmd/bootmenu.c | 39 +++++++++++++++++++++++++-------- configs/sandbox_defconfig | 1 - doc/usage/cmd/bootmenu.rst | 13 ++++++++--- lib/efi_loader/efi_setup.c | 8 +++++++ net/eth_bootdev.c | 30 +++++++++++++++---------- test/py/tests/test_extension.py | 4 +++- 8 files changed, 71 insertions(+), 26 deletions(-) -- 2.45.2

5 23

[PATCH 00/18] x86: Improve operation under QEMU
by Simon Glass 10 Jan '25

10 Jan '25

U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it is not perfect. With both builds, executing the VESA ROM causes an intermittent hang, at least on some AMD CPUs. With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) is done in a way that works on real hardware but not with QEMU. This means that performance is 4-5x slower than it could be, at least on my CPU. We can work around the first problem by using Bochs, which is anyway a better choice than VESA for QEMU. But this results in the Ubuntu installer failing to boot via EFI. It isn't clear whether this due to a problem with the UEFI GOP, or something else. It hangs before the Ubuntu logo appears. So this series is unfinished. I thought it best to post what is here in the hope that others can help work out the kinks. Simon Glass (18): scripts: Add a script for building and booting QEMU x86: Expand x86_64 early memory RFC: x86: qemu: Switch to bochs display x86: qemu: Enable dhrystone x86: qemu: Avoid accessing BSS too early x86: Drop mpspec from the SPL build x86: Add some log categories x86: Drop use of CONFIG_REALMODE_DEBUG x86: Avoid clearing the VESA display x86: Add 64-bit entries to the GDT x86: Use defines for the cache flags x86: spl: Drop duplicate CPU init x86: Drop the message about features missing in 64-bit x86: Include stdbool.h in interrupt header x86: Tidy up the GDT size in start/16.S x86: Disable paging before changing to long mode x86: Use the same GDT when jumping to long mode x86: Use a simple jump into long mode MAINTAINERS | 8 ++ arch/x86/cpu/i386/call64.S | 35 +++---- arch/x86/cpu/i386/cpu.c | 18 +++- arch/x86/cpu/qemu/qemu.c | 20 ++-- arch/x86/cpu/start.S | 4 +- arch/x86/cpu/start16.S | 3 +- arch/x86/include/asm/interrupt.h | 1 + arch/x86/include/asm/processor.h | 5 +- arch/x86/lib/Makefile | 2 + arch/x86/lib/bios.c | 27 +++-- arch/x86/lib/bios_interrupts.c | 8 +- arch/x86/lib/i8259.c | 2 + arch/x86/lib/spl.c | 4 +- configs/qemu-x86_64_defconfig | 10 +- configs/qemu-x86_defconfig | 6 +- doc/board/emulation/index.rst | 1 + doc/board/emulation/script.rst | 61 +++++++++++ scripts/build-qemu.sh | 175 +++++++++++++++++++++++++++++++ 18 files changed, 331 insertions(+), 59 deletions(-) create mode 100644 doc/board/emulation/script.rst create mode 100755 scripts/build-qemu.sh -- 2.34.1

3 31