July 2024 - U-Boot

[PATCH 0/4] U-Boot support for the Rock 5 ITX
by Heiko Stuebner 02 Aug '24

02 Aug '24

Support for the Rock 5 ITX is now part of 6.11-rc1, so add support for it in u-boot as well. The naming follows Dragan's suggestion in the mainline submission: "the name of this board deviates from the standard Radxa naming scheme, which is something like "ROCK <number><letter>" thus, "rock-5a" is fine, but it should be "rock-5-itx", simply because there's a space between "5" and "ITX" in "ROCK 5 ITX" Not sure if the u-boot side wants less dashes, but we'll see :-) U-Boot master + this series can detect all mass storage devices (emmc, sd, nvme) and also both PCIe connected network controllers Alexey Charkov (1): arm64: dts: rockchip: add thermal zones information on RK3588 Dragan Simic (1): arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs Heiko Stuebner (2): arm64: dts: rockchip: add ROCK 5 ITX board board: rockchip: Add Radxa ROCK 5 ITX arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi | 18 + arch/arm/mach-rockchip/rk3588/Kconfig | 29 + board/radxa/rock-5-itx-rk3588/Kconfig | 12 + board/radxa/rock-5-itx-rk3588/MAINTAINERS | 7 + configs/rock-5-itx-rk3588_defconfig | 104 + ...-pinctrl.dtsi => rk3588-base-pinctrl.dtsi} | 0 .../{rk3588s.dtsi => rk3588-base.dtsi} | 155 +- ...pinctrl.dtsi => rk3588-extra-pinctrl.dtsi} | 0 .../{rk3588.dtsi => rk3588-extra.dtsi} | 4 +- .../src/arm64/rockchip/rk3588-rock-5-itx.dts | 1177 ++++++++ dts/upstream/src/arm64/rockchip/rk3588.dtsi | 420 +-- dts/upstream/src/arm64/rockchip/rk3588j.dtsi | 2 +- dts/upstream/src/arm64/rockchip/rk3588s.dtsi | 2677 +---------------- include/configs/rock-5-itx-rk3588.h | 15 + 14 files changed, 1533 insertions(+), 3087 deletions(-) create mode 100644 arch/arm/dts/rk3588-rock-5-itx-u-boot.dtsi create mode 100644 board/radxa/rock-5-itx-rk3588/Kconfig create mode 100644 board/radxa/rock-5-itx-rk3588/MAINTAINERS create mode 100644 configs/rock-5-itx-rk3588_defconfig rename dts/upstream/src/arm64/rockchip/{rk3588s-pinctrl.dtsi => rk3588-base-pinctrl.dtsi} (100%) copy dts/upstream/src/arm64/rockchip/{rk3588s.dtsi => rk3588-base.dtsi} (95%) rename dts/upstream/src/arm64/rockchip/{rk3588-pinctrl.dtsi => rk3588-extra-pinctrl.dtsi} (100%) copy dts/upstream/src/arm64/rockchip/{rk3588.dtsi => rk3588-extra.dtsi} (99%) create mode 100644 dts/upstream/src/arm64/rockchip/rk3588-rock-5-itx.dts rewrite dts/upstream/src/arm64/rockchip/rk3588.dtsi (99%) rewrite dts/upstream/src/arm64/rockchip/rk3588s.dtsi (99%) create mode 100644 include/configs/rock-5-itx-rk3588.h -- 2.39.2

4 10

[PATCH 0/2] board: rockchip: Add Radxa ROCK S0
by Jonas Karlman 02 Aug '24

02 Aug '24

This series add support for the RK3308 based Radxa ROCK S0 board. Features tested on a ROCK S0 v1.2 with 512 MiB RAM and 8 GiB eMMC: - SD-card boot - eMMC boot - Ethernet - USB gadget - USB host This series depends on the following patch: - arm64: dts: rockchip: Add rk3308 IO voltage domains [1] [1] https://patchwork.ozlabs.org/patch/1966593/ Jonas Karlman (2): arm64: dts: rockchip: Add Radxa ROCK S0 board: rockchip: Add Radxa ROCK S0 arch/arm/dts/rk3308-rock-s0-u-boot.dtsi | 21 ++ board/rockchip/evb_rk3308/MAINTAINERS | 6 + configs/rock-s0-rk3308_defconfig | 72 +++++ doc/board/rockchip/rockchip.rst | 1 + .../src/arm64/rockchip/rk3308-rock-s0.dts | 293 ++++++++++++++++++ 5 files changed, 393 insertions(+) create mode 100644 arch/arm/dts/rk3308-rock-s0-u-boot.dtsi create mode 100644 configs/rock-s0-rk3308_defconfig create mode 100644 dts/upstream/src/arm64/rockchip/rk3308-rock-s0.dts -- 2.45.2

2 4

[PATCH] mmc: rockchip_dw_mmc: Allow 4-bit mode when 8-bit mode is supported
by Jonas Karlman 02 Aug '24

02 Aug '24

Hosts capable of 8-bit can also do 4 bits, fix use of 4-bit mode when 8-bit mode is supported. This fixes use of 1-bit mode with SD NAND on ROCK Pi S using the DT in v6.11-rc1 that chage to use 8-bit bus to also support eMMC. With this 4-bit mode is used with SD NAND and 8-bit mode with eMMC, same as in Linux kernel. Signed-off-by: Jonas Karlman <jonas(a)kwiboo.se> --- drivers/mmc/rockchip_dw_mmc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c index 1a10b7057a47..549fb80f1988 100644 --- a/drivers/mmc/rockchip_dw_mmc.c +++ b/drivers/mmc/rockchip_dw_mmc.c @@ -159,6 +159,10 @@ static int rockchip_dwmmc_probe(struct udevice *dev) host->mmc->dev = dev; upriv->mmc = host->mmc; + /* Hosts capable of 8-bit can also do 4 bits */ + if (host->buswidth == 8) + plat->cfg.host_caps |= MMC_MODE_4BIT; + return dwmci_probe(dev); } -- 2.45.2

2 1

[PATCHv3 00/14] Add a subcommand 'release' to cmd/cpu.c
by Zhiqiang Hou 02 Aug '24

02 Aug '24

From: Hou Zhiqiang <Zhiqiang.Hou(a)nxp.com> This patch set is to add a subcommand 'release' to the 'cpu' command in cmd/cpu.c, making the command is able to release a core to run baremetal and RTOS applications. Fixed some problems of the imx8_cpu.c and added i.MX 8M series SoCs support. Added ARM A53 core clock registration in clock driver of i.MX 8M Mini, Nano and Plus SoCs. And enabled the 'cpu' command and imx CPU driver for i.MX 8M series EVK boards and i.MX 93 EVK board. Hou Zhiqiang (14): clk: imx8m: register ARM A53 core clock cpu: add release_core callback cpu: sandbox: implement release_core callback test: cpu: add test for release CPU core. cpu: imx: fix the CPU frequency in cpu_imx_get_info() cpu: imx: fix the CPU type field width cpu: imx: removed the tail '\n' of the CPU description cpu: imx: Add i.MX 8M series SoCs cpu: imx: implement release_core callback cmd: cpu: add release subcommand doc: cmd: add documentation for cpu command MAINTAINERS: add entry for cpu command configs: imx8m: enable the 'cpu' command configs: imx93: enable the 'cpu' command --- V4: - Moved the depended patch into this thread. - Removed the tail '\n' of the CPU description for imx CPU driver. - Refined the documentation of 'cpu' command. V3: - Added documentation for 'cpu' command. - Fixed the getting cpu frequency issue in i.MX CPU driver. V2: - Implemented release_core() in sandbox and added test for the new API. - Increased the CPU type mask in i.MX CPU driver. - Added i.MX 8M series SoCs in i.MX CPU driver MAINTAINERS | 7 +++ cmd/cpu.c | 44 ++++++++++++- configs/imx8mm_evk_defconfig | 3 + configs/imx8mn_evk_defconfig | 3 + configs/imx8mp_evk_defconfig | 3 + configs/imx93_11x11_evk_defconfig | 1 + doc/usage/cmd/cpu.rst | 101 ++++++++++++++++++++++++++++++ drivers/clk/imx/clk-imx8mm.c | 6 ++ drivers/clk/imx/clk-imx8mn.c | 7 +++ drivers/clk/imx/clk-imx8mp.c | 7 +++ drivers/cpu/cpu-uclass.c | 10 +++ drivers/cpu/cpu_sandbox.c | 6 ++ drivers/cpu/imx8_cpu.c | 38 +++++++++-- include/cpu.h | 15 +++++ test/dm/cpu.c | 2 + 15 files changed, 246 insertions(+), 7 deletions(-) create mode 100644 doc/usage/cmd/cpu.rst -- 2.17.1

5 26

[PATCH] clk: clk-uclass: Print clk name in clk_enable/clk_disable
by Michael Trimarchi 02 Aug '24

02 Aug '24

Print clk name in clk_enable and clk_disable. Make sense to know what clock get disabled/enabled before a system crash or system hang. Signed-off-by: Michael Trimarchi <michael(a)amarulasolutions.com> --- drivers/clk/clk-uclass.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index d768e5ad2e..76f1026164 100644 --- a/drivers/clk/clk-uclass.c +++ b/drivers/clk/clk-uclass.c @@ -630,7 +630,7 @@ int clk_enable(struct clk *clk) struct clk *clkp = NULL; int ret; - debug("%s(clk=%p)\n", __func__, clk); + debug("%s(clk=%p name=%s)\n", __func__, clk, clk->dev->name); if (!clk_valid(clk)) return 0; ops = clk_dev_ops(clk->dev); @@ -691,7 +691,7 @@ int clk_disable(struct clk *clk) struct clk *clkp = NULL; int ret; - debug("%s(clk=%p)\n", __func__, clk); + debug("%s(clk=%p name=%s)\n", __func__, clk, clk->dev->name); if (!clk_valid(clk)) return 0; ops = clk_dev_ops(clk->dev); -- 2.43.0

2 1

[PATCH v2] clk: Revise help text for clk_get_parent_rate()
by Alexander Dahl 02 Aug '24

02 Aug '24

The function returns the rate of the parent clock, the previous text made no sense at all. Fixes: 4aa78300a025 ("dm: clk: Define clk_get_parent_rate() for clk operations") Signed-off-by: Alexander Dahl <ada(a)thorsis.com> Reviewed-by: Sean Anderson <seanga2(a)gmail.com> --- Notes: v2: - Collected tags include/clk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/clk.h b/include/clk.h index af23e4f3475..045e923a529 100644 --- a/include/clk.h +++ b/include/clk.h @@ -444,7 +444,7 @@ ulong clk_get_rate(struct clk *clk); struct clk *clk_get_parent(struct clk *clk); /** - * clk_get_parent_rate() - Get parent of current clock rate. + * clk_get_parent_rate() - Get rate of current clock's parent. * @clk: A clock struct that was previously successfully requested by * clk_request/get_by_*(). * base-commit: c92d48f8b2909d08584f17612a23d959467f14b8 -- 2.39.2

2 1

[PATCH] clk: Fix error message in clk_get_bulk
by Jan Kiszka 02 Aug '24

02 Aug '24

From: Jan Kiszka <jan.kiszka(a)siemens.com> Fix a logical inversion of the printed text. Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> --- drivers/clk/clk-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index ed6e60bc484..78d8ea94c65 100644 --- a/drivers/clk/clk-uclass.c +++ b/drivers/clk/clk-uclass.c @@ -180,7 +180,7 @@ int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk) bulk_get_err: err = clk_release_all(bulk->clks, bulk->count); if (err) - debug("%s: could release all clocks for %p\n", + debug("%s: could not release all clocks for %p\n", __func__, dev); return ret; -- 2.35.3

4 3

[PATCH 00/12] clk: mediatek: add OPs to support OF_UPSTREAM
by Christian Marangi 02 Aug '24

02 Aug '24

This series doesn't currently change anything and it does add all the additional OPs to make support of OF_UPSTREAM. While converting the mt7681/7686/7688/7623/7622 it was notice lots of discrepancy between the downstream dtsi and the upstream one and the clock ID between downstream clock ID and upstream clock ID. Upstream reference clock by names and clock are handled by the CCF (Common Clock Framework). The same can't be used here as we would quickly reach the max space allocated before relocation. The current mediatek clock driver reference all the parents and clocks with offset from the clk ID related to the different tables. Discrepancy between clock ID and the order in the clocks table cause one clock referenced for another or even crash for trying to access a clock at an offset that doesn't exist. To handle this and permit use of OF_UPSTREAM, various measure and changes are done to the mediatek clock driver to support it. This series have all the generic clock changes. Once this is merged, series for each SoC will came that will just change files in their dedicated clock driver. This is to prevent massive patch and to permit to split series, one for each SoC. As said at the start, these changes doesn't cause regression and are just expansion to the current API. Current behaviour is saved in every possible way (aside from the first 2 patch that fixes latent bugs) World compile tested in Azure Pipeline test Christian Marangi (12): clk: mediatek: return XTAL rate directly for gates with XTAL parent clk: mediatek: return XTAL rate for infrasys get_mux_rate clk: mediatek: add support for gates in clk_tree for infrasys clk: mediatek: add support for gate ID at offset clk: mediatek: add support for parent mux from different source clk: mediatek: add support for parent mux from different source for topckgen clk: mediatek: add support for gate clock to reference topckgen clock clk: mediatek: provide common clk init function for infrasys clk: mediatek: add support for remapping clock ID clk: mediatek: implement MUX_FLAGS and MUX_MIXED_FLAGS macro clk: mediatek: add support for GATEs for APMIXED OPs clk: mediatek: add support for APMIXED parent in infra MUX drivers/clk/mediatek/clk-mtk.c | 433 ++++++++++++++++++++++++--------- drivers/clk/mediatek/clk-mtk.h | 74 +++++- 2 files changed, 392 insertions(+), 115 deletions(-) -- 2.45.1

2 14

[RFC PATCH 0/4] dm: Duplicate uclass name fix and alias improvements
by Zixun LI 01 Aug '24

01 Aug '24

Patch 1 is a tentative fix for duplicate uclass name issue met in https://lists.denx.de/pipermail/u-boot/2024-July/560189.html The idea is to use orignal class name only for sequence alias to keep this alias function working and rename the class something else. Patch 2 and 3 make "dm tree", "bind" and "unbind" commands to take care of alias sequence numbering. As the alias sequence numbering is more meanful than uclass index. Patch 4 is the actual fix for usb gadet class. There are some situations where uclass index and device sequence number are misused which is not convered by this patch set, for example in drivers/net/sandbox.c, uclass_get_device() is used which is based on uclass index, while in the comments it says "index - The alias index (also DM seq number)" Zixun LI (4): dm: core: Add a way to specify an alt name for alias sequence numbering dm: core: Show device sequence instead in dm_dump_tree() cmd: bind: Use device sequence instead for driver bind/unbind usb: gadget: udc: Fix duplicate uclass name cmd/bind.c | 4 ++-- drivers/core/device.c | 3 ++- drivers/core/dump.c | 2 +- drivers/core/read.c | 7 ++++++- drivers/core/uclass.c | 11 +++++++++-- drivers/usb/gadget/udc/udc-uclass.c | 3 ++- include/dm/read.h | 9 ++++++++- include/dm/uclass.h | 2 ++ 8 files changed, 32 insertions(+), 9 deletions(-) -- 2.45.2

2 9

Vulnerability in LZMA implementation
by Darek 01 Aug '24

01 Aug '24

Hello! I hope this is all the correct contacts for reporting this issue. I have discovered that there is a vulnerability in the version of 7z LZMA that U-Boot is using (9.20). I've found this to lead to code execution when used with `lzmadec`. I have found no issued CVEs or public disclosures announcing this vulnerability, but it appears to have been patched in 7z LZMA version 21.02 alpha. I've patched locally with 24.07 and U-Boot appeared to LZMA decompress successfully, but I'm unaware of other use cases within the project. I would also be curious if another LZMA implementation would be considered. I'm separately coordinating disclosure with the 7z maintainers and planning on requesting a CVE. Since your project uses an older version that is unlikely to get a backported patch, and the issue is already fixed in newer versions, I am disclosing this to U-Boot maintainers at the same time. The bug triggers when an LZMA has the 8-byte length field in the header set to 0. This field is located at offset 5 from the start of an LZMA file. Due to how the logic of `LzmaDec_DecodeToDic()` works, this eventually reaches a `memcpy(p->tempBuf, src, inSize)` on this line - https://github.com/u-boot/u-boot/blob/8877bc51a8a4d921ba2f163208b8b1a57ba47… The `inSize` value here is allowed to be greater than the buffer size due to the previous if-statement ignoring this value if `checkEndMarkNow` is set. The return value from `LzmaDec_TryDummy()` also needs to return `DUMMY_ERROR` to reach the `memcpy()`. The value of `dicLimit` in this function is initially the value read from the LZMA header, which for this case is 0. Under my testing, when this was 0, it hits the memcpy call, using the passed `srcLen` value (`inSize`). Within `lmzadec`, this value is originally set to max size_t as the default here - https://github.com/u-boot/u-boot/blob/8877bc51a8a4d921ba2f163208b8b1a57ba47… And passed to the `LzmaDecode()` function here - https://github.com/u-boot/u-boot/blob/8877bc51a8a4d921ba2f163208b8b1a57ba47… Under my testing, when `lzmadec` is passed an LZMA file with a 0-length field, this ends up calling: ``` memcpy(p->tempBuf, src, 0xFFFFFFFFFFFFFFF5) ``` This is no longer max size_t due to previous subtractions in this loop and within a previous function: https://github.com/u-boot/u-boot/blob/8877bc51a8a4d921ba2f163208b8b1a57ba47… and https://github.com/u-boot/u-boot/blob/8877bc51a8a4d921ba2f163208b8b1a57ba47… This leads to code execution when the corrupted LZMA file is large enough to overwrite `memcpy()`'s instructions, or if the memory past the LZMA file is also controlled previously. In my testing, I created a small LZMA file and modified the header's size to 0. I then appended assembly instructions that performed a loop to this file, so that when code execution would occur, I could easily verify by seeing the loop. I repeated this until the file was over 1GB. In U-Boot CLI, I then used TFTP to load the LZMA file from my server and then ran `lzmadec`with my selected source and destination address far away from U-Boot's code. When I attached a debugger at this point, the program was stuck in my infinite loop code. I believe this is especially a concern for secure boot implementations that utilize U-Boot's LZMA decompression, as it could bypass their secure boot implementation. Please let me know if any additional details are needed or if a proof-of-concept video/script would be required for further evidence. Thank you, Darek

1 1