September 2022 - U-Boot

[PATCH] ARM: stm32: Enable btrfs support on DHSOM
by Marek Vasut 18 Oct '22

18 Oct '22

The btrfs filesystem provides advanced functionality like copy-on-write and snapshots, as well as metadata and data duplication and checksumming. Enable btrfs in U-Boot to permit even the primary partition to be btrfs and let system boot from it. Signed-off-by: Marek Vasut <marex(a)denx.de> --- configs/stm32mp15_dhcom_basic_defconfig | 1 + configs/stm32mp15_dhcor_basic_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index f47e70be44a..67e238af3a1 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -79,6 +79,7 @@ CONFIG_CMD_TIME=y CONFIG_CMD_TIMER=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y +CONFIG_CMD_BTRFS=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=nor0" diff --git a/configs/stm32mp15_dhcor_basic_defconfig b/configs/stm32mp15_dhcor_basic_defconfig index 02cce50691e..a630713f926 100644 --- a/configs/stm32mp15_dhcor_basic_defconfig +++ b/configs/stm32mp15_dhcor_basic_defconfig @@ -77,6 +77,7 @@ CONFIG_CMD_TIME=y CONFIG_CMD_TIMER=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y +CONFIG_CMD_BTRFS=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=nor0" -- 2.35.1

2 2

[PATCH] ARM: dts: stm32: Remove buck3 regulator-always-on on AV96
by Marek Vasut 18 Oct '22

18 Oct '22

In case the regulator-always-on is present in regulator DT node, the regulator is always reconfigured to the voltage set in DT on probe, even if regulator_set_value() has been called before. Drop the property from AV96 U-Boot DT and enable the regulator manually in code, as the board already reconfigures the Buck3 regulator in code per PMIC NVM content instead. Fixes: 0adf10a87b1 ("ARM: dts: stm32: Configure Buck3 voltage per PMIC NVM on Avenger96") 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> --- arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 4 ++++ board/dhelectronics/dh_stm32mp1/board.c | 1 + 2 files changed, 5 insertions(+) diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi index 5bed53e3fdb..b6fceb9ad58 100644 --- a/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi +++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi @@ -102,6 +102,10 @@ hnp-srp-disable; }; +&vdd { + /delete-property/ regulator-always-on; +}; + &vdd_io { u-boot,dm-spl; }; diff --git a/board/dhelectronics/dh_stm32mp1/board.c b/board/dhelectronics/dh_stm32mp1/board.c index 9188f5381eb..b0284609183 100644 --- a/board/dhelectronics/dh_stm32mp1/board.c +++ b/board/dhelectronics/dh_stm32mp1/board.c @@ -595,6 +595,7 @@ static void board_init_regulator_av96(void) /* Adjust Buck3 per preconfigured PMIC voltage from NVM. */ regulator_set_value(rdev, uv); + regulator_set_enable(rdev, true); } static void board_init_regulator(void) -- 2.35.1

2 2

[PATCH 0/7] add support for Theobroma Systems PX30-µQ7 (Ringneck) with Haikou devkit
by Quentin Schulz 17 Oct '22

17 Oct '22

From: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> The PX30-uQ7 (Ringneck) SoM is a µQseven-compatible (40mmx70mm, MXM-230 connector) system-on-module from Theobroma Systems[1], featuring the Rockchip PX30. It provides the following feature set: * up to 4GB DDR4 * up to 128GB on-module eMMC (with 8-bit 1.8V interface) * SD card (on a baseboard) via edge connector * Fast Ethernet with on-module TI DP83825I PHY * MIPI-DSI/LVDS * MIPI-CSI * USB - 1x USB 2.0 dual-role - 3x USB 2.0 host * on-module STM32 Cortex-M0 companion controller, implementing: - low-power RTC functionality (ISL1208 emulation) - fan controller (AMC6821 emulation) - USB<->CAN bridge controller * on-module Espressif ESP32 for Bluetooth + 2.4GHz WiFi * on-module NXP SE05x Secure Element [1] https://www.theobroma-systems.com/som-product/px30-%C2%B5q7/ This patch series depends on the following patch series: https://lore.kernel.org/u-boot/20220915101247.796236-1-foss+uboot@0leil.net/ The non-U-Boot-specific Device Trees are from the following Linux kernel patch series: https://lore.kernel.org/lkml/20220922101211.3215888-3-foss+kernel@0leil.net/ The new SW input event code added in patch 6/7 is from the following patch from the Linux kernel: https://lore.kernel.org/lkml/20220922101211.3215888-2-foss+kernel@0leil.net/ We probably should wait on the kernel to merge it in one of the maintainers branches before merging it into U-Boot? Cheers, Quentin Quentin Schulz (7): rockchip: px30: fix CONFIG_IRAM_BASE rockchip: px30: list possible SPL boot devices rockchip: px30: insert u-boot,spl-boot-device into U-Boot device tree arm64: dts: rockchip: sync px30 with linux-next include/dt-bindings: Sync linux-event-codes with Linux kernel Input: add `SW_BOOT_ALT` rockchip: add support for PX30 Ringneck SoM on Haikou Devkit arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi | 95 +++++ arch/arm/dts/px30-ringneck-haikou.dts | 239 ++++++++++++ arch/arm/dts/px30-ringneck.dtsi | 347 ++++++++++++++++++ arch/arm/dts/px30.dtsi | 28 +- arch/arm/mach-rockchip/px30/Kconfig | 25 ++ arch/arm/mach-rockchip/px30/px30.c | 56 +++ board/theobroma-systems/ringneck_px30/Kconfig | 18 + .../ringneck_px30/MAINTAINERS | 9 + .../theobroma-systems/ringneck_px30/Makefile | 7 + board/theobroma-systems/ringneck_px30/README | 69 ++++ .../ringneck_px30/ringneck-px30.c | 175 +++++++++ configs/ringneck-px30_defconfig | 131 +++++++ doc/board/rockchip/rockchip.rst | 1 + include/configs/px30_common.h | 3 +- include/configs/ringneck_px30.h | 15 + include/dt-bindings/input/linux-event-codes.h | 176 ++++++++- 16 files changed, 1385 insertions(+), 9 deletions(-) create mode 100644 arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi create mode 100644 arch/arm/dts/px30-ringneck-haikou.dts create mode 100644 arch/arm/dts/px30-ringneck.dtsi create mode 100644 board/theobroma-systems/ringneck_px30/Kconfig create mode 100644 board/theobroma-systems/ringneck_px30/MAINTAINERS create mode 100644 board/theobroma-systems/ringneck_px30/Makefile create mode 100644 board/theobroma-systems/ringneck_px30/README create mode 100644 board/theobroma-systems/ringneck_px30/ringneck-px30.c create mode 100644 configs/ringneck-px30_defconfig create mode 100644 include/configs/ringneck_px30.h -- 2.37.3

3 18

[PATCH] rkspi: only enable padding quirk on SoCs which need it
by Lorenz Brun 17 Oct '22

17 Oct '22

The workaround for the Mask ROM bug in a lot of Rockchip SoCs is applied unconditionally, but at least on the RK3328 it is not needed and causes a boot failure if applied. Make a new column in the SoC feature description and skip the workaround if the SoC doesn't need it. Signed-off-by: Lorenz Brun <lorenz(a)brun.one> --- tools/rkcommon.c | 35 ++++++++++++++++++++++------------- tools/rkcommon.h | 9 +++++++++ tools/rkspi.c | 6 ++++++ 3 files changed, 37 insertions(+), 13 deletions(-) diff --git a/tools/rkcommon.c b/tools/rkcommon.c index 0db45c2d41..4b4de24f21 100644 --- a/tools/rkcommon.c +++ b/tools/rkcommon.c @@ -118,22 +118,24 @@ struct spl_info { const uint32_t spl_size; const bool spl_rc4; const uint32_t header_ver; + const bool has_spi_halfblock_quirk; }; +// Note: has_spi_halfblock_quirk is not certain on all SoCs. static struct spl_info spl_infos[] = { - { "px30", "RK33", 0x2800, false, RK_HEADER_V1 }, - { "rk3036", "RK30", 0x1000, false, RK_HEADER_V1 }, - { "rk3066", "RK30", 0x8000 - 0x800, true, RK_HEADER_V1 }, - { "rk3128", "RK31", 0x1800, false, RK_HEADER_V1 }, - { "rk3188", "RK31", 0x8000 - 0x800, true, RK_HEADER_V1 }, - { "rk322x", "RK32", 0x8000 - 0x1000, false, RK_HEADER_V1 }, - { "rk3288", "RK32", 0x8000, false, RK_HEADER_V1 }, - { "rk3308", "RK33", 0x40000 - 0x1000, false, RK_HEADER_V1 }, - { "rk3328", "RK32", 0x8000 - 0x1000, false, RK_HEADER_V1 }, - { "rk3368", "RK33", 0x8000 - 0x1000, false, RK_HEADER_V1 }, - { "rk3399", "RK33", 0x30000 - 0x2000, false, RK_HEADER_V1 }, - { "rv1108", "RK11", 0x1800, false, RK_HEADER_V1 }, - { "rk3568", "RK35", 0x14000 - 0x1000, false, RK_HEADER_V2 }, + { "px30", "RK33", 0x2800, false, RK_HEADER_V1, true}, + { "rk3036", "RK30", 0x1000, false, RK_HEADER_V1, true }, + { "rk3066", "RK30", 0x8000 - 0x800, true, RK_HEADER_V1, true }, + { "rk3128", "RK31", 0x1800, false, RK_HEADER_V1, true }, + { "rk3188", "RK31", 0x8000 - 0x800, true, RK_HEADER_V1, true }, + { "rk322x", "RK32", 0x8000 - 0x1000, false, RK_HEADER_V1, true }, + { "rk3288", "RK32", 0x8000, false, RK_HEADER_V1, true }, + { "rk3308", "RK33", 0x40000 - 0x1000, false, RK_HEADER_V1, true }, + { "rk3328", "RK32", 0x8000 - 0x1000, false, RK_HEADER_V1, false }, + { "rk3368", "RK33", 0x8000 - 0x1000, false, RK_HEADER_V1, true }, + { "rk3399", "RK33", 0x30000 - 0x2000, false, RK_HEADER_V1, true }, + { "rv1108", "RK11", 0x1800, false, RK_HEADER_V1, true }, + { "rk3568", "RK35", 0x14000 - 0x1000, false, RK_HEADER_V2, true }, }; /** @@ -282,6 +284,13 @@ bool rkcommon_is_header_v2(struct image_tool_params *params) return (info->header_ver == RK_HEADER_V2); } +bool rkcommon_has_spi_halfblock_quirk(struct image_tool_params *params) +{ + struct spl_info *info = rkcommon_get_spl_info(params->imagename); + + return info->has_spi_halfblock_quirk; +} + static void do_sha256_hash(uint8_t *buf, uint32_t size, uint8_t *out) { sha256_context ctx; diff --git a/tools/rkcommon.h b/tools/rkcommon.h index 49b6df3185..7b0c036dac 100644 --- a/tools/rkcommon.h +++ b/tools/rkcommon.h @@ -41,6 +41,15 @@ const char *rkcommon_get_spl_hdr(struct image_tool_params *params); */ int rkcommon_get_spl_size(struct image_tool_params *params); + +/** + * rkcommon_has_spi_halfblock_quirk checks if the SoC MaskROM has the SPI block + * loading quirk. + * SoCs with this quirk load the initial TPL/SPL incorrectly and need each 4K + * block of it to be split into two 2K blocks with the upper half padded. + */ +bool rkcommon_has_spi_halfblock_quirk(struct image_tool_params *params); + /** * rkcommon_set_header() - set up the header for a Rockchip boot image * diff --git a/tools/rkspi.c b/tools/rkspi.c index f2530f7bde..b6f75fae1b 100644 --- a/tools/rkspi.c +++ b/tools/rkspi.c @@ -26,6 +26,9 @@ static void rkspi_set_header(void *buf, struct stat *sbuf, int ifd, rkcommon_set_header(buf, sbuf, ifd, params); + if(!rkcommon_has_spi_halfblock_quirk(params)) + return; + /* * Spread the image out so we only use the first 2KB of each 4KB * region. This is a feature of the SPI format required by the Rockchip @@ -62,6 +65,9 @@ static int rkspi_vrec_header(struct image_tool_params *params, { rkcommon_vrec_header(params, tparams); + if(!rkcommon_has_spi_halfblock_quirk(params)) + return 0; + /* * Converting to the SPI format (i.e. splitting each 4K page into two * 2K subpages and then padding these 2K pages up to take a complete -- 2.37.2

2 1

[REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series with CAAM enabled
by ZHIZHIKIN Andrey 16 Oct '22

16 Oct '22

Hello Gaurav, In the new v2022.07, I've stumbled upon the issue with calculating the SHA256 of memory blocks with CAAM hashing. This causes the FIT image not to pass the hash validation, and also `sha256` command not operable. I'm also wondering if any i.MX8M-based board maintainers have seen the same issues at their end? I've made a small test executing the following command sequence (with corresponding serial output): U-Boot 2022.07 (Jul 15 2022 - 14:36:00 +0200) CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz Reset cause: POR Model: FSL i.MX8MM EVK board DRAM: 2 GiB Core: 153 devices, 19 uclasses, devicetree: separate WDT: Started watchdog@30280000 with servicing (60s timeout) MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial@30890000 Out: serial@30890000 Err: serial@30890000 SEC0: RNG instantiated Net: eth0: ethernet@30be0000 Hit any key to stop autoboot: 0 u-boot=> mw.b ${kernel_addr_r} DE 100 u-boot=> md.b ${kernel_addr_r} 100 40480000: dededede dededede dededede dededede ................ 40480010: dededede dededede dededede dededede ................ 40480020: dededede dededede dededede dededede ................ 40480030: dededede dededede dededede dededede ................ 40480040: dededede dededede dededede dededede ................ 40480050: dededede dededede dededede dededede ................ 40480060: dededede dededede dededede dededede ................ 40480070: dededede dededede dededede dededede ................ 40480080: dededede dededede dededede dededede ................ 40480090: dededede dededede dededede dededede ................ 404800a0: dededede dededede dededede dededede ................ 404800b0: dededede dededede dededede dededede ................ 404800c0: dededede dededede dededede dededede ................ 404800d0: dededede dededede dededede dededede ................ 404800e0: dededede dededede dededede dededede ................ 404800f0: dededede dededede dededede dededede ................ u-boot=> hash sha256 ${kernel_addr_r} 100 CAAM was not setup properly or it is faulty sha256 for 40480000 ... 404800ff ==> 736372697074616464727d0a626f6f745f6566695f62696e6172793d6c6f6164 Running `sha256` commands several times in a row also produces different Results, sometimes it comes out as all 0's. For comparison purposes, I've did similar on the desktop: $ while true ; do printf "\xDE"; done | dd of=./test_data bs=1 count=256 256+0 records in 256+0 records out 256 bytes copied, 0.000484 s, 529 kB/s $ hexdump -C -v ./test_data 00000000 de de de de de de de de de de de de de de de de |................| 00000010 de de de de de de de de de de de de de de de de |................| 00000020 de de de de de de de de de de de de de de de de |................| 00000030 de de de de de de de de de de de de de de de de |................| 00000040 de de de de de de de de de de de de de de de de |................| 00000050 de de de de de de de de de de de de de de de de |................| 00000060 de de de de de de de de de de de de de de de de |................| 00000070 de de de de de de de de de de de de de de de de |................| 00000080 de de de de de de de de de de de de de de de de |................| 00000090 de de de de de de de de de de de de de de de de |................| 000000a0 de de de de de de de de de de de de de de de de |................| 000000b0 de de de de de de de de de de de de de de de de |................| 000000c0 de de de de de de de de de de de de de de de de |................| 000000d0 de de de de de de de de de de de de de de de de |................| 000000e0 de de de de de de de de de de de de de de de de |................| 000000f0 de de de de de de de de de de de de de de de de |................| 00000100 $ sha256sum ./test_data 8b11bcdc65d5f1af0fa1edfa7b5db089dba40d4e8d29b455295d58ab2b314e76 ./test_data As one can see, the SHA256 has a totally different value, with desktop produces a rather correct one. Since the CAAM is enabled per default for all i.MX8M derivatives, there is no way to target SHA hash calculations back to SW implementation, therefore it blocks a lot of people to boot FIT images that has `hash` nodes in them. Looking a bit deeper into why it fails, I saw that the JR used for hash calculations is hard-coded to `0` in run_descriptor_jr() call, which is now reserved in S-World for HAB operations. But changing it to `1` did not change the behavior, the SHA256 is still not calculated proper. Can you please advise how this can be solved? And more conceptually: why is SHA hashing now hardwired to HW CAAM module, while it was perfectly executed in SW via `lib/sha.c`? Thanks a lot! Regards, Andrey

5 16

[PATCH] Kconfig: distro: Use imply instead of select for CMD_FAT
by Jit Loon Lim 14 Oct '22

14 Oct '22

From: Tien Fong Chee <tien.fong.chee(a)intel.com> Using imply instead of select for CMD_FAT so overwritten is allowed in later configuration. Signed-off-by: Tien Fong Chee <tien.fong.chee(a)intel.com> --- Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 991b260182..71374980e9 100644 --- a/Kconfig +++ b/Kconfig @@ -201,7 +201,7 @@ config DISTRO_DEFAULTS select CMD_ENV_EXISTS select CMD_EXT2 select CMD_EXT4 - select CMD_FAT + imply CMD_FAT select CMD_FS_GENERIC select CMD_PART if PARTITIONS select CMD_PING if CMD_NET -- 2.26.2

3 5

[PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI
by Simon Glass 14 Oct '22

14 Oct '22

At present U-Boot can be built as an EFI app, but it is really just for testing, with very few features. Instead, the payload build is used for booting on top of UEFI, where U-Boot takes over the machine immediately and supplies its own drivers. But the app could be made more useful. This series provides access to EFI block devices and the video console within U-Boot. It also restructures the app to make it possible to boot a kernel, although further work is needed to implement this. This can be thought of as making U-Boot perform a little like 'grub', in that it runs purely based on UEFI-provided services. Of course a lot more work is required, but this is a start. Note: It would be very useful to include qemu tests of the app and stub in CI. This is available at u-boot-dm/efi-working Changes in v2: - Add MAINTAINERS entry - Add a better boot command too - Add a note that EFI_GRAPHICS_OUTPUT_PROTOCOL is used - Add a sentence about what the patch does - Add a work-around to avoid a toolchain crash - Add new patch to drop the OF_EMBED warning for EFI - Add new patch to enable DM_ETH for the app - Add new patch to support the efi command in the app - Add new patch with maintainer entry - Add support for creating a partition table with a filesystem inside - Add support for running qemu with just a serial console (no display) - Drop mention of partitions from the commit message - Expand the commit message to make things clearer - Fix 'as' typo - Mention why this patch is included in this series - Put this patch first so that it is separated from the rest of the series - Show the correct interface type with 'part list' - Update commit message to mention that these function are x86-specific - Update commit message to mention why the data structure is like it is - Update commit message to mention why ulong is used - Update documentation - Update the commit message to explain things better - Use log_info() instead of printf() Simon Glass (39): RFC: efi: Drop code that doesn't work with driver model efi: Add a separate maintainer entry for the app x86: Keep symbol information in u-boot ELF file x86: Create a new header for EFI x86: Show some EFI info with the bdinfo command x86: Tidy up global_data pointer for 64-bit efi: Add a script for building and testing U-Boot on UEFI efi: Enable DM_ETH for the app efi: Drop the OF_EMBED warning for EFI x86: Create a 32/64-bit selection for the app efi: Create a 64-bit app x86: Don't duplicate global_ptr in 64-bit EFI app efi: Add a way to obtain boot services in the app efi: Add video support to the app efi: Add EFI uclass for media efi: Add a media/block driver for EFI block devices efi: Locate all block devices in the app patman: Use a ValueError exception if tools.Run() fails binman: Report an error if test files fail to compile binman: Support reading the offset of an ELF-file symbol binman: Allow timeout to occur in the image or its section binman: Tidy up comments on _DoTestFile() binman: Support updating the dtb in an ELF file efi: serial: Support arrow keys bloblist: Support allocating the bloblist x86: Allow booting a kernel from the EFI app x86: Don't process the kernel command line unless enabled x86: efi: Add room for the binman definition in the dtb efi: Add comments to struct efi_priv efi: Fix ll_boot_init() operation with the app efi: Add a few comments to the stub efi: Share struct efi_priv between the app and stub code efi: Move exit_boot_services into a function efi: Check for failure when initing the app efi: Mention that efi_info_get() is only used in the stub efi: Show when allocated pages are used efi: Allow easy selection of serial-only operation efi: Update efi_get_next_mem_desc() to avoid needing a map efi: Support the efi command in the app MAINTAINERS | 14 + Makefile | 10 +- arch/sandbox/dts/test.dts | 4 + arch/x86/config.mk | 4 +- arch/x86/cpu/efi/payload.c | 21 +- arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/cpu/u-boot-64.lds | 2 + arch/x86/cpu/x86_64/Makefile | 4 + arch/x86/cpu/x86_64/cpu.c | 32 +- arch/x86/cpu/x86_64/misc.c | 41 +++ arch/x86/dts/Makefile | 2 +- arch/x86/dts/efi-x86_app.dts | 4 + arch/x86/include/asm/efi.h | 39 +++ arch/x86/include/asm/global_data.h | 2 + arch/x86/include/asm/zimage.h | 3 - arch/x86/lib/Makefile | 1 + arch/x86/lib/bdinfo.c | 22 ++ arch/x86/lib/bootm.c | 11 +- arch/x86/lib/zimage.c | 14 +- board/efi/Kconfig | 15 +- board/efi/efi-x86_app/Kconfig | 6 +- board/efi/efi-x86_app/MAINTAINERS | 11 +- cmd/Makefile | 2 +- cmd/efi.c | 76 +++-- common/Kconfig | 15 +- common/bloblist.c | 16 +- common/board_f.c | 8 +- ..._app_defconfig => efi-x86_app32_defconfig} | 3 +- configs/efi-x86_app64_defconfig | 39 +++ disk/part.c | 5 +- doc/develop/bloblist.rst | 16 + doc/develop/uefi/u-boot_on_efi.rst | 74 ++++- drivers/block/Kconfig | 33 +++ drivers/block/Makefile | 4 + drivers/block/blk-uclass.c | 2 +- drivers/block/efi-media-uclass.c | 15 + drivers/block/efi_blk.c | 115 ++++++++ drivers/block/sb_efi_media.c | 20 ++ drivers/serial/serial_efi.c | 11 +- drivers/video/Kconfig | 2 +- drivers/video/efi.c | 45 ++- include/configs/efi-x86_app.h | 31 +- include/dm/uclass-id.h | 1 + include/efi.h | 123 +++++++- include/efi_api.h | 15 + include/init.h | 2 +- lib/efi/Kconfig | 34 ++- lib/efi/efi.c | 106 +++++++ lib/efi/efi_app.c | 276 +++++++++++++++++- lib/efi/efi_stub.c | 95 +++--- lib/efi_driver/Makefile | 2 +- lib/efi_loader/Kconfig | 1 + lib/efi_loader/efi_device_path.c | 96 ++---- lib/efi_loader/efi_disk.c | 48 --- scripts/build-efi.sh | 188 ++++++++++++ test/dm/Makefile | 1 + test/dm/efi_media.c | 24 ++ tools/binman/binman.rst | 36 +++ tools/binman/cmdline.py | 2 + tools/binman/control.py | 11 + tools/binman/elf.py | 74 ++++- tools/binman/elf_test.py | 45 ++- tools/binman/ftest.py | 91 +++++- tools/binman/test/Makefile | 13 +- tools/binman/test/bss_data.c | 2 +- tools/binman/test/embed_data.c | 16 + tools/binman/test/embed_data.lds | 23 ++ tools/binman/test/u_boot_binman_embed.c | 13 + tools/binman/test/u_boot_binman_embed.lds | 29 ++ tools/binman/test/u_boot_binman_embed_sm.c | 13 + tools/patman/tools.py | 2 +- 71 files changed, 1841 insertions(+), 337 deletions(-) create mode 100644 arch/x86/cpu/x86_64/misc.c create mode 100644 arch/x86/include/asm/efi.h create mode 100644 arch/x86/lib/bdinfo.c rename configs/{efi-x86_app_defconfig => efi-x86_app32_defconfig} (94%) create mode 100644 configs/efi-x86_app64_defconfig create mode 100644 drivers/block/efi-media-uclass.c create mode 100644 drivers/block/efi_blk.c create mode 100644 drivers/block/sb_efi_media.c create mode 100755 scripts/build-efi.sh create mode 100644 test/dm/efi_media.c create mode 100644 tools/binman/test/embed_data.c create mode 100644 tools/binman/test/embed_data.lds create mode 100644 tools/binman/test/u_boot_binman_embed.c create mode 100644 tools/binman/test/u_boot_binman_embed.lds create mode 100644 tools/binman/test/u_boot_binman_embed_sm.c -- 2.33.0.685.g46640cef36-goog

4 73

Re: Question about uboot initialisation
by momo aubin 14 Oct '22

14 Oct '22

On Mon, 12 Sept 2022 at 17:07, Simon Glass <sjg(a)chromium.org> wrote: > Hi Aubin, > > On Mon, 12 Sept 2022 at 08:23, momo aubin <aubinno(a)gmail.com> wrote: > > > > Hi Simon, > > > > Thanks for your answer and explanations. > > > > The sequence of boot is : > > RBL->UBL->UBOOT->Kernel->ROOTFS. > > > > According to this sequence, ubl is the one who chooses which uboot needs > to be started, then writing the script means writing them inside ubl. > However, Ubl doesn't have access to the environment variable in order to > know which u-boot has been used first. > > > > My question is . > > Is it possible to choose another u-boot (u-boot2) inside the first > u-boot (u-boot1) ? > > Can you please try that reply again, without top posting? > > https://www.google.com/search?q=top+posting > > Regards, > Simon > > > > > > Regards, > > Aubin > > > > On Mon, 12 Sept 2022 at 15:35, Simon Glass <sjg(a)chromium.org> wrote: > >> > >> Hi Momo, > >> > >> On Sun, 11 Sept 2022 at 08:29, momo aubin <aubinno(a)gmail.com> wrote: > >> > > >> > Hi Simon, > >> > > >> > Thanks for getting back to me. > >> > > >> > How can I avoid top posting ? i'm a new > >> > >> You can do a web search for "top posting" which explains the issue > >> better than I can. > >> > >> > > >> > How uboot know that the kernel has started ? > >> > >> Generally it does not. U-Boot's job is typically over once it jumps to > >> the kernel. > >> > >> > If the system is blocked during the u-boot stage, is it possible to > restart all the systems ? > >> > It is possible to put a timer in the u-boot stage in case of the > kernel has not started , can the system reboot by choosing another u-boot ? > >> > >> You can use a watchdog timer to reboot the system. It can be set up in > >> U-Boot, then it Linux does not kick it in time, it will cause a > >> reboot. To choose another U-Boot, you would need to do some scripting, > >> or use mender. There is some work on VBE going on (U-Boot standard > >> boot) but it will take a while to all land. > >> > >> Regards, > >> SImon > >> > >> > >> > > >> > > >> > Thanks for your answer in advance. > >> > Aubin > >> > > >> > > >> > On Tue, 30 Aug 2022 at 04:30, Simon Glass <sjg(a)chromium.org> wrote: > >> >> > >> >> Hi Aubin, > >> >> > >> >> On Mon, 29 Aug 2022 at 01:40, momo aubin <aubinno(a)gmail.com> wrote: > >> >> > > >> >> > Hi Simon, > >> >> > I got what is the 'dm tree' which is a driver model. This command > could be done only in uboot stage. but i got the situation in which the > initialisation of u-boot has not finished yet as showing in the following > picture. > >> >> > > >> >> > > >> >> > .i would like to know what is wrong in the initialisation ? > >> >> > >> >> Please try to avoid top posting. > >> >> > >> >> I think the best thing is to move to the latest U-Boot. You are about > >> >> 9 years behind! But as to your question, I am really not sure. If it > >> >> is a TI board, you could try asking them? > >> >> > >> >> Regards, > >> >> Simon > >> >> > >> >> > >> >> > > >> >> > Best Regard, > >> >> > Aubin > >> >> > > >> >> > On Mon, 29 Aug 2022 at 05:24, momo aubin <aubinno(a)gmail.com> > wrote: > >> >> >> > >> >> >> Hi Simon, > >> >> >> > >> >> >> Thanks for your answer. > >> >> >> > >> >> >> The script that you are telling it is Env.txt right ? > >> >> >> > >> >> >> What is a 'dm tree' ? Please could you provide me more infos > about this ? > >> >> >> > >> >> >> Thanks for your answer in advance. > >> >> >> > >> >> >> On Sat, 27 Aug 2022 at 02:21, Simon Glass <sjg(a)chromium.org> > wrote: > >> >> >>> > >> >> >>> Hi Aubin, > >> >> >>> > >> >> >>> On Fri, 26 Aug 2022 at 06:41, momo aubin <aubinno(a)gmail.com> > wrote: > >> >> >>> > > >> >> >>> > Dear all, > >> >> >>> > > >> >> >>> > > >> >> >>> > Is there any way that allows us to know that uboot has > initialised all his > >> >> >>> > peripherals before starting loading kernel ? > >> >> >>> > > >> >> >>> > The goal of this check is to reset the board in case of bad > initialisation > >> >> >>> > and choose a different uboot . > >> >> >>> > > >> >> >>> > Thanks for your answer in advance. > >> >> >>> > Aubin > >> >> >>> > >> >> >>> If there is a failure then it likely results in an error-return > code > >> >> >>> from board_init_f() or board_init_r(). These generally halt > U-Boot / > >> >> >>> cause a reboot. But this only covers the peripherals that U-Boot > sets > >> >> >>> up early, like serial, clocks, pinctrl, MMC, PCI, etc. > >> >> >>> > >> >> >>> U-Boot typically does not init a peripheral unless it is needed > for U-Boot. > >> >> >>> > >> >> >>> While U-Boot is running (e.g. a script) it may start up other > >> >> >>> peripherals (e.g. to read a kernel from USB) and in those cases > errors > >> >> >>> can be handled by the script. > >> >> >>> > >> >> >>> You can use 'dm tree' to see what devices have been probed > successfully. > >> >> >>> > >> >> >>> Regards, > >> >> >>> Simon > Hi Simon, Thanks for your answer and explanations. The sequence of boot is : RBL->UBL->UBOOT->Kernel->ROOTFS. According to this sequence, ubl is the one who chooses which uboot needs to be started, then writing the script means writing them inside ubl. However, Ubl doesn't have access to the environment variable in order to know which u-boot has been used first. My question is . Is it possible to choose another u-boot (u-boot2) inside the first u-boot (u-boot1) ? Is this correct ? Regards, Aubin

2 4

[PATCH v2] efi_loader: Improve console screen clearing and reset
by Jan Kiszka 14 Oct '22

14 Oct '22

From: Jan Kiszka <jan.kiszka(a)siemens.com> Before clearing the screen, ensure that no previous output of firmware or UEFI programs will be overwritten on serial devices or other streaming consoles. This helps generating complete boot logs. Tested regarding multi-output against qemu-x86_defconfig. Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> --- Changes in v2: - rebased and tested against more scenarios, sucessfully lib/efi_loader/efi_console.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c index 60a3fc85ac4..0270b20bafe 100644 --- a/lib/efi_loader/efi_console.c +++ b/lib/efi_loader/efi_console.c @@ -463,8 +463,18 @@ static efi_status_t EFIAPI efi_cout_set_attribute( static efi_status_t EFIAPI efi_cout_clear_screen( struct efi_simple_text_output_protocol *this) { + unsigned int row; + EFI_ENTRY("%p", this); + /* Avoid overwriting previous outputs on streaming consoles */ + for (row = 1; row < efi_cout_modes[efi_con_mode.mode].rows; row++) + printf("\n"); + + /* Set default colors if not done yet */ + if (efi_con_mode.attribute == 0) + efi_cout_set_attribute(this, 0x07); + /* * The Linux console wants both a clear and a home command. The video * uclass does not support <ESC>[H without coordinates, yet. @@ -522,9 +532,9 @@ static efi_status_t EFIAPI efi_cout_reset( { EFI_ENTRY("%p, %d", this, extended_verification); - /* Set default colors */ - efi_con_mode.attribute = 0x07; - printf(ESC "[0;37;40m"); + /* Trigger reset to default colors */ + efi_con_mode.attribute = 0; + /* Clear screen */ EFI_CALL(efi_cout_clear_screen(this)); -- 2.35.3

2 4

[PATCH 0/2] sunxi: update devicetree files from the kernel
by Andre Przywara 13 Oct '22

13 Oct '22

This syncs the .dts and .dtsi files from the Linux kernel repository as of v6.0-rc4 into U-Boot. As before, we skip the r_intc change, as this breaks older kernels. The first patch handles the 64-bit parts, the second one the 32-bit SoCs. Thanks, Andre Andre Przywara (2): sunxi: dts: arm64: update devicetree files sunxi: dts: arm: update devicetree files arch/arm/dts/Makefile | 3 +- arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 40 +-- arch/arm/dts/sun4i-a10-pcduino.dts | 6 +- arch/arm/dts/sun50i-a64-amarula-relic.dts | 2 +- arch/arm/dts/sun50i-a64-bananapi-m64.dts | 4 +- arch/arm/dts/sun50i-a64-nanopi-a64.dts | 2 +- arch/arm/dts/sun50i-a64-olinuxino.dts | 30 ++ arch/arm/dts/sun50i-a64-orangepi-win.dts | 6 +- arch/arm/dts/sun50i-a64-pinebook.dts | 4 +- arch/arm/dts/sun50i-a64-pinephone-1.0.dts | 4 + arch/arm/dts/sun50i-a64-pinephone-1.1.dts | 4 + arch/arm/dts/sun50i-a64-teres-i.dts | 8 + arch/arm/dts/sun50i-a64.dtsi | 10 +- arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts | 4 +- arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 4 +- arch/arm/dts/sun50i-h5-orangepi-prime.dts | 4 +- arch/arm/dts/sun50i-h6-orangepi-3.dts | 4 +- arch/arm/dts/sun50i-h6-orangepi-lite2.dts | 4 +- arch/arm/dts/sun50i-h6-tanix.dtsi | 2 +- arch/arm/dts/sun50i-h6.dtsi | 12 +- arch/arm/dts/sun50i-h616-orangepi-zero2.dts | 55 +--- arch/arm/dts/sun50i-h616-x96-mate.dts | 177 +++++++++++ arch/arm/dts/sun50i-h616.dtsi | 286 +++++------------- arch/arm/dts/sun5i-a13-licheepi-one.dts | 6 +- arch/arm/dts/sun6i-a31.dtsi | 13 +- arch/arm/dts/sun7i-a20-pcduino3.dts | 6 +- arch/arm/dts/sun8i-a23-a33.dtsi | 9 +- arch/arm/dts/sun8i-a23-ippo-q8h-v1.2.dts | 74 +---- arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts | 74 +---- arch/arm/dts/sun8i-a33-et-q8-v1.6.dts | 58 +--- arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts | 58 +--- .../dts/sun8i-h2-plus-bananapi-m2-zero.dts | 8 +- arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 2 +- arch/arm/dts/sun8i-h3-beelink-x2.dts | 6 +- arch/arm/dts/sun8i-h3-mapleboard-mp130.dts | 6 +- arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 8 +- arch/arm/dts/sun8i-h3-nanopi-neo-air.dts | 2 +- arch/arm/dts/sun8i-h3-nanopi-r1.dts | 4 +- arch/arm/dts/sun8i-h3-nanopi.dtsi | 5 +- arch/arm/dts/sun8i-h3-orangepi-2.dts | 6 +- arch/arm/dts/sun8i-h3-orangepi-lite.dts | 4 +- arch/arm/dts/sun8i-h3-orangepi-one.dts | 4 +- arch/arm/dts/sun8i-h3-orangepi-pc.dts | 4 +- arch/arm/dts/sun8i-r16-bananapi-m2m.dts | 4 +- arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts | 5 + arch/arm/dts/sun8i-r40-cpu-opp.dtsi | 52 ++++ arch/arm/dts/sun8i-r40-feta40i.dtsi | 5 + arch/arm/dts/sun8i-r40.dtsi | 44 ++- arch/arm/dts/sun8i-t3-cqa3t-bv3.dts | 5 + arch/arm/dts/sun8i-v3s.dtsi | 6 +- arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts | 5 + arch/arm/dts/sun9i-a80.dtsi | 1 - arch/arm/dts/sunxi-bananapi-m2-plus.dtsi | 8 +- arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi | 4 +- arch/arm/dts/sunxi-h3-h5.dtsi | 13 +- arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi | 4 +- include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 + include/dt-bindings/clock/sun50i-h616-ccu.h | 1 + include/dt-bindings/clock/sun6i-rtc.h | 10 + 59 files changed, 562 insertions(+), 638 deletions(-) create mode 100644 arch/arm/dts/sun50i-h616-x96-mate.dts mode change 100644 => 120000 arch/arm/dts/sun8i-a23-ippo-q8h-v1.2.dts mode change 100644 => 120000 arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts mode change 100644 => 120000 arch/arm/dts/sun8i-a33-et-q8-v1.6.dts mode change 100644 => 120000 arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts create mode 100644 arch/arm/dts/sun8i-r40-cpu-opp.dtsi create mode 100644 include/dt-bindings/clock/sun6i-rtc.h -- 2.35.3

2 4