June 2024 - U-Boot

[PATCH v3 0/8] Inline ECC Series
by Santhosh Kumar K 07 Jun '24

07 Jun '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 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/53c6f285640c4b6dfb3420d84975d12a This series contains changes that grab the memory node from the DTS to set/modify DRAM bank sizes. A kernel patch has been sent [1] setting the required nodes to be available at bootloader stage. This patch series can be merged only after the DTS changes have been reflected in U-Boot either via OF_UPSTREAM (for devices that have moved to it) or via a sync to U-Boot patch. [1] https://lore.kernel.org/all/20240506110203.3230255-1-n-francis@ti.com/ 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 ++-- board/ti/am62ax/evm.c | 17 +-- board/ti/am62px/evm.c | 18 +-- board/ti/am62x/evm.c | 63 ++-------- board/ti/am64x/evm.c | 73 ++--------- board/ti/am65x/evm.c | 29 +---- board/ti/common/Makefile | 1 + board/ti/common/k3-ddr-init.c | 89 +++++++++++++ board/ti/common/k3-ddr-init.h | 15 +++ 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, 390 insertions(+), 267 deletions(-) create mode 100644 board/ti/common/k3-ddr-init.c create mode 100644 board/ti/common/k3-ddr-init.h -- 2.34.1

2 10

Re: Possible license violation
by pm88hpxmdxke＠disengage.co 07 Jun '24

07 Jun '24

I think this is huge misunderstanding.They just don’t want users to brick devices:After agent reply, no complaintshttps://forum.gl-inet.com/t/uboot-for-gl-mt3000-beryl-ax/41760/13… company, sorry for fuss> HiI am copying this message to you and GL team.Regarding license violation:U-boot’s license requires Gl.iNet to provide the source-code for U-boot (including any modifications they made) to anybody that asks for it. So…GL team refused to send source code nor .bin file. I wanted to inspect it for possible backdoors but still they are refusing.“ If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.”https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htmlhttps://g… I am sending this message to you to check this situation. They probably will not send it to you.Also please use web mail (not business domain) as they can sent it to you through it to hide the fact of licensing violation. For example send request from Gmail. Please take measures. It is certainly very disappointing to hear GL.iNET is not following the clear license terms of software they are using. -- Tom

2 1

[GIT PULL] Please pull u-boot-dfu-20240606
by Mattijs Korpershoek 07 Jun '24

07 Jun '24

Hi Tom, Please find some fixes for master: - dwc3 fix crash when ep0 stalls or gadget is stopped - Kconfig build fix for DFU_SF (SPI flash DFU driver) The CI job is at https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/20990 Thanks, Mattijs The following changes since commit c0ea27bccfb7d2d37fd36806ac2a2f7389099420: Prepare v2024.07-rc4 (2024-06-03 18:34:59 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-dfu.git tags/u-boot-dfu-20240606 for you to fetch changes up to 4339138a2086f8449b9356130cb6e97a81aa8679: dfu: add missing dependency for SPI flash DFU driver (2024-06-06 09:11:21 +0200) ---------------------------------------------------------------- u-boot-dfu-20240606 - dwc3 fix crash when ep0 stalls or gadget is stopped - Kconfig build fix for DFU_SF (SPI flash DFU driver) ---------------------------------------------------------------- Heinrich Schuchardt (1): dfu: add missing dependency for SPI flash DFU driver Neil Armstrong (1): usb: dwc3: gadget: fix crash in dwc3_gadget_giveback() drivers/dfu/Kconfig | 1 + drivers/usb/dwc3/gadget.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-)

2 1

Pull request doc-2024-07-rc5
by Heinrich Schuchardt 07 Jun '24

07 Jun '24

Dear Tom, The following changes since commit 4b992573b34b1586e323e27b177680a6efec1c76: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-usb (2024-06-05 10:59:10 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/doc-2024-07-rc5 for you to fetch changes up to 0efc5a9f670144cad7f287711f25c69cba0fde39: doc: process.rst: Document device tree resync rules (2024-06-06 09:28:20 +0200) Gitlab CI showed no issues building the documentation: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/20988 ---------------------------------------------------------------- Documentation: * Update netconsole examples mentioning stderr. * Describe what an "fpga" image is in FIT files. * process.rst: Document device tree resync rules. ---------------------------------------------------------------- Fiona Klute (2): doc: Detailed example for netconsole setup doc: Update netconsole examples, mention stderr Sam Povilus (2): doc: Remove extraneous curly braces doc: add clarity to what a "fpga" image is Tom Rini (2): doc: process.rst: Use subsubheading for "Phases of the Development Process" doc: process.rst: Document device tree resync rules doc/develop/devicetree/control.rst | 9 ++++-- doc/develop/process.rst | 21 +++++++++++--- doc/usage/fit/source_file_format.rst | 28 +++++++++--------- doc/usage/netconsole.rst | 55 +++++++++++++++++++++++++++++------- 4 files changed, 82 insertions(+), 31 deletions(-)

2 1

Possible license violation
by pm88hpxmdxke＠disengage.co 07 Jun '24

07 Jun '24

HiI am copying this message to you and GL team.Regarding license violation:U-boot’s license requires Gl.iNet to provide the source-code for U-boot (including any modifications they made) to anybody that asks for it. So…GL team refused to send source code nor .bin file. I wanted to inspect it for possible backdoors but still they are refusing.“ If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it.If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer.The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you.”https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htmlhttps://g… I am sending this message to you to check this situation. They probably will not send it to you.Also please use web mail (not business domain) as they can sent it to you through it to hide the fact of licensing violation. For example send request from Gmail. Please take measures.

2 1

Needs a check in the device tree
by jianqiang wang 06 Jun '24

06 Jun '24

Dear Das U-Boot developers, I found that the u-boot device tree implementation lacks a check for the off_dt_struct field in the device tree. In file scripts\dtc\libfdt\libfdt_internal.h, fdt_offset_ptr_ returns the dt struct address. It calculates the address by adding the header address, fdt offset, and a specified offset. However, the fdt offset is read from the device tree and lacks a proper check. The returned pointer can even point to any address, leading to arbitrary read or write. Could you please confirm it is a vulnerability? best regards Jianqiang

2 2

[RFC PATCH 0/1] drivers: bootcount: Add support for FAT filesystem
by Vasileios Amoiridis 06 Jun '24

06 Jun '24

From: Vasileios Amoiridis <vasileios.amoiridis(a)cern.ch> This patch adds support to save the bootcount variable in a file located in FAT filesystem. Up to now, there was support only for EXT filesystem. The reason I put this as RFC is because the file "bootcount_ext.c" will no longer represent the implementation for the EXT filesystem, but also for the FAT filesystem. Should it be renamed? If not, wouldn't it be inconsistent? Cheers, Vasilis P.S: Documentation has not been modified yet, I will submit in the v2 (if any). Vasileios Amoiridis (1): drivers: bootcount: Add support for FAT filesystem doc/README.bootcount | 12 ++++---- drivers/bootcount/Kconfig | 49 +++++++++++++++++++++++-------- drivers/bootcount/Makefile | 2 +- drivers/bootcount/bootcount_ext.c | 18 ++++++++---- 4 files changed, 56 insertions(+), 25 deletions(-) base-commit: c0ea27bccfb7d2d37fd36806ac2a2f7389099420 -- 2.34.1

4 6

[PATCH] doc/sphinx, test/py: Update requests module to 2.32.2
by Tom Rini 06 Jun '24

06 Jun '24

The issue described in https://github.com/psf/requests/pull/6655 has been assigned as a security issue. While unlikely to be exploited in our usage, update to the current release to fix it. Furthermore, upstream has now moved on to v2.23.2 as the release to use which has all of the issues resolved. Reported-by: GitHub dependabot Signed-off-by: Tom Rini <trini(a)konsulko.com> --- Changes in v2: - Switch from 2.23.0 to 2.23.2 to use most recent upstream. --- doc/sphinx/requirements.txt | 2 +- test/py/requirements.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 426f41e1a028..54eb70aa92c0 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -9,7 +9,7 @@ Jinja2==3.1.4 MarkupSafe==2.1.3 packaging==23.2 Pygments==2.17.2 -requests==2.31.0 +requests==2.32.2 six==1.16.0 snowballstemmer==2.2.0 Sphinx==7.2.6 diff --git a/test/py/requirements.txt b/test/py/requirements.txt index 0f67c3c61949..c1dd636931f7 100644 --- a/test/py/requirements.txt +++ b/test/py/requirements.txt @@ -20,7 +20,7 @@ pytest==6.2.5 pytest-xdist==2.5.0 python-mimeparse==1.6.0 python-subunit==1.3.0 -requests==2.31.0 +requests==2.32.2 setuptools==65.5.1 six==1.16.0 testtools==2.3.0 -- 2.34.1

1 0

[PATCH 0/3] rockchip: rk8xx: fix broken [np]ldo callbacks
by Quentin Schulz 06 Jun '24

06 Jun '24

This is for master branch, merge ASAP as it's known to break at least Chromebook Jerry. @Simon, can you please check that this fixes your CB? The wrong udevice was passed to the functions, making them call the pmic callbacks on the parent of the pmic udevice instead of the pmic udevice itself. While at it, ensure consistency by having all internal functions use pmic udevice instead of the regulator udevice. Finally, clarify operator precedence in ternary condition as reported by my linter. Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Quentin Schulz (3): regulator: rk8xx: fix incorrect device used for _ldo_[sg]et_suspend_value regulator: rk8xx: pass pmic udevice instead of regulator to all internal functions regulator: rk8xx: clarify operator precedence drivers/power/regulator/rk8xx.c | 54 ++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 27 deletions(-) --- base-commit: c0ea27bccfb7d2d37fd36806ac2a2f7389099420 change-id: 20240605-pmic-rk8xx-52f2286be334 Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

6 12

[PATCH 0/2] Cleanup fit documentation
by Sam Povilus 06 Jun '24

06 Jun '24

Sam Povilus (2): doc: Remove extraneous curly braces doc: add clarity to what a "fpga" image is doc/usage/fit/source_file_format.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) -- 2.34.1

3 5