October 2022 - U-Boot

[PATCH] sandbox: Eliminate CONFIG_HOST_32/64BIT
by Heinrich Schuchardt 14 Oct '22

14 Oct '22

From: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Building sandbox_defconfig on 32bit systems requires manual configuration. we should void this. The compiler provides symbol __LP64__. This is enough to know if the host is a 64bit or a 32bit system. Reported-by: Michal Suchanek <msuchanek(a)suse.de> Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- arch/sandbox/Kconfig | 24 ------------------------ arch/sandbox/include/asm/posix_types.h | 8 +++++++- drivers/misc/swap_case.c | 2 +- include/linux/bitops.h | 2 +- 4 files changed, 9 insertions(+), 27 deletions(-) diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig index 852a7c8bf2..c7668233b9 100644 --- a/arch/sandbox/Kconfig +++ b/arch/sandbox/Kconfig @@ -13,7 +13,6 @@ config SYS_CPU config SANDBOX64 bool "Use 64-bit addresses" select PHYS_64BIT - select HOST_64BIT config SANDBOX_RAM_SIZE_MB int "RAM size in MiB" @@ -41,24 +40,6 @@ config SYS_CONFIG_NAME default "sandbox_spl" if SANDBOX_SPL default "sandbox" if !SANDBOX_SPL -choice - prompt "Run sandbox on 32/64-bit host" - default HOST_64BIT - help - Sandbox can be built on 32-bit and 64-bit hosts. - The default is to build on a 64-bit host and run - on a 64-bit host. If you want to run sandbox on - a 32-bit host, change it here. - -config HOST_32BIT - bool "32-bit host" - depends on !PHYS_64BIT - -config HOST_64BIT - bool "64-bit host" - -endchoice - config SANDBOX_CRASH_RESET bool "Reset on crash" help @@ -68,11 +49,6 @@ config SANDBOX_CRASH_RESET test suites like the UEFI self certification test which continue with the next test after a crash. -config SANDBOX_BITS_PER_LONG - int - default 32 if HOST_32BIT - default 64 if HOST_64BIT - config SYS_FDT_LOAD_ADDR hex "Address at which to load devicetree" default 0x100 diff --git a/arch/sandbox/include/asm/posix_types.h b/arch/sandbox/include/asm/posix_types.h index ec18ed7e3c..0129e91122 100644 --- a/arch/sandbox/include/asm/posix_types.h +++ b/arch/sandbox/include/asm/posix_types.h @@ -19,6 +19,12 @@ * assume GCC is being used. */ +#ifdef __LP64__ +#define SANDBOX_BITS_PER_LONG 64 +#else +#define SANDBOX_BITS_PER_LONG 32 +#endif + typedef unsigned short __kernel_dev_t; typedef unsigned long __kernel_ino_t; typedef unsigned short __kernel_mode_t; @@ -28,7 +34,7 @@ typedef int __kernel_pid_t; typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; -#if CONFIG_SANDBOX_BITS_PER_LONG == 32 +#if SANDBOX_BITS_PER_LONG == 32 typedef unsigned int __kernel_size_t; typedef int __kernel_ssize_t; typedef int __kernel_ptrdiff_t; diff --git a/drivers/misc/swap_case.c b/drivers/misc/swap_case.c index 7093ad1cd4..205ed81750 100644 --- a/drivers/misc/swap_case.c +++ b/drivers/misc/swap_case.c @@ -331,7 +331,7 @@ static int sandbox_swap_case_map_physmem(struct udevice *dev, *ptrp = &pci_ea_bar2_magic; *lenp = PCI_CAP_EA_SIZE_LO; break; -#ifdef CONFIG_HOST_64BIT +#ifdef __LP64__ /* * This cannot be work on a 32-bit machine since *lenp is ulong * which is 32-bits, but it needs to have a 64-bit value diff --git a/include/linux/bitops.h b/include/linux/bitops.h index d2e5ca026e..6456f5ad45 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -28,7 +28,7 @@ */ #ifdef CONFIG_SANDBOX #define GENMASK(h, l) \ - (((~0UL) << (l)) & (~0UL >> (CONFIG_SANDBOX_BITS_PER_LONG - 1 - (h)))) + (((~0UL) << (l)) & (~0UL >> (SANDBOX_BITS_PER_LONG - 1 - (h)))) #else #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h)))) -- 2.37.2

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] riscv: andes_plic.c: use modified IPI scheme
by Yu Chien Peter Lin 14 Oct '22

14 Oct '22

The IPI scheme in OpenSBI has been updated to support 8-core AE350 platform, the plicsw configuration needs to be modified accordingly. Signed-off-by: Yu Chien Peter Lin <peterlin(a)andestech.com> --- arch/riscv/lib/andes_plic.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c index 5e113ee8c9..9fe2568a16 100644 --- a/arch/riscv/lib/andes_plic.c +++ b/arch/riscv/lib/andes_plic.c @@ -27,17 +27,18 @@ /* claim register */ #define CLAIM_REG(base, hart) ((ulong)(base) + 0x200004 + (hart) * 0x1000) -#define ENABLE_HART_IPI (0x80808080) -#define SEND_IPI_TO_HART(hart) (0x80 >> (hart)) +#define ENABLE_HART_IPI (0x01010101) +#define SEND_IPI_TO_HART(hart) (0x1 << (hart)) DECLARE_GLOBAL_DATA_PTR; -static int enable_ipi(int hart) +int enable_ipi(int hart) { unsigned int en; - en = ENABLE_HART_IPI >> hart; + en = ENABLE_HART_IPI << hart; writel(en, (void __iomem *)ENABLE_REG(gd->arch.plic, hart)); + writel(en, (void __iomem *)ENABLE_REG(gd->arch.plic + 0x4, hart)); return 0; } -- 2.34.1

1 0

Re: ext4load failed in the uboot
by Kali 14 Oct '22

14 Oct '22

Hi guys: Do you have some patchs to protect this global vars? kali From: Kali Date: 2022-10-14 11:35 To: u-boot; wd Subject: ext4load failed in the uboot Hi guys: I'm kali. We used this uboot(PDX-License-Identifier:GPL-2.0+) on the rtl11619b soc. We find sometimes ext4load failed. cmd is "ext4load mmc 0:4 0x1400000 emmc.uImage". I guss global vars cause this problem. Maybe,global vars are modified by other app. for example: static block_dev_desc_t *fs_dev_desc; static disk_partition_t fs_partition;( they are included fs.c) struct ext2_data *ext4fs_root;struct ext2fs_node *ext4fs_file; uint32_t *ext4fs_indir1_block;( they are included ext4fs_common.c) Please check it. Thank you! kali

1 0

ext4load failed in the uboot
by Kali 14 Oct '22

14 Oct '22

Hi guys: I'm kali. We used this uboot(PDX-License-Identifier:GPL-2.0+) on the rtl11619b soc. We find sometimes ext4load failed. cmd is "ext4load mmc 0:4 0x1400000 emmc.uImage". I guss global vars cause this problem. Maybe,global vars are modified by other app. for example: static block_dev_desc_t *fs_dev_desc; static disk_partition_t fs_partition;( they are included fs.c) struct ext2_data *ext4fs_root;struct ext2fs_node *ext4fs_file; uint32_t *ext4fs_indir1_block;( they are included ext4fs_common.c) Please check it. Thank you! kali

1 0

[PATCH v4] imx: imx8qm: cgtqmx8: switch to binman
by Oliver Graute 14 Oct '22

14 Oct '22

Switch to use binman to pack images Signed-off-by: Oliver Graute <oliver.graute(a)kococonnector.com> Reviewed-by: Fabio Estevam <festevam(a)denx.de> Reviewed-by: Simon Glass <sjg(a)chromium.org> --- Changes for v4 - rebased on master Changes for v3 -added Reviewed-by - rebased on master arch/arm/dts/imx8qm-cgtqmx8.dts | 1 + arch/arm/mach-imx/imx8/Kconfig | 1 + board/congatec/cgtqmx8/imximage.cfg | 4 ++-- configs/cgtqmx8_defconfig | 2 +- doc/board/congatec/cgtqmx8.rst | 3 +-- 5 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/arm/dts/imx8qm-cgtqmx8.dts b/arch/arm/dts/imx8qm-cgtqmx8.dts index 555c357f6f..919d00644f 100644 --- a/arch/arm/dts/imx8qm-cgtqmx8.dts +++ b/arch/arm/dts/imx8qm-cgtqmx8.dts @@ -12,6 +12,7 @@ /memreserve/ 0x80000000 0x00020000; #include "fsl-imx8qm.dtsi" +#include "imx8qm-u-boot.dtsi" / { model = "Congatec QMX8 Qseven series"; diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig index ba2a38c7f7..a0036a32b5 100644 --- a/arch/arm/mach-imx/imx8/Kconfig +++ b/arch/arm/mach-imx/imx8/Kconfig @@ -76,6 +76,7 @@ config TARGET_IMX8QM_MEK config TARGET_CONGA_QMX8 bool "Support congatec conga-QMX8 board" + select BINMAN select BOARD_LATE_INIT select SUPPORT_SPL select IMX8QM diff --git a/board/congatec/cgtqmx8/imximage.cfg b/board/congatec/cgtqmx8/imximage.cfg index 5ecde0c530..43035088e3 100644 --- a/board/congatec/cgtqmx8/imximage.cfg +++ b/board/congatec/cgtqmx8/imximage.cfg @@ -4,8 +4,8 @@ */ -/* Boot from SD, sector size 0x400 */ -BOOT_FROM SD 0x400 +BOOT_FROM sd + /* SoC type IMX8QM */ SOC_TYPE IMX8QM /* Append seco container image */ diff --git a/configs/cgtqmx8_defconfig b/configs/cgtqmx8_defconfig index ddc65a06b9..6b72afa80d 100644 --- a/configs/cgtqmx8_defconfig +++ b/configs/cgtqmx8_defconfig @@ -21,7 +21,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80200000 CONFIG_REMAKE_ELF=y CONFIG_FIT=y CONFIG_SPL_LOAD_FIT=y -CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh" +# CONFIG_USE_SPL_FIT_GENERATOR is not set CONFIG_OF_BOARD_SETUP=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTCOMMAND=y diff --git a/doc/board/congatec/cgtqmx8.rst b/doc/board/congatec/cgtqmx8.rst index bccdef2f16..16711a844d 100644 --- a/doc/board/congatec/cgtqmx8.rst +++ b/doc/board/congatec/cgtqmx8.rst @@ -57,8 +57,7 @@ Build U-Boot $ export ATF_LOAD_ADDR=0x80000000 $ export BL33_LOAD_ADDR=0x80020000 $ make cgtqmx8_defconfig - $ make u-boot.bin - $ make flash.bin + $ make Flash the binary into the SD card --------------------------------- -- 2.17.1

2 1

[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

[PATCH 1/2] image: Suppress string truncation warning
by Michal Suchanek 13 Oct '22

13 Oct '22

In file included from ../tools/imagetool.h:24, from ../tools/default_image.c:16: In function ‘image_set_name’, inlined from ‘image_set_header’ at ../tools/default_image.c:133:2: ../include/image.h:786:9: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] 786 | strncpy(image_get_name(hdr), name, IH_NMLEN); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is no standard function that can be used to make the copy without a warning. Signed-off-by: Michal Suchanek <msuchanek(a)suse.de> --- include/image.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/include/image.h b/include/image.h index d7d6a3fe5b..e08ef6ed55 100644 --- a/include/image.h +++ b/include/image.h @@ -783,7 +783,14 @@ image_set_hdr_b(comp) /* image_set_comp */ static inline void image_set_name(struct legacy_img_hdr *hdr, const char *name) { +#if defined(__GNUC__) && (__GNUC__ > 7) +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstringop-truncation" +#endif strncpy(image_get_name(hdr), name, IH_NMLEN); +#if defined(__GNUC__) && (__GNUC__ > 7) +#pragma GCC diagnostic pop +#endif } int image_check_hcrc(const struct legacy_img_hdr *hdr); -- 2.37.3

4 4

[PATCH] fastboot: mmc: switch to user hwpart after erase/flash
by Mattijs Korpershoek 13 Oct '22

13 Oct '22

Before erasing (or flashing) an mmc hardware partition, such as mmc0boot0 or mmc0boot1, we select it using blk_dselect_hwpart(). However, we don't select back the normal (userdata) hwpartition afterwards. For example, the following sequence is broken: $ fastboot erase mmc2boot1 # switch to hwpart 1 $ fastboot reboot bootloader # attempts to read GPT from hwpart 1 > writing 128 blocks starting at 8064... > ........ wrote 65536 bytes to 'mmc0boot1' > GUID Partition Table Header signature is wrong: 0xFB4EC30FC5B7E5B2 != 0x5452415020494645 > find_valid_gpt: *** ERROR: Invalid GPT *** > GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645 > find_valid_gpt: *** ERROR: Invalid Backup GPT *** > Error: mmc 2:misc read failed (-2) The GPT is stored in hwpart0 (userdata), not hwpart1 (mmc0boot1) As the blk documentation states: > Once selected only the region of the device > covered by that partition is accessible. Add a cleanup function, fastboot_mmc_select_default_hwpart() which selects back the default hwpartition (userdata). Note: this is more visible since commit a362ce214f03 ("fastboot: Implement generic fastboot_set_reboot_flag") because "fastboot reboot bootloader" will access the "misc" partition. Signed-off-by: Mattijs Korpershoek <mkorpershoek(a)baylibre.com> --- This fix has been used for over a year in the AOSP tree at [1] [1] https://android.googlesource.com/device/amlogic/yukawa/+/c008ddaec0943adda3… --- drivers/fastboot/fb_mmc.c | 20 +++++++++++++++++--- include/mmc.h | 1 + 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c index 033c510bc096..dedef7c4deb1 100644 --- a/drivers/fastboot/fb_mmc.c +++ b/drivers/fastboot/fb_mmc.c @@ -199,6 +199,12 @@ static void write_raw_image(struct blk_desc *dev_desc, fastboot_okay(NULL, response); } +static void fastboot_mmc_select_default_hwpart(struct blk_desc *dev_desc) +{ + if (blk_dselect_hwpart(dev_desc, MMC_PART_USERDATA)) + pr_err("Failed to restore hwpart to userdata\n"); +} + #if defined(CONFIG_FASTBOOT_MMC_BOOT_SUPPORT) || \ defined(CONFIG_FASTBOOT_MMC_USER_SUPPORT) static int fb_mmc_erase_mmc_hwpart(struct blk_desc *dev_desc) @@ -246,7 +252,7 @@ static void fb_mmc_boot_ops(struct blk_desc *dev_desc, void *buffer, if (blkcnt > dev_desc->lba) { pr_err("Image size too large\n"); fastboot_fail("Image size too large", response); - return; + goto fail_restore_hwpart; } debug("Start Flashing Image to EMMC_BOOT%d...\n", hwpart); @@ -257,7 +263,7 @@ static void fb_mmc_boot_ops(struct blk_desc *dev_desc, void *buffer, pr_err("Failed to write EMMC_BOOT%d\n", hwpart); fastboot_fail("Failed to write EMMC_BOOT part", response); - return; + goto fail_restore_hwpart; } printf("........ wrote %lu bytes to EMMC_BOOT%d\n", @@ -267,11 +273,15 @@ static void fb_mmc_boot_ops(struct blk_desc *dev_desc, void *buffer, pr_err("Failed to erase EMMC_BOOT%d\n", hwpart); fastboot_fail("Failed to erase EMMC_BOOT part", response); - return; + goto fail_restore_hwpart; } } fastboot_okay(NULL, response); + return; + +fail_restore_hwpart: + fastboot_mmc_select_default_hwpart(dev_desc); } #endif @@ -630,6 +640,8 @@ void fastboot_mmc_flash_write(const char *cmd, void *download_buffer, write_raw_image(dev_desc, &info, cmd, download_buffer, download_bytes, response); } + + fastboot_mmc_select_default_hwpart(dev_desc); } /** @@ -694,6 +706,8 @@ void fastboot_mmc_erase(const char *cmd, char *response) blks = fb_mmc_blk_write(dev_desc, blks_start, blks_size, NULL); + fastboot_mmc_select_default_hwpart(dev_desc); + if (blks != blks_size) { pr_err("failed erasing from device %d\n", dev_desc->devnum); fastboot_fail("failed erasing from device", response); diff --git a/include/mmc.h b/include/mmc.h index 027e8bcc73a6..cdd457a60a5b 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -362,6 +362,7 @@ enum mmc_voltage { /* The number of MMC physical partitions. These consist of: * boot partitions (2), general purpose partitions (4) in MMC v4.4. */ +#define MMC_PART_USERDATA 0 #define MMC_NUM_BOOT_PARTITION 2 #define MMC_PART_RPMB 3 /* RPMB partition number */ --- base-commit: f5717231abad983b4d8f87db612ae60dec86cb1b change-id: 20221010-switch-hwpart-7fed7746db59 Best regards, -- Mattijs Korpershoek <mkorpershoek(a)baylibre.com>

2 4

[PATCH v3] schemas: Add schema for U-Boot driver model 'phase tags'
by Simon Glass 13 Oct '22

13 Oct '22

Until recently it has not been possible to add any U-Boot-specific properties to the device tree schema. Now that it is somewhat separated from Linux and people are feeling the enormous pain of the bifurcated schema, it seems like a good time to add this and other U-Boot-specific bindings. U-Boot has some particular challenges with device tree and devices which are not faced with Linux: - U-Boot has multiple build phases, such as a Secondary Program Loader (SPL) phase which typically runs in a pre-SDRAM environment where code and data space are limited. In particular, there may not be enough space for the full device tree blob. U-Boot uses various automated techniques to reduce the size from perhaps 40KB to 3KB. - Some U-Boot phases needs to run before the clocks are properly set up, where the CPU may be running very slowly. Therefore it is important to bind only those devices which are actually needed in that phase - Unlike Linux or UEFI, U-Boot uses lazy initialisation for its devices, with 'bind' and 'probe' being separate steps. Even if a device is bound, it is not actually probed until it is used. This is necessary to keep the boot time reasonable, e.g. to under a second The phases of U-Boot in order are: TPL, VPL, SPL, U-Boot (first pre-relocation, then post-relocation). ALl but the last two are optional. For the above reasons, U-Boot only includes the full device tree in the final 'U-Boot proper' build. Even then, before relocation U-Boot only processes nodes which are marked as being needed. For this to work, U-Boot's driver model[1] provides a way to mark device tree nodes as applicable for a particular phase. This works by adding a tag to the node, e.g.: cru: clock-controller@ff760000 { u-boot,dm-all; compatible = "rockchip,rk3399-cru"; reg = <0x0 0xff760000 0x0 0x1000>; rockchip,grf = <&grf>; #clock-cells = <1>; #reset-cells = <1>; ... }; Here the "u-boot,dm-all" tag indicates that the node must be present in all phases, since the clock driver is required There has been discussion over the years about whether this could be done in a property instead, e.g. options { u-boot,dm-all = <&cru> <&gpio_a> ...; ... }; Some problems with this: - we need to be able to merge several such tags from different .dtsi files since many boards have their own specific requirements - it is hard to find and cross-reference the affected nodes - it is more error-prone - it requires significant tool rework in U-Boot, including fdtgrep and the build system - is harder (slower, more code) to process since it involves scanning another node/property to find out what to do with a particular node - we don't want to add phandle arguments to the above since we are referring, e.g., to the clock device as a whole, not a paricular clock - the of-platdata feature[2], which converts device tree to C for even more constrained environments, would need to become aware of the /options node There is also the question about whether this needs to be U-Boot-specific, or whether the tags could be generic. From what I can tell, U-Boot is the only bootloader which seriously attempts to use a runtime device tree in all cases. We could perhaps adopt U-Boot's naming for the phases and drop the "u-boot," prefix, but that might cause confusion. It should also be noted that the approach provided here has stood the test of time, used in U-Boot for 8 years so far. So add the schema for this. This will allow a major class of schema exceptions to be dropped from the U-Boot source tree. This being sent to the mailing list since it might attract more review. A PR will be sent when this has had some review. That is why the file path is set up for https://github.com/devicetree-org/dt-schema rather than the Linux kernel. [1] https://u-boot.readthedocs.io/en/latest/develop/driver-model/index.html [2] https://u-boot.readthedocs.io/en/latest/develop/driver-model/of-plat.html Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Changes in v3: - Fix an incorrect schema path in $id Changes in v2: - Expand docs to include a description of each tag - Fix some typos and unclear wording dtschema/schemas/u-boot.yaml | 66 ++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 dtschema/schemas/u-boot.yaml diff --git a/dtschema/schemas/u-boot.yaml b/dtschema/schemas/u-boot.yaml new file mode 100644 index 0000000..b888b3e --- /dev/null +++ b/dtschema/schemas/u-boot.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: BSD-2-Clause +# Copyright 2022 Google LLC +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/u-boot.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings required by U-Boot driver model + +maintainers: + - Simon Glass <sjg(a)chromium.org> + +patternProperties: + "^u-boot,dm-(tpl|vpl|spl|all|pre-reloc)$": + type: boolean + description: | + The device tree is often quite large (e.g. 40KB) and cannot fit into xPL + phases like SPL, TPL. Even with U-Boot proper, we normally only want to + init a small subset of devices before relocation. + + U-Boot supports adding tags to device tree nodes to allow them to be + marked according to the U-Boot phases where they should be included. + + Without any tags, nodes are included only in U-Boot proper after + relocation. Any untagged nodes are dropped from xPL and are ignored before + relocation in U-Boot proper. + + The xPL builds use fdtgrep drop any nodes which are not needed for that + build. For example, TPL will drop any nodes which are not marked with + u-boot,dm-tpl or u-boot,dm-all tags. + + The available tags are as follows: + + u-boot,dm-all: + Include this node in all phases (see enum u_boot_phase) + + u-boot,dm-pre-reloc: + Enable this node before relocation in U-Boot proper + + u-boot,dm-tpl: + Enable this node in the Tertiary Program Loader (TPL) + + u-boot,dm-vpl: + Enable this node in the Verifying Program Loader (VPL) + + u-boot,dm-spl: + Enable this node in the Secondary Program Loader (SPL) + + Note that xPL builds also drop the tags, since they have served their + purpose by that point. So when looking at xPL device tree files you will + not see these tags. This means, for example, that ofnode_pre_reloc() + always returns true in xPL builds. This is done to save space. + + Multiple tags can be used in the same node. + + One complication is that tags apply only to the node they are added to, + not to any parents. This means that you often need to add the same tag to + parent nodes so that any properties needed by the parent driver are + included. Without that, the parent node may have no properties, or may not + be bound before relocation (meaning that its child will not be bound + either). + + The phases of U-Boot in order are: TPL, VPL, SPL, U-Boot (first + pre-relocation, then post-relocation). ALl but the last two are optional. + +additionalProperties: true -- 2.38.0.rc1.362.ged0d419d3c-goog

4 5