September 2022 - U-Boot

[PATCH v2] schemas: Add schema for U-Boot driver model 'phase tags'
by Simon Glass 30 Sep '22

30 Sep '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 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..0674684 --- /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/serial.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

1 0

[PATCH] common: board_f: Fix crash in print_cpuinfo
by Christian Kohlschütter 30 Sep '22

30 Sep '22

With CONFIG_DISPLAY_CPUINFO=y and CONFIG_CPU=y, the initcall sequence may fail (and therefore hang the boot process) with an -ENODEV (err=-19) error code. This is caused by either cpu_get_current_dev/cpu_get_desc failing to return CPU information. If no CPU information can be obtained, fall-back to the non-Driver Model implementation of print_cpuinfo. Signed-off-by: Christian Kohlschütter <christian(a)kohlschutter.com> --- common/board_f.c | 14 +++++++++----- include/init.h | 3 +-- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/common/board_f.c b/common/board_f.c index 18e2246733..0656845e24 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -182,9 +182,12 @@ static int print_resetinfo(void) } #endif -#if defined(CONFIG_DISPLAY_CPUINFO) && CONFIG_IS_ENABLED(CPU) -static int print_cpuinfo(void) +#if defined(CONFIG_DISPLAY_CPUINFO) +static int print_cpuinfo_0(void) { +#if !CONFIG_IS_ENABLED(CPU) + return print_cpuinfo(); +#else struct udevice *dev; char desc[512]; int ret; @@ -193,19 +196,20 @@ static int print_cpuinfo(void) if (!dev) { debug("%s: Could not get CPU device\n", __func__); - return -ENODEV; + return print_cpuinfo(); // fallback } ret = cpu_get_desc(dev, desc, sizeof(desc)); if (ret) { debug("%s: Could not get CPU description (err = %d)\n", dev->name, ret); - return ret; + return print_cpuinfo(); // fallback } printf("CPU: %s\n", desc); return 0; +#endif } #endif @@ -866,7 +870,7 @@ static const init_fnc_t init_sequence_f[] = { print_resetinfo, #endif #if defined(CONFIG_DISPLAY_CPUINFO) - print_cpuinfo, /* display cpu info (and speed) */ + print_cpuinfo_0, /* display cpu info (and speed) */ #endif #if defined(CONFIG_DTB_RESELECT) embedded_dtb_select, diff --git a/include/init.h b/include/init.h index 7b8f62c121..9837c22b75 100644 --- a/include/init.h +++ b/include/init.h @@ -210,14 +210,13 @@ int pci_init(void); */ int init_cache_f_r(void); -#if !CONFIG_IS_ENABLED(CPU) /** * print_cpuinfo() - Display information about the CPU * * Return: 0 if OK, -ve on error */ int print_cpuinfo(void); -#endif + int timer_init(void); #if defined(CONFIG_DTB_RESELECT) -- 2.36.2

2 3

[PATCH RESEND] fs: btrfs: remove the usage of undeclared fs_mutex variable
by Pankaj Raghav 29 Sep '22

29 Sep '22

This line probably got in by mistake as there is no fs_mutex member in the btrfs_fs_info struct. Signed-off-by: Pankaj Raghav <p.raghav(a)samsung.com> --- For UBOOT. The patch I sent the first time is not showing up in the uboot mailing list because of the missing approval. So, resending the patch. fs/btrfs/disk-io.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 8043abc1bd..c80f8e8028 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -782,8 +782,6 @@ struct btrfs_fs_info *btrfs_new_fs_info(void) fs_info->fs_root_tree = RB_ROOT; cache_tree_init(&fs_info->mapping_tree.cache_tree); - mutex_init(&fs_info->fs_mutex); - return fs_info; free_all: btrfs_free_fs_info(fs_info); -- 2.25.1

3 2

[PATCH] configs: rockchip: Drop TPL_MAX_SIZE definition
by Michael Trimarchi 29 Sep '22

29 Sep '22

The max size is defined at architectural level. On the same commit I have checked mostly all the other architecture and look like they are Fixes: commit ca8a329a1b7f ("Convert CONFIG_SPL_PAD_TO et al to Kconfig") Signed-off-by: Michael Trimarchi <michael(a)amarulasolutions.com> --- configs/evb-px30_defconfig | 1 - configs/evb-px5_defconfig | 1 - configs/evb-rk3229_defconfig | 1 - configs/evb-rk3328_defconfig | 1 - configs/firefly-px30_defconfig | 1 - configs/lion-rk3368_defconfig | 1 - configs/nanopi-r2s-rk3328_defconfig | 1 - configs/odroid-go2_defconfig | 1 - configs/px30-core-ctouch2-of10-px30_defconfig | 1 - configs/px30-core-ctouch2-px30_defconfig | 1 - configs/px30-core-edimm2.2-px30_defconfig | 1 - configs/roc-cc-rk3328_defconfig | 1 - configs/rock-pi-e-rk3328_defconfig | 1 - configs/rock64-rk3328_defconfig | 1 - 14 files changed, 14 deletions(-) diff --git a/configs/evb-px30_defconfig b/configs/evb-px30_defconfig index 240a044b2a..4f88879e18 100644 --- a/configs/evb-px30_defconfig +++ b/configs/evb-px30_defconfig @@ -17,7 +17,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/evb-px5_defconfig b/configs/evb-px5_defconfig index 8112b42c94..40df2892e5 100644 --- a/configs/evb-px5_defconfig +++ b/configs/evb-px5_defconfig @@ -19,7 +19,6 @@ CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig index c8833e68ec..442f504826 100644 --- a/configs/evb-rk3229_defconfig +++ b/configs/evb-rk3229_defconfig @@ -17,7 +17,6 @@ CONFIG_SPL_STACK_R_ADDR=0x60600000 CONFIG_DEBUG_UART_BASE=0x11030000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x61800800 -CONFIG_TPL_MAX_SIZE=0x100000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x61100000 diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig index 251cc3f3cf..2782a3901d 100644 --- a/configs/evb-rk3328_defconfig +++ b/configs/evb-rk3328_defconfig @@ -16,7 +16,6 @@ CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/firefly-px30_defconfig b/configs/firefly-px30_defconfig index 4bc2031086..1717eb2110 100644 --- a/configs/firefly-px30_defconfig +++ b/configs/firefly-px30_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/lion-rk3368_defconfig b/configs/lion-rk3368_defconfig index 5f7c5a0091..33cd0c37c6 100644 --- a/configs/lion-rk3368_defconfig +++ b/configs/lion-rk3368_defconfig @@ -18,7 +18,6 @@ CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/nanopi-r2s-rk3328_defconfig b/configs/nanopi-r2s-rk3328_defconfig index 4dfb7782d9..86f5e111f8 100644 --- a/configs/nanopi-r2s-rk3328_defconfig +++ b/configs/nanopi-r2s-rk3328_defconfig @@ -16,7 +16,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/odroid-go2_defconfig b/configs/odroid-go2_defconfig index f8e432239b..c0c0c4daee 100644 --- a/configs/odroid-go2_defconfig +++ b/configs/odroid-go2_defconfig @@ -20,7 +20,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/px30-core-ctouch2-of10-px30_defconfig b/configs/px30-core-ctouch2-of10-px30_defconfig index 625460b34e..2fb8bd8a23 100644 --- a/configs/px30-core-ctouch2-of10-px30_defconfig +++ b/configs/px30-core-ctouch2-of10-px30_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/px30-core-ctouch2-px30_defconfig b/configs/px30-core-ctouch2-px30_defconfig index bca4698212..76f81ae437 100644 --- a/configs/px30-core-ctouch2-px30_defconfig +++ b/configs/px30-core-ctouch2-px30_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/px30-core-edimm2.2-px30_defconfig b/configs/px30-core-edimm2.2-px30_defconfig index c13af9320e..8493500a06 100644 --- a/configs/px30-core-edimm2.2-px30_defconfig +++ b/configs/px30-core-edimm2.2-px30_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/roc-cc-rk3328_defconfig b/configs/roc-cc-rk3328_defconfig index 8e2e5302e4..8ba50345da 100644 --- a/configs/roc-cc-rk3328_defconfig +++ b/configs/roc-cc-rk3328_defconfig @@ -16,7 +16,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/rock-pi-e-rk3328_defconfig b/configs/rock-pi-e-rk3328_defconfig index 9831670137..fb5eac3c1f 100644 --- a/configs/rock-pi-e-rk3328_defconfig +++ b/configs/rock-pi-e-rk3328_defconfig @@ -17,7 +17,6 @@ CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 9ca6f3a3a1..b055dd0979 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -16,7 +16,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 -- 2.34.1

5 8

[PATCH] vexpress64: also consider DTB pointer in x1
by Andre Przywara 29 Sep '22

29 Sep '22

Commit c0fce929564f("vexpress64: fvp: enable OF_CONTROL") added code to consider a potential DTB address being passed in the x0 register, or revert to the built-in DTB otherwise. The former case was used when using the boot-wrapper, to which we sell U-Boot as a Linux kernel. The latter was meant for TF-A, for which we couldn't find an easy way to use the DTB it uses itself. We have some quirk to filter for a valid DTB, as TF-A happens to pass a pointer to some special devicetree blob in x0 as well. Now the TF-A case is broken, when enabling proper emulation of secure memory (-C bp.secure_memory=1). TF-A carves out some memory at the top of the first DRAM bank for its own purposes, and configures the TrustZone DRAM controller to make this region secure-only. U-Boot will then hang when it tries to relocate itself exactly to the end of DRAM. TF-A announces this by carving out that region of the /memory node, in the DT it passes on to BL33 in x1, but we miss that so far. Instead of repeating this carveout in our DT copy, let's try to look for a DTB at the address x1 points to as well. This will let U-Boot pick up the DTB provided by TF-A, which has the correct carveout in place, avoiding the hang. While we are at it, make the detection more robust: the length test (is the DT larger than 256 bytes?) is too fragile, in fact the TF-A port for a new FVP model already exceeds this. So we test x1 first, consider 0 an invalid address, and also require a /memory node to detect a valid DTB. And for the records: Some asking around revealed what is really going on with TF-A and that ominous DTB pointer in x0: TF-A expects EDK-2 as its non-secure payload (BL33), and there apparently was some long-standing ad-hoc boot protocol defined just between the two: x0 would carry the MPIDR register value of the boot CPU, and the hardware DTB address would be stored in x1. Now the MPIDR of CPU 0 is typically 0, plus bit 31 set, which is defined as RES1 in the ARMv7 and ARMv8 architectures. This gives 0x80000000, which is the same value as the address of the beginning of DRAM (2GB). And coincidentally TF-A put some DTB structure exactly there, for its own purposes (passing it between stages). So U-Boot was trying to use this DTB, which requires the quirk to check for its validity. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- board/armltd/vexpress64/lowlevel_init.S | 2 +- board/armltd/vexpress64/vexpress64.c | 27 +++++++++++++++++++++---- 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/board/armltd/vexpress64/lowlevel_init.S b/board/armltd/vexpress64/lowlevel_init.S index 3dcfb85d0e9..68ca3f26e96 100644 --- a/board/armltd/vexpress64/lowlevel_init.S +++ b/board/armltd/vexpress64/lowlevel_init.S @@ -7,6 +7,6 @@ save_boot_params: adr x8, prior_stage_fdt_address - str x0, [x8] + stp x0, x1, [x8] b save_boot_params_ret diff --git a/board/armltd/vexpress64/vexpress64.c b/board/armltd/vexpress64/vexpress64.c index 05a7a25c32e..af326dc6f45 100644 --- a/board/armltd/vexpress64/vexpress64.c +++ b/board/armltd/vexpress64/vexpress64.c @@ -100,7 +100,7 @@ int dram_init_banksize(void) * Push the variable into the .data section so that it * does not get cleared later. */ -unsigned long __section(".data") prior_stage_fdt_address; +unsigned long __section(".data") prior_stage_fdt_address[2]; #ifdef CONFIG_OF_BOARD @@ -151,6 +151,23 @@ static phys_addr_t find_dtb_in_nor_flash(const char *partname) } #endif +/* + * Filter for a valid DTB, as TF-A happens to provide a pointer to some + * data structure using the DTB format, which we cannot use. + * The address of the DTB cannot be 0, in fact this is the reserved value + * for x1 in the kernel boot protocol. + * And while the nt_fw_config.dtb used by TF-A is a valid DTB structure, it + * does not contain the typical nodes and properties, which we test for by + * probing for the mandatory /memory node. + */ +static bool is_valid_dtb(uintptr_t dtb_ptr) +{ + if (dtb_ptr == 0 || fdt_magic(dtb_ptr) != FDT_MAGIC) + return false; + + return fdt_subnode_offset((void *)dtb_ptr, 0, "memory") >= 0; +} + void *board_fdt_blob_setup(int *err) { #ifdef CONFIG_TARGET_VEXPRESS64_JUNO @@ -172,10 +189,12 @@ void *board_fdt_blob_setup(int *err) } #endif - if (fdt_magic(prior_stage_fdt_address) == FDT_MAGIC && - fdt_totalsize(prior_stage_fdt_address) > 0x100) { + if (is_valid_dtb(prior_stage_fdt_address[1])) { + *err = 0; + return (void *)prior_stage_fdt_address[1]; + } else if (is_valid_dtb(prior_stage_fdt_address[0])) { *err = 0; - return (void *)prior_stage_fdt_address; + return (void *)prior_stage_fdt_address[0]; } if (fdt_magic(gd->fdt_blob) == FDT_MAGIC) { -- 2.25.1

3 5

[PATCH] board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data
by Nishanth Menon 29 Sep '22

29 Sep '22

The situation is similar to commit bf6376642fe8 ("board: ti: common: board_detect: Fix EEPROM read quirk"). This is seen on a variant of eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte addressing and 2 byte addressing eeproms. Unlike the am335x (ti_i2c_eeprom_am_get) and dra7 (ti_i2c_eeprom_dra7_get) which use constant data structure which allows us to do a complete read of the data, the am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic. This removes the option of being able to read the complete eeprom data in one single shot. Fortunately, on the I2C bus, we do see the following behavior: In 1 byte mode, if we attempt to read the first header data yet again, the misbehaving 2 byte addressing device acts in constant addressing mode which results in the header not matching up and follow on attempt at 2 byte addressing scheme grabs the correct data. This costs us an extra ~3 milliseconds, which is a minor penalty compared to the consistent image support we need to have. Reported-by: Jason Kridner <jkridner(a)beagleboard.org> Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Signed-off-by: Nishanth Menon <nm(a)ti.com> --- BeagleBone-AI64 logs with this patch: With 1 byte addressing eeproms : https://www.irccloud.com/pastebin/XRjFVW82/ With quirky 2 byte addressing eeproms: https://www.irccloud.com/pastebin/eCQugpP6/ Wave capture of the quirky 2 byte addressing with this patch: https://pasteboard.co/bcNQyj3MVOpG.png board/ti/common/board_detect.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c index 9fa7b7beb63f..b959041cd22f 100644 --- a/board/ti/common/board_detect.c +++ b/board/ti/common/board_detect.c @@ -444,6 +444,16 @@ int __maybe_unused ti_i2c_eeprom_am6_get(int bus_addr, int dev_addr, if (rc) return rc; + /* + * Handle case of bad 2 byte eeproms that responds to 1 byte addressing + * but gets stuck in const addressing when read requests are performed + * on offsets. We re-read the board ID to ensure we have sane data back + */ + rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC, + sizeof(board_id), (uint8_t *)&board_id); + if (rc) + return rc; + if (board_id.header.id != TI_AM6_EEPROM_RECORD_BOARD_ID) { pr_err("%s: Invalid board ID record!\n", __func__); return -EINVAL; -- 2.31.1

2 1

[PATCH] tools: env: Fix missing closedir in ubi_get_volnum_by_name
by Miaoqian Lin 29 Sep '22

29 Sep '22

The function calls opendir() but missing the corresponding closedir() before exit the function. Add missing closedir() to fix it. Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- tools/env/fw_env.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 2a61a5d6f049..eb138accdcbe 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -192,10 +192,13 @@ static int ubi_get_volnum_by_name(int devnum, const char *volname) &tmp_devnum, &volnum); if (ret == 2 && devnum == tmp_devnum) { if (ubi_check_volume_sysfs_name(dirent->d_name, - volname) == 0) + volname) == 0) { + closedir(sysfs_ubi); return volnum; + } } } + closedir(sysfs_ubi); return -1; } -- 2.25.1

2 1

[PATCH] pci: Remove duplicate PCI_REGION_IO / "io" line
by Pali Rohár 29 Sep '22

29 Sep '22

Signed-off-by: Pali Rohár <pali(a)kernel.org> --- cmd/pci.c | 1 - 1 file changed, 1 deletion(-) diff --git a/cmd/pci.c b/cmd/pci.c index 6258699fec81..58a74755c8b2 100644 --- a/cmd/pci.c +++ b/cmd/pci.c @@ -450,11 +450,10 @@ static const struct pci_flag_info { } pci_flag_info[] = { { PCI_REGION_IO, "io" }, { PCI_REGION_PREFETCH, "prefetch" }, { PCI_REGION_SYS_MEMORY, "sysmem" }, { PCI_REGION_RO, "readonly" }, - { PCI_REGION_IO, "io" }, }; static void pci_show_regions(struct udevice *bus) { struct pci_controller *hose = dev_get_uclass_priv(pci_get_controller(bus)); -- 2.20.1

4 3

[ISSUE] Failure to compile for MIPS32 using maltael_defconfig
by Majid B. 29 Sep '22

29 Sep '22

Hello, I've tried to build U-Boot 2022.07 with the following series of instructions: export CROSS_COMPILE=mipsel-linux-gnu- make mrproper make O=build maltael_defconfig make V=1 O=build -j$(nproc) Unfortunately, I seem to always run into this error: In file included from arch/mips/lib/cache.c:10: ./arch/mips/include/asm/cacheops.h: In function ‘flush_cache’: ./arch/mips/include/asm/cacheops.h:18:9: error: invalid argument to built-in function 18 | __builtin_mips_cache(op, addr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ make[1]: *** [scripts/Makefile.build:257: arch/mips/lib/cache.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:1906: arch/mips/lib] Error 2 make: *** Waiting for unfinished jobs.... What could I be doing wrong? I'd really appreciate any help I can get on this. Thank you in advance! Regards, Majid B.

2 1

[PATCH] dm: automatically set DM_FLAG_PRE_RELOC based on device-tree property
by Quentin Schulz 29 Sep '22

29 Sep '22

From: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> One needs to set u-boot,dm-pre-reloc in a device Device Tree node so that it is kept in SPL/TPL variant of the device tree. However, a device is automatically probed only if it's flagged with DM_FLAG_PRE_RELOC, regardless of u-boot,dm-pre-reloc DT property presence. This flag is currently only set by drivers directly. However, this flag should be allowed to be set on a per-device basis even if the driver does not hardcode it so that the device will be probed in SPL/TPL regardless of the driver's defaults. This sets the DM_FLAG_PRE_RELOC for all U_BOOT_CLASS devices whose DT node contains the u-boot,dm-pre-reloc property. Cc: Quentin Schulz <foss+uboot(a)0leil.net> Signed-off-by: Quentin Schulz <quentin.schulz(a)theobroma-systems.com> --- drivers/core/lists.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/core/lists.c b/drivers/core/lists.c index c49695b24f..86b75ffede 100644 --- a/drivers/core/lists.c +++ b/drivers/core/lists.c @@ -260,6 +260,9 @@ int lists_bind_fdt(struct udevice *parent, ofnode node, struct udevice **devp, ret); return log_msg_ret("bind", ret); } else { + if (ofnode_pre_reloc(node)) + dev_or_flags(dev, DM_FLAG_PRE_RELOC); + found = true; if (devp) *devp = dev; -- 2.37.3

5 5