December 2024 - U-Boot

[PATCH v1 0/8] Cleanup the LMB subsystem
by Ilias Apalodimas 13 Dec '24

13 Dec '24

Hi all, This is v1 of the rfc [0] The LMB subsystem was used opportunistically for a number of years. A while back Sughosh merged it with the EFI subsystem in order to have a common allocator and avoid subsystems overwriting memory they shouldn't. This is an initial cleanup of all the crud we gathered over the years. There's no functional change expected from the patches as they just cleanup some abstraction functions and rename a few variables to make more sense. I plan to make even bigger changes -- e.g I don't see the point of having *_alloc() and *_reserve() versions of the functions since they mostly do the same thing and just cause confusion. lmb_alloc_addr_flags() returning the base address on success makes little sense since we already *request* the address on the function arguments, etc. Since this patchset grew enough already, I'd like to get it in before more refactoring happens. It's worth noting that although some patches slightly increase the code size due to an extra flags argument being carried around, the final result is eventually smaller. # qemu_arm64_lwip_defconfig (version string adds another 20b) add/remove: 0/5 grow/shrink: 15/1 up/down: 568/-628 (-60) Function old new delta lmb_alloc_base 80 324 +244 lmb_alloc_addr 8 144 +136 lmb_reserve 8 96 +88 version_string 50 70 +20 boot_relocate_fdt 488 508 +20 boot_ramdisk_high 268 284 +16 lmb_add_region_flags 696 704 +8 boot_fdt_reserve_region 100 108 +8 load_serial 548 552 +4 lmb_alloc 8 12 +4 image_setup_libfdt 368 372 +4 do_load 728 732 +4 do_bootz 332 336 +4 do_booti 520 524 +4 bootm_run_states 2176 2180 +4 lmb_alloc_addr_flags 4 - -4 boot_fdt_add_mem_rsv_regions 284 280 -4 lmb_alloc_base_flags 76 - -76 lmb_reserve_flags 96 - -96 _lmb_alloc_addr 144 - -144 _lmb_alloc_base 304 - -304 Total: Before=1020102, After=1020042, chg -0.01% # sandbox_defconfig (version string adds another 20b) add/remove: 0/3 grow/shrink: 24/3 up/down: 523/-501 (22) Function old new delta lmb_alloc_base 48 299 +251 lmb_alloc_addr 4 92 +88 lmb_reserve 4 58 +54 test_alloc_addr 2933 2963 +30 version_string 50 70 +20 lib_test_lmb_overlapping_reserve 1018 1030 +12 lmb_add_region_flags 600 610 +10 test_multi_alloc.constprop 3034 3042 +8 test_get_unreserved_size 1032 1038 +6 boot_relocate_fdt 599 605 +6 boot_fdt_reserve_region 67 73 +6 lmb_alloc 4 9 +5 lmb_free_flags 190 194 +4 wget_handler 1530 1533 +3 tftp_handler 1190 1192 +2 test_noreserved 1207 1209 +2 test_bigblock 911 913 +2 load_serial 946 948 +2 lib_test_lmb_flags 2101 2103 +2 do_spi_flash 3150 3152 +2 do_bootz 526 528 +2 do_bootm_linux 2067 2069 +2 bootm_run_states 5275 5277 +2 _fs_read.lto_priv 331 333 +2 lmb_dump_region.lto_priv 356 353 -3 lmb_add 59 52 -7 efi_allocate_pages.part 303 249 -54 lmb_reserve_flags 65 - -65 _lmb_alloc_addr.lto_priv 92 - -92 _lmb_alloc_base.lto_priv 280 - -280 Total: Before=2492722, After=2492744, chg +0.00% [0] https://lore.kernel.org/u-boot/20241208105223.2821049-1-ilias.apalodimas@li… Changes since v1: - Rebased on top of https://lore.kernel.org/u-boot/20241211021703.2333-1-semen.protsenko@linaro… https://lore.kernel.org/u-boot/20241211022550.2995-1-semen.protsenko@linaro… - Converted enum lmb_flags to a u32 - Removed the _flags from all the functions - Added a patch that removes lmb_align_down() - Picked up r-b tags. Tom I kept your on patch #3 since I only changed the name of the function and assumed you are ok with it. Ilias Apalodimas (8): lmb: Remove lmb_align_down() lmb: Move enum lmb_flags to a u32 lmb: Remove lmb_reserve_flags() lmb: Rename free_mem to available_mem lmb: Remove lmb_add_region() lmb: Remove lmb_alloc_addr_flags() lmb: Remove lmb_alloc_base_flags() lmb: Rename _lmb_alloc_addr() to lmb_alloc_addr_flags() arch/powerpc/cpu/mpc85xx/mp.c | 2 +- arch/powerpc/lib/misc.c | 2 +- boot/bootm.c | 3 +- boot/image-board.c | 20 +++-- boot/image-fdt.c | 15 ++-- cmd/booti.c | 2 +- cmd/bootz.c | 2 +- cmd/load.c | 2 +- fs/fs.c | 2 +- include/lmb.h | 58 ++++++--------- lib/efi_loader/efi_memory.c | 6 +- lib/lmb.c | 136 +++++++++++----------------------- test/cmd/bdinfo.c | 4 +- test/lib/lmb.c | 92 +++++++++++------------ 14 files changed, 145 insertions(+), 201 deletions(-) -- 2.45.2

2 21

[PATCH] mmc: Fix potential timer value truncation
by Ronald Wahl 13 Dec '24

13 Dec '24

From: Ronald Wahl <ronald.wahl(a)legrand.com> On 64bit systems the timer value might be truncated to a 32bit value causing malfunctions. For example on ARM the timer might start from 0 again only after a cold reset. The 32bit overflow occurs after a bit more than 49 days (1000 Hz counter) so booting after that time may lead to a surprise because the board might become stuck requiring a cold reset. Signed-off-by: Ronald Wahl <ronald.wahl(a)legrand.com> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: Jaehoon Chung <jh80.chung(a)samsung.com> --- drivers/mmc/mmc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index efe98354a0..799586891a 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -750,7 +750,7 @@ static int mmc_send_op_cond(struct mmc *mmc) { int err, i; int timeout = 1000; - uint start; + ulong start; /* Some cards seem to need this */ mmc_go_idle(mmc); @@ -844,7 +844,8 @@ int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd) static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value, bool send_status) { - unsigned int status, start; + ulong start; + unsigned int status; struct mmc_cmd cmd; int timeout_ms = DEFAULT_CMD6_TIMEOUT_MS; bool is_part_switch = (set == EXT_CSD_CMD_SET_NORMAL) && -- 2.47.1

2 1

[PATCH] clk: Propagate clk_set_rate() if CLK_SET_PARENT_RATE present
by Sam Protsenko 13 Dec '24

13 Dec '24

Sometimes clocks provided to a consumer might not have .set_rate operation (like gate or mux clocks), but have CLK_SET_PARENT_RATE flag set. In that case it's usually possible to find a parent up the tree which is capable of setting the rate (div, pll, etc). Implement a simple lookup procedure for such cases, to traverse the clock tree until .set_rate capable parent is found, and use that parent to actually change the rate. The search will stop once the first .set_rate capable clock is found, which is usually enough to handle most cases. Signed-off-by: Sam Protsenko <semen.protsenko(a)linaro.org> --- drivers/clk/clk-uclass.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index ed6e60bc4841..755f05f34669 100644 --- a/drivers/clk/clk-uclass.c +++ b/drivers/clk/clk-uclass.c @@ -571,8 +571,20 @@ ulong clk_set_rate(struct clk *clk, ulong rate) return 0; ops = clk_dev_ops(clk->dev); - if (!ops->set_rate) - return -ENOSYS; + /* Try to find parents which can set rate */ + while (!ops->set_rate) { + struct clk *parent; + + if (!(clk->flags & CLK_SET_RATE_PARENT)) + return -ENOSYS; + + parent = clk_get_parent(clk); + if (IS_ERR_OR_NULL(parent) || !clk_valid(parent)) + return -ENODEV; + + clk = parent; + ops = clk_dev_ops(clk->dev); + } /* get private clock struct used for cache */ clk_get_priv(clk, &clkp); -- 2.39.2

5 16

[PULL] u-boot-usb/master
by Marek Vasut 12 Dec '24

12 Dec '24

The following changes since commit b841e559cd26ffcb20f22e8ee75debed9616c002: Prepare v2025.01-rc4 (2024-12-09 16:09:28 -0600) are available in the Git repository at: git://source.denx.de/u-boot-usb.git master for you to fetch changes up to 0e24474cc323a9012bf1f0942f46d1053e326b3f: usb: onboard-hub: Update the bind function based on peer-hub property (2024-12-11 08:22:17 +0100) ---------------------------------------------------------------- Venkatesh Yadav Abbarapu (1): usb: onboard-hub: Update the bind function based on peer-hub property common/usb_onboard_hub.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)

2 1

[GIT PULL] xilinx: Fix for v2025.01-rc5
by Michal Simek 12 Dec '24

12 Dec '24

Hi Tom, please pull this one patch to your tree. It is fixing issue on Kria SOM when SPL flow is used. Display port driver is touching IP registers but none is getting IP out of reset. That's why adding support for reset fixing it. And the commit 1a48b0be93d48f9ec5498297ec775fb572d3d150 "lmb: prohibit allocations above ram_top even from same bank" introduced regression on SOM ERROR: reserving fdt memory region failed (addr=7ff00000 size=100000 flags=2) but this series is fixing it. https://lore.kernel.org/all/20241211021703.2333-1-semen.protsenko@linaro.or… That's why would be good to get it to v2025.01 release. Thanks, Michal The following changes since commit b841e559cd26ffcb20f22e8ee75debed9616c002: Prepare v2025.01-rc4 (2024-12-09 16:09:28 -0600) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2025.01-rc5 for you to fetch changes up to 8b81010a2fe385524b58bea9116f1b6954c3d2bd: video: zynqmp: Add support for reset (2024-12-11 12:40:13 +0100) ---------------------------------------------------------------- AMD/Xilinx changes for v2025.01-rc5 - Fix reset issue for SOM ---------------------------------------------------------------- Michal Simek (1): video: zynqmp: Add support for reset drivers/video/zynqmp/zynqmp_dpsub.c | 6 ++++++ 1 file changed, 6 insertions(+)

2 1

[PATCH v2 0/2] lmb: Fix reserving the same region multiple times
by Sam Protsenko 12 Dec '24

12 Dec '24

This series is intended to be picked up for the v2025.01 release. Since commit 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE") the lmb_add_region_flags() returns -1 when the caller tries to add the already existing region with !LMB_NONE flags (it was returning 0 before that patch). That causes boot_fdt_reserve_region() function to print erroneous error messages when it's called consequently more than one time. Make lmb_add_region_flags() return -EEXIST when the already added region with !LMB_NONE flags is being added, and then check that error code in boot_fdt_reserve_region() to avoid printing the misleading error messages. This series fixes all 3 found cases (discussed at [1]) for the false positive error messages. All unit tests pass in sandbox U-Boot. Changes in v2: - Split the original series by two separate series (cleanups will be sent out as a different one) - Collected all R-b and A-b tags from review - Patch #1: Removed the check for exactly the same region, and return -EEXIST in the branch handling overlapping regions instead - Reworded the commit messages slightly [1] https://lists.denx.de/pipermail/u-boot/2024-December/574123.html Sam Protsenko (2): lmb: Return -EEXIST in lmb_add_region_flags() if region already added boot: fdt: Handle already reserved memory in boot_fdt_reserve_region() boot/image-fdt.c | 2 +- lib/lmb.c | 26 +++++++++++++------------- test/lib/lmb.c | 2 +- 3 files changed, 15 insertions(+), 15 deletions(-) -- 2.39.5

4 5

[PATCH] configs: am62x_evm_*: Fix USB DFU configuration
by Roger Quadros 12 Dec '24

12 Dec '24

CONFIG_USB_XHCI_DWC3 is not required for AM62x as the XHCI driver is registered through the dwc3-generic driver. CONFIG_USB_XHCI_DWC3 causes problems by hijacking the USB controller even if it is not set for Host mode in device tree. 'dm tree' output after 'usb start' is fixed from simple_bus 5 [ + ] dwc3-am62 | |-- dwc3-usb@f900000 usb_gadget 0 [ ] dwc3-generic-periphe | | |-- usb@31000000 usb 0 [ + ] xhci-dwc3 | | `-- usb@31000000 usb_hub 0 [ + ] usb_hub | | `-- usb_hub simple_bus 6 [ + ] dwc3-am62 | |-- dwc3-usb@f910000 usb 1 [ + ] dwc3-generic-host | | |-- usb@31100000 usb_hub 1 [ + ] usb_hub | | | `-- usb_hub usb 1 [ + ] xhci-dwc3 | | `-- usb@31100000 usb_hub 2 [ + ] usb_hub | | `-- usb_hub [notice that 'xhci-dwc3' and 'usb_hub' drivers are probed for both USB instances although the first instance is supposed to be 'peripheral' only] to simple_bus 5 [ ] dwc3-am62 | |-- dwc3-usb@f900000 usb_gadget 0 [ ] dwc3-generic-periphe | | `-- usb@31000000 simple_bus 6 [ + ] dwc3-am62 | |-- dwc3-usb@f910000 usb 1 [ + ] dwc3-generic-host | | `-- usb@31100000 usb_hub 0 [ + ] usb_hub | | `-- usb_hub Fixes: dfc2dff5a844 ("configs: am62x_evm_*: Enable USB and DFU support") Signed-off-by: Roger Quadros <rogerq(a)kernel.org> --- configs/am62x_a53_usbdfu.config | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/am62x_a53_usbdfu.config b/configs/am62x_a53_usbdfu.config index 3a19cf23287..0d3c6df1e73 100644 --- a/configs/am62x_a53_usbdfu.config +++ b/configs/am62x_a53_usbdfu.config @@ -16,7 +16,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_SPL_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y CONFIG_SPL_USB_DWC3_GENERIC=y --- base-commit: 3073246d1be682071d8b3d07d06c2484907aed60 change-id: 20241203-am62-usb-xhci-be62bc9584c9 Best regards, -- Roger Quadros <rogerq(a)kernel.org>

3 8

[PATCH] video: zynqmp: Add support for reset
by Michal Simek 12 Dec '24

12 Dec '24

In Kria SOM configuration DP is under reset and access to DP is causing hang that's why call reset at probe to avoid this situation. Signed-off-by: Michal Simek <michal.simek(a)amd.com> --- drivers/video/zynqmp/zynqmp_dpsub.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/video/zynqmp/zynqmp_dpsub.c b/drivers/video/zynqmp/zynqmp_dpsub.c index 76abfeac4433..52af23c3c835 100644 --- a/drivers/video/zynqmp/zynqmp_dpsub.c +++ b/drivers/video/zynqmp/zynqmp_dpsub.c @@ -11,6 +11,7 @@ #include <dm.h> #include <errno.h> #include <generic-phy.h> +#include <reset.h> #include <stdlib.h> #include <video.h> #include <wait_bit.h> @@ -2093,10 +2094,15 @@ static int zynqmp_dpsub_probe(struct udevice *dev) { struct video_priv *uc_priv = dev_get_uclass_priv(dev); struct zynqmp_dpsub_priv *priv = dev_get_priv(dev); + struct reset_ctl_bulk resets; struct clk clk; int ret; int mode = RGBA8888; + ret = reset_get_bulk(dev, &resets); + if (!ret) + reset_deassert_bulk(&resets); + ret = clk_get_by_name(dev, "dp_apb_clk", &clk); if (ret < 0) { dev_err(dev, "failed to get clock\n"); -- 2.43.0

1 1

[PATCH v4 0/8] Inline ECC Series
by Santhosh Kumar K 12 Dec '24

12 Dec '24

Hello, This series is to: Add support for Inline ECC in DDR for AM64X, AM62X, AM62AX, AM62PX, J721S2 and J784S4 devices. (1/8) Enable ECC priming with BIST engine (2/8) Add a function to store base address and size of RAM's banks in a 64-bit device private data (3/8) Setup the ECC region start and range (4/8) Enable ECC 1-bit error, 2-bit error and multiple-bit error interrupts (5/8) Add CONFIG_K3_INLINE_ECC (6/8) Set NR_DRAM_BANKS to 2 (7/8) Pull Redundant DDR functions to a common location and Fixup DDR size when ECC is enabled (8/8) Add ss_cfg reg entry Changes since v3: Pull redundant DDR functions to arch/arm/mach-k3/* v3: https://lore.kernel.org/all/20240523050430.455201-1-s-k6@ti.com/ Changes since v2: Removed 'default n' in Kconfig as that is default setting v2: https://lore.kernel.org/u-boot/20240510084707.1903133-1-s-k6@ti.com/ Changes since v1: Add support for J7* devices. v1: https://lore.kernel.org/u-boot/20240131060213.1128024-1-s-k6@ti.com/ Test Results: https://gist.github.com/santhosh21/25937355aa2c134a64fa76480ac6a4a2 Thanks and Regards, Santhosh. Georgi Vlaev (1): ram: k3-ddrss: Use the DDR controller BIST engine for ECC priming Neha Malcom Francis (2): drivers: ram: Kconfig: Add CONFIG_K3_INLINE_ECC configs: j7*_evm_r5_defconfig: Set NR_DRAM_BANKS to 2 Santhosh Kumar K (5): ram: k3-ddrss: Add k3_ddrss_ddr_bank_base_size_calc() to solve 'calculations restricted to 32 bits' issue ram: k3-ddrss: Setup ECC region start and range ram: k3-ddrss: Enable ECC interrupts board: ti: Pull redundant DDR functions to a common location and Fixup DDR size when ECC is enabled arm: dts: k3-*-ddr: Add ss_cfg reg entry arch/arm/dts/k3-am62a-ddr.dtsi | 7 +- arch/arm/dts/k3-j721s2-ddr.dtsi | 12 +- arch/arm/dts/k3-j784s4-ddr.dtsi | 24 ++- arch/arm/mach-k3/Makefile | 2 +- arch/arm/mach-k3/include/mach/k3-ddr.h | 15 ++ arch/arm/mach-k3/k3-ddr.c | 88 ++++++++++ board/ti/am62ax/evm.c | 17 +- board/ti/am62px/evm.c | 17 +- board/ti/am62x/evm.c | 62 +------ board/ti/am64x/evm.c | 73 +-------- board/ti/am65x/evm.c | 29 +--- board/ti/j721e/evm.c | 29 +--- board/ti/j721s2/evm.c | 35 ++-- board/ti/j784s4/evm.c | 17 +- configs/j7200_evm_r5_defconfig | 1 + configs/j721e_evm_r5_defconfig | 1 + configs/j721s2_evm_r5_defconfig | 1 + configs/j784s4_evm_r5_defconfig | 1 + drivers/ram/Kconfig | 10 ++ drivers/ram/k3-ddrss/k3-ddrss.c | 214 +++++++++++++++++++++---- 20 files changed, 387 insertions(+), 268 deletions(-) create mode 100644 arch/arm/mach-k3/include/mach/k3-ddr.h create mode 100644 arch/arm/mach-k3/k3-ddr.c -- 2.34.1

5 26

Using EFI variables in boot scr
by Patryk 12 Dec '24

12 Dec '24

Hi, Suppose I would like to utilize the possibility of combining the OPTEE, EKD2 StandaloneMM, and U-BOOT efivars and RPMB drivers to store my env variables securely in RPMB of eMMC device. However I would still like to be able to use the boot script to call the bootm command to boot my non-uefi kernel image stored in fitImage. One of the efi variables could e.g. act as a rootfs selection (would be used as a value for root= passed as a kernel cmdline in A/B scenario) or could e.g indicate which configuration from fit image should be used. In other words - I would like to use the efi variables and the fact that they are stored on RPMB but not use the rest of UEFI implementation in u-boot. The problem is that, apparently there is no easy way to get the value of efi variable from boot script other than printing it and somehow parsing (I'm not sure if this is even possible without some nasty workarounds). Does it even make sense? If not, then I would be grateful for even a short explanation why, and perhaps showing an alternative way. Best regards Patryk

1 0