July 2022 - U-Boot

[MVEBU] SPI flash offset was depecrated?
by Tony Dinh 02 Aug '22

02 Aug '22

Hi Stefan and Pali, Sorry the question might be a bit trivial, but I could not find it in the source tree. It's been a long time and I'm not up to date on this subject. I recall a long time ago we needed to specify a SPI flash offset for the u-boot image so SPL would know where to load it from. I vaguely remember something about "return to BootROM and let the BootROM load the u-boot image"? Is this applicable only when we kwboot the u-boot-spl.kwb image, or also applicable to the u-boot payload on SPI flash? I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README Update from original Marvell U-Boot to mainline U-Boot: ------------------------------------------------------- The resulting image including the SPL binary with the full DDR setup is "u-boot-spl.kwb". To update the SPI NOR flash, please use the following command: => sf probe; tftpboot 2000000 db-88f6820-gp/u-boot-spl.kwb;\ sf update 2000000 0 60000 ... But building this board I got 642K u-boot-spl.kwb. So perhaps the instructions above are out of date, or 60000 meant to be just an example to be adjusted to the real image size? Could you point me in the right direction, ie. which Kconfig option deals with this at the moment, or is it automatically set when we build MVEBU -boot-spl.kwb? Thanks, Tony

3 9

[PATCH v2 0/5] fs/fat: fix handling of full disk
by Heinrich Schuchardt 02 Aug '22

02 Aug '22

Currently we have two functions with redundant coding to find an empty cluster: * find_empty_cluster() seeks from the beginning of the FAT table * determine_fatent() seeks after a given entry Both do not detect the end of the FAT table correctly and return an invalid cluster number if no empty entry if found. Correctly determine empty FAT entries and full disk correctly. Carve out a function for creating directory entries to avoid code duplication. Provide a unit test checking that a full FAT16 root directory is recognized. For other file systems testing is too time consuming. FAT32 allows 65536 entries per directory. v2: Handle errors returned by fat_create_dir_entry() Add unit test Heinrich Schuchardt (5): fs: fat: finding an empty FAT cluster fs: fat: determine_fatent() error handling fs: fat: carve out fat_create_dir_entry() test: let fs_obj_mkdir() provide full file system type test: add test for full FAT16 directory fs/fat/fat_write.c | 161 ++++++++++++++-------------- test/py/tests/test_fs/conftest.py | 6 +- test/py/tests/test_fs/test_mkdir.py | 72 ++++++++----- 3 files changed, 131 insertions(+), 108 deletions(-) -- 2.36.1

2 11

[PATCH v2 0/7] Add support for cyclic function execution infrastruture
by Stefan Roese 01 Aug '22

01 Aug '22

This patchset adds the basic infrastructure to periodically execute code, e.g. all 100ms. Examples for such functions might be LED blinking etc. The functions that are hooked into this cyclic list should be small timewise as otherwise the execution of the other code that relies on a high frequent polling (e.g. UART rx char ready check) might be delayed too much. This patch also adds the Kconfig option CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time for such a cyclic function. If it's execution time exceeds this time, this cyclic function will get removed from the cyclic list. How is this cyclic functionality executed? This patchset integrates the main function responsible for calling all registered cyclic functions cyclic_run() into the common WATCHDOG_RESET macro. This guarantees that cyclic_run() is executed very often, which is necessary for the cyclic functions to get scheduled and executed at their configured periods. This cyclic infrastructure will be used by a board specific function on the NIC23 MIPS Octeon board, which needs to check periodically, if a PCIe FLR has occurred. Ideas how to continue: One idea is to rename WATCHDOG_RESET to something like SCHEDULE and move the watchdog_reset call into this cyclic infrastructure as well. Or to perhaps move the shell UART RX ready polling to a cyclic function. It's also possible to extend the "cyclic" command, to support the creation of periodically executed shell commands (for testing etc). Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=219&view=results Thanks, Stefan Aaron Williams (1): mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure Stefan Roese (6): time: Import time_after64() and friends from Linux cyclic: Add basic support for cyclic function execution infrastruture cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET cyclic: Integrate cyclic functionality at bootup in board_r/f cyclic: Add 'cyclic list' command sandbox: Add cyclic demo function MAINTAINERS | 7 + board/Marvell/octeon_nic23/board.c | 197 +++++++++++++++++++++++++++++ board/sandbox/sandbox.c | 15 +++ cmd/Kconfig | 7 + cmd/Makefile | 1 + cmd/cyclic.c | 40 ++++++ common/Kconfig | 20 +++ common/Makefile | 1 + common/board_f.c | 2 + common/board_r.c | 2 + common/cyclic.c | 112 ++++++++++++++++ configs/octeon_nic23_defconfig | 3 + configs/sandbox_defconfig | 3 + fs/cramfs/uncompress.c | 2 +- include/cyclic.h | 97 ++++++++++++++ include/time.h | 19 +++ include/watchdog.h | 23 +++- 17 files changed, 547 insertions(+), 4 deletions(-) create mode 100644 cmd/cyclic.c create mode 100644 common/cyclic.c create mode 100644 include/cyclic.h -- 2.37.1

3 16

[PATCH 0/5] arm: bcmbca: add basic support for Broadcom BCA SoCs
by William Zhang 01 Aug '22

01 Aug '22

Broadcom BCA (Broadband Carrier Access origin) chipset family includes DSL, PON and WLAN access point and gateway SoC. Now that the ARCH_BCMBCA architecture and its first SoC BCM47622 are supported in u-boot 2022.07, this patch series add the basic support for following BCA chips under ARCH_BCMBCA: BCM63178, BCM6846, BCM6878, BCM6756 and BCM63148. We expect to send additional patches for more BCMBCA SoCs in the near future. William Zhang (5): arm: bcmbca: add bcm63178 SoC support arm: bcmbca: add bcm6846 SoC support arm: bcmbca: add bcm6878 SoC support arm: bcmbca: add bcm6756 SoC support arm: bcmbca: add bcm63148 SoC support MAINTAINERS | 9 +- arch/arm/dts/Makefile | 10 ++ arch/arm/dts/bcm63148.dtsi | 103 ++++++++++++++++++++ arch/arm/dts/bcm63178.dtsi | 120 +++++++++++++++++++++++ arch/arm/dts/bcm6756.dtsi | 130 +++++++++++++++++++++++++ arch/arm/dts/bcm6846.dtsi | 103 ++++++++++++++++++++ arch/arm/dts/bcm6878.dtsi | 111 +++++++++++++++++++++ arch/arm/dts/bcm963148.dts | 30 ++++++ arch/arm/dts/bcm963178.dts | 30 ++++++ arch/arm/dts/bcm96756.dts | 30 ++++++ arch/arm/dts/bcm96846.dts | 30 ++++++ arch/arm/dts/bcm96878.dts | 30 ++++++ arch/arm/mach-bcmbca/Kconfig | 42 +++++++- arch/arm/mach-bcmbca/Makefile | 5 + arch/arm/mach-bcmbca/bcm63148/Kconfig | 17 ++++ arch/arm/mach-bcmbca/bcm63148/Makefile | 5 + arch/arm/mach-bcmbca/bcm63178/Kconfig | 17 ++++ arch/arm/mach-bcmbca/bcm63178/Makefile | 5 + arch/arm/mach-bcmbca/bcm6756/Kconfig | 17 ++++ arch/arm/mach-bcmbca/bcm6756/Makefile | 5 + arch/arm/mach-bcmbca/bcm6846/Kconfig | 17 ++++ arch/arm/mach-bcmbca/bcm6846/Makefile | 5 + arch/arm/mach-bcmbca/bcm6878/Kconfig | 17 ++++ arch/arm/mach-bcmbca/bcm6878/Makefile | 5 + board/broadcom/bcmbca/Kconfig | 35 +++++++ configs/bcm963148_defconfig | 22 +++++ configs/bcm963178_defconfig | 22 +++++ configs/bcm96756_defconfig | 22 +++++ configs/bcm96846_defconfig | 22 +++++ configs/bcm96878_defconfig | 22 +++++ include/configs/bcm963148.h | 12 +++ include/configs/bcm963178.h | 12 +++ include/configs/bcm96756.h | 12 +++ include/configs/bcm96846.h | 12 +++ include/configs/bcm96878.h | 12 +++ 35 files changed, 1095 insertions(+), 3 deletions(-) create mode 100644 arch/arm/dts/bcm63148.dtsi create mode 100644 arch/arm/dts/bcm63178.dtsi create mode 100644 arch/arm/dts/bcm6756.dtsi create mode 100644 arch/arm/dts/bcm6846.dtsi create mode 100644 arch/arm/dts/bcm6878.dtsi create mode 100644 arch/arm/dts/bcm963148.dts create mode 100644 arch/arm/dts/bcm963178.dts create mode 100644 arch/arm/dts/bcm96756.dts create mode 100644 arch/arm/dts/bcm96846.dts create mode 100644 arch/arm/dts/bcm96878.dts create mode 100644 arch/arm/mach-bcmbca/bcm63148/Kconfig create mode 100644 arch/arm/mach-bcmbca/bcm63148/Makefile create mode 100644 arch/arm/mach-bcmbca/bcm63178/Kconfig create mode 100644 arch/arm/mach-bcmbca/bcm63178/Makefile create mode 100644 arch/arm/mach-bcmbca/bcm6756/Kconfig create mode 100644 arch/arm/mach-bcmbca/bcm6756/Makefile create mode 100644 arch/arm/mach-bcmbca/bcm6846/Kconfig create mode 100644 arch/arm/mach-bcmbca/bcm6846/Makefile create mode 100644 arch/arm/mach-bcmbca/bcm6878/Kconfig create mode 100644 arch/arm/mach-bcmbca/bcm6878/Makefile create mode 100644 configs/bcm963148_defconfig create mode 100644 configs/bcm963178_defconfig create mode 100644 configs/bcm96756_defconfig create mode 100644 configs/bcm96846_defconfig create mode 100644 configs/bcm96878_defconfig create mode 100644 include/configs/bcm963148.h create mode 100644 include/configs/bcm963178.h create mode 100644 include/configs/bcm96756.h create mode 100644 include/configs/bcm96846.h create mode 100644 include/configs/bcm96878.h -- 2.37.1

2 7

[PATCH v1 0/2] cmd/fru: move FRU handling support to common region
by Jae Hyun Yoo 01 Aug '22

01 Aug '22

Hello, The FRU handling was added as a Xilinx board dependent support but it would be useful for other boards too, so this commit moves the FRU handling support to the common region so that it can be enabled by CONFIG_CMD_FRU. To provide manufacturer specific custom board info field parsing, it defines 'fru_parse_board_custom' as a weak function so that it can be replaced with the board specific implementation. In the same way, OEM Multirecord type (0xc0 - 0xff) parsing logic can be replaced with a board specific 'fru_parse_multirec' implementation. Also, this series adds 'Product Info' parsing support. Please review! Thanks, Jae Graeme Gregory (1): cmd: fru: move FRU handling support to common region Jae Hyun Yoo (1): cmd: fru: add product info area parsing support board/xilinx/Kconfig | 8 - board/xilinx/common/Makefile | 3 - board/xilinx/common/board.c | 108 +++++++- cmd/Kconfig | 8 + cmd/Makefile | 1 + {board/xilinx/common => cmd}/fru.c | 5 +- common/Makefile | 2 + {board/xilinx/common => common}/fru_ops.c | 287 ++++++++++++++++++---- {board/xilinx/common => include}/fru.h | 47 ++-- 9 files changed, 379 insertions(+), 90 deletions(-) rename {board/xilinx/common => cmd}/fru.c (95%) rename {board/xilinx/common => common}/fru_ops.c (60%) rename {board/xilinx/common => include}/fru.h (70%) -- 2.25.1

3 8

[PATCH] MAINTAINERS: Change POWERPC MPC85XX maintainer to Marek Behún
by Marek Behún 01 Aug '22

01 Aug '22

After a discussion with Tom Rini, we've agreed that I am going to take over custodianship of the MPC85XX platform, since it seems other people do not have necessary interest or time and getting things done over there takes too long. Since I am only working on one MPC85XX board, Turris 1.x, and do not have time to do thorough reviews of patches for this entire platform (other than those concerning Turris 1.x board), for other boards I will only run patches through CI and checkpatch, and then send them via PR upwards to Tom. Signed-off-by: Marek Behún <kabel(a)kernel.org> --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index cd54e6663d..3347bd4126 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1209,7 +1209,7 @@ F: arch/powerpc/cpu/mpc83xx/ F: arch/powerpc/include/asm/arch-mpc83xx/ POWERPC MPC85XX -M: Priyanka Jain <priyanka.jain(a)nxp.com> +M: Marek Behún <kabel(a)kernel.org> S: Maintained T: git https://source.denx.de/u-boot/custodians/u-boot-mpc85xx.git F: arch/powerpc/cpu/mpc85xx/ -- 2.35.1

3 3

Re: [PATCH v2] board: freescale: p1_p2_rdb_pc: Add env commands norlowerboot, norupperboot, sd2boot and defboot
by Tom Rini 01 Aug '22

01 Aug '22

[resend to the list too this time] On Sat, Jul 09, 2022 at 12:43:44AM +0200, Pali Rohár wrote: > PING???? > > I still have not received any response. What is the point? > > On Sunday 03 July 2022 14:38:36 Pali Rohár wrote: > > PING! > > > > On Thursday 23 June 2022 15:43:45 Pali Rohár wrote: > > > On Thursday 16 June 2022 17:01:50 Peng Fan (OSS) wrote: > > > > 在 2022/4/25 22:50, Pali Rohár 写道: > > > > > All *boot env commands overrides default boot source location via i2c. > > > > > After board reset without power off, BootROM then starts booting U-Boot > > > > > from this specified location instead of the default one. > > > > > > > > > > Add new env command defboot which reverts boot location to the default > > > > > value, which in most cases is configurable by HW DIP switches. > > > > > > > > > > And add new env commands norlowerboot, norupperboot, sd2boot to boot from > > > > > other locations. norlowerboot would instruct BootROM to boot from lower NOR > > > > > bank, norupperboot from upper NOR bank and sd2boot from SD card with > > > > > alternative configuration. > > > > > > > > > > Signed-off-by: Pali Rohár <pali(a)kernel.org> > > > > > > > > Not able to apply this patch. > > > > > > And what is the reason? It applies cleanly on top of next branch, which > > > is today at commit 9121478ee6f2aee381f8fe49d8997d43527d351a. Peng, this patch doesn't apply currently but also looks fairly obvious to adapt to top of tree. Please just make it apply when you pick this up, thanks. -- Tom

2 2

[PATCH 00/14] imx: kontron-sl-mx8mm: Improvements and OSM board support
by Frieder Schrempf 01 Aug '22

01 Aug '22

From: Frieder Schrempf <frieder.schrempf(a)kontron.de> This set contains several improvements for the kontron-sl-mx8mm board configuration (patches 1 to 13) and support for a new SoM (patch 14, including baseboard) that complies to the Open Standard Module (OSM) 1.0 hardware specification, size S (https://sget.org/standards/osm). Frieder Schrempf (14): imx: kontron-sl-mx8mm: Remove LVDS board type and devicetrees imx: kontron-sl-mx8mm: Add redundant environment imx: kontron-sl-mx8mm: Enable environment in MMC imx: kontron-sl-mx8mm: Migrate to use CONFIG_EXTRA_ENV_TEXT imx: kontron-sl-mx8mm: Enable bootaux command imx: kontron-sl-mx8mm: lpddr4_timing.c: Add spaces for proper alignment imx: kontron-sl-mx8mm: Remove 100mt DDR setpoint imx: kontron-sl-mx8mm: Use new LPDDR4 config parameters imx: kontron-sl-mx8mm: Prepare for other i.MX8MM SoM types imx: kontron-sl-mx8mm: Adjust board and SoM model strings imx: kontron-sl-mx8mm: Use the VSELECT signal to switch SD card IO voltage imx: kontron-sl-mx8mm: Use voltage rail names from schematic for PMIC regulator-names imx: kontron-sl-mx8mm: Simplify code in spl.c imx: kontron-sl-mx8mm: Add support for Kontron Electronics SoM SL i.MX8MM OSM-S arch/arm/dts/Makefile | 1 - .../imx8mm-kontron-n801x-s-lvds-u-boot.dtsi | 6 - arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts | 116 - .../dts/imx8mm-kontron-n801x-s-u-boot.dtsi | 7 +- arch/arm/dts/imx8mm-kontron-n801x-s.dts | 5 +- arch/arm/dts/imx8mm-kontron-n801x-som.dtsi | 30 +- .../dts/imx8mm-kontron-n802x-s-u-boot.dtsi | 6 + arch/arm/dts/imx8mm-kontron-n802x-s.dts | 376 ++++ arch/arm/dts/imx8mm-kontron-n802x-som.dtsi | 309 +++ ...tsi => imx8mm-kontron-n80xx-s-u-boot.dtsi} | 8 +- board/kontron/sl-mx8mm/MAINTAINERS | 1 + board/kontron/sl-mx8mm/lpddr4_timing.c | 1969 ++++++++--------- board/kontron/sl-mx8mm/sl-mx8mm.c | 41 + board/kontron/sl-mx8mm/sl-mx8mm.env | 7 + board/kontron/sl-mx8mm/spl.c | 85 +- configs/kontron-sl-mx8mm_defconfig | 10 +- doc/board/kontron/sl-mx8mm.rst | 7 +- include/configs/kontron-sl-mx8mm.h | 16 +- 18 files changed, 1717 insertions(+), 1283 deletions(-) delete mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s-lvds-u-boot.dtsi delete mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-s-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-s.dts create mode 100644 arch/arm/dts/imx8mm-kontron-n802x-som.dtsi rename arch/arm/dts/{imx8mm-kontron-n801x-u-boot.dtsi => imx8mm-kontron-n80xx-s-u-boot.dtsi} (88%) create mode 100644 board/kontron/sl-mx8mm/sl-mx8mm.env -- 2.37.0

4 18

[RFC PATCH 0/2] cmd/fru: move FRU handling support to common region
by Jae Hyun Yoo 01 Aug '22

01 Aug '22

Hello, The FRU handling was added as a Xilinx board dependent support but it would be useful for other boards too, so this commit moves the FRU handling support to the common region to be enabled by CONFIG_CMD_FRU. Since the Multirecord parsing logic should be implemented on each board specifically, it defines 'fru_parse_multirec' as a weak function so that the function can be replaced with the board specific implementation. Also, this series adds 'Product Info' of FRU parsing support. Please review! Thanks, Jae Graeme Gregory (1): cmd/fru: cmd/fru: move FRU handling support to common region Jae Hyun Yoo (1): cmd/fru: add product info area parsing support board/xilinx/Kconfig | 8 - board/xilinx/common/Makefile | 3 - board/xilinx/common/board.c | 63 ++++++-- cmd/Kconfig | 8 + cmd/Makefile | 1 + {board/xilinx/common => cmd}/fru.c | 3 +- common/Makefile | 2 + {board/xilinx/common => common}/fru_ops.c | 171 +++++++++++++++++++--- {board/xilinx/common => include}/fru.h | 37 +++-- 9 files changed, 237 insertions(+), 59 deletions(-) rename {board/xilinx/common => cmd}/fru.c (99%) rename {board/xilinx/common => common}/fru_ops.c (73%) rename {board/xilinx/common => include}/fru.h (76%) -- 2.25.1

2 9

[PATCH 1/1] fs/erofs: silence erofs_probe()
by Heinrich Schuchardt 01 Aug '22

01 Aug '22

fs_set_blk_dev() probes all file-systems until it finds one that matches the volume. We do not expect any console output for non-matching file-systems. Convert error messages in erofs_read_superblock() to debug output. Fixes: 830613f8f5bb ("fs/erofs: add erofs filesystem support") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- fs/erofs/super.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/erofs/super.c b/fs/erofs/super.c index 4cca322b9e..095754dc28 100644 --- a/fs/erofs/super.c +++ b/fs/erofs/super.c @@ -65,14 +65,14 @@ int erofs_read_superblock(void) ret = erofs_blk_read(data, 0, 1); if (ret < 0) { - erofs_err("cannot read erofs superblock: %d", ret); + erofs_dbg("cannot read erofs superblock: %d", ret); return -EIO; } dsb = (struct erofs_super_block *)(data + EROFS_SUPER_OFFSET); ret = -EINVAL; if (le32_to_cpu(dsb->magic) != EROFS_SUPER_MAGIC_V1) { - erofs_err("cannot find valid erofs superblock"); + erofs_dbg("cannot find valid erofs superblock"); return ret; } @@ -81,7 +81,7 @@ int erofs_read_superblock(void) blkszbits = dsb->blkszbits; /* 9(512 bytes) + LOG_SECTORS_PER_BLOCK == LOG_BLOCK_SIZE */ if (blkszbits != LOG_BLOCK_SIZE) { - erofs_err("blksize %u isn't supported on this platform", + erofs_dbg("blksize %u isn't supported on this platform", 1 << blkszbits); return ret; } -- 2.36.1

4 4