July 2023 - U-Boot

[PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
by Rasmus Villemoes 04 Oct '23

04 Oct '23

I have a couple of boards, e.g. foo21, bar33, each with a few different revisions, so I have foo21-revA.dts foo21-revB.dts bar33-revA.dts bar33-revB.dts Now the necessary U-Boot specific additions for the foo21 boards doesn't depend on the revision (likely for bar33), so I just want to have and maintain one foo21-u-boot.dtsi But currently I need to add dummy files foo21-revA-u-boot.dtsi and foo21-revB-u-boot.dtsi each just containing '#include foo21-u-boot.dtsi'. And similarly for bar33, and all those files become quite unwieldy as more revisions need to be supported. It's quite natural to look for a file named after CONFIG_SYS_BOARD, with lower precedence of course than a -u-boot.dtsi file with the same basename as the .dts, but higher than CONFIG_SYS_SOC. Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> --- Of course, this can cause unwanted changes for existing boards. But a bit of ad hoc scripting shows that the risk is low: I first grabbed all 'default "foo"' stanzas of all 'config SYS_BOARD' instances, as well as all values of CONFIG_SYS_BOARD set in *_defconfig files. Then I made a list of all existing *-u-boot.dtsi files, and from these removed any where there is a corresponding .dts file. That leaves just imx6ul imx8mm mt7620 mt7621 mt7622 mt7623 mt7628 mt8516 socfpga_arria10 sunxi and inspecting a few of those suggests that they set SYS_SOC to the same as SYS_BOARD, i.e. they were already picking up the .dtsi file due to the SYS_SOC rule. Now, the only way to be really sure is to build the world with/without this patch and check if any .dtb file changes, but I don't have the means to do that. But I do notice that doc/develop/devicetree/control.rst | 1 + scripts/Makefile.lib | 2 ++ 2 files changed, 3 insertions(+) diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index c71570d64b..831d225fb1 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -174,6 +174,7 @@ devicetree for your board, searching for them in the same directory as the main file, in this order:: <orig_filename>-u-boot.dtsi + <CONFIG_SYS_BOARD>-u-boot.dtsi <CONFIG_SYS_SOC>-u-boot.dtsi <CONFIG_SYS_CPU>-u-boot.dtsi <CONFIG_SYS_VENDOR>-u-boot.dtsi diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index ecc15041ee..69f4d560d1 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -160,6 +160,7 @@ ld_flags = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F)) # Try these files in order to find the U-Boot-specific .dtsi include file u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \ + $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_BOARD))-u-boot.dtsi) \ $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \ $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \ $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \ @@ -167,6 +168,7 @@ u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boo u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \ $(dir $<)$(basename $(notdir $<))-u-boot.dtsi \ + $(dir $<)$(subst $\",,$(CONFIG_SYS_BOARD))-u-boot.dtsi \ $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \ $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \ $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \ -- 2.37.2

3 38

[PATCH] test: fix comment indentation on tpm tests
by Ilias Apalodimas 01 Oct '23

01 Oct '23

One out comments is off by one, adjust it Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> --- test/dm/tpm.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/test/dm/tpm.c b/test/dm/tpm.c index 3defb3c3da1f..cde933ab2848 100644 --- a/test/dm/tpm.c +++ b/test/dm/tpm.c @@ -98,10 +98,11 @@ static int test_tpm_autostart(struct unit_test_state *uts, if (reinit) ut_assertok(tpm_init(dev)); - /* - * tpm_auto_start will rerun tpm_init() if reinit, but handles the - * -EBUSY return code internally. - */ + + /* + * tpm_auto_start will rerun tpm_init() if reinit, but handles the + * -EBUSY return code internally. + */ ut_assertok(tpm_auto_start(dev)); return 0; -- 2.39.2

3 3

[PATCH] rockchip: rk3399: nanopc-t4: use 1600MHz sdram config
by Lu jicong 30 Sep '23

30 Sep '23

Current 1866MHz sdram config is too high for NanoPC-T4. On this frequency, its lpddr3 sdram becomes unstable, causing memtest failures and random kernel crashes. Signed-off-by: Lu jicong <jiconglu58(a)gmail.com> --- arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi index 17201bcf41..8b6c9059ab 100644 --- a/arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi +++ b/arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi @@ -4,4 +4,4 @@ */ #include "rk3399-nanopi4-u-boot.dtsi" -#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi" +#include "rk3399-sdram-lpddr3-4GB-1600.dtsi" -- 2.39.2

2 3

[PATCH v2 0/6] Kbuild: Fix cleanup of generated sources in tools (and more)
by Tobias Deiminger 28 Sep '23

28 Sep '23

This patch series fixes various unexpected leftovers after running make clean and make mrproper. The test suggested during review of v1 [0] revealed more cleanup related issues. I thought it's best to fix them all together in a somewhat extended v2, to let the new test pass without cheating. Changes in v2: - add test for 'make clean' and 'make mrproper' - fix found issues until test passes - move .gitignore changes to separate commit [0] http://patchwork.ozlabs.org/project/uboot/patch/20230614113954.51812-2-tobi… Tobias Deiminger (6): Kbuild: Fix cleanup of generated sources in tools Adjust gitignore for tools/generated/ Kbuild: Fix cleanup of VPL Kbuild: Fix cleanup of *.dtb for some archs Kbuild: Fix cleanup of *.dtbo for sandbox test: Find leftovers after clean/mrproper Makefile | 4 +- arch/sandbox/dts/Makefile | 2 +- dts/Makefile | 4 +- test/py/tests/test_cleanup_build.py | 105 ++++++++++++++++++++++++++++ tools/.gitignore | 1 + tools/Makefile | 64 ++++++++--------- tools/env/.gitignore | 1 - 7 files changed, 144 insertions(+), 37 deletions(-) create mode 100644 test/py/tests/test_cleanup_build.py base-commit: 50842b217fef505a0ec6662cc2acdc55d0bb23c5 -- 2.30.2

3 13

[PATCH v4 0/1] CONFIG_IS_ENABLED vs IS_ENABLED
by Troy Kisky 27 Sep '23

27 Sep '23

This patch set gets ready to checks the usage of CONFIG_IS_ENABLED/IS_ENABLED. After the set has been applied, you can delete test/usage_of_is_enabled_todo.txt and run test/usage_of_is_enabled_commit.sh The script test/usage_of_is_enabled_check.sh checks for new questionable uses of CONFIG_IS_ENABLED/IS_ENABLED and is added to .azure-pipelines.yml, and .gitlab-ci.yml version 4 changes: Down to just one patch, other issue fixed by other means Added the following new configs to todo ACPI DM_CLK FEC_MXC FWU_MULTI_BANK_UPDATE IMX8M_VDD_SOC_850MV MCFTMR PANEL SANDBOX64 SPLASH_SCREEN SPLASH_SOURCE SPL_LOAD_FIT USB_ETH_RNDIS VIDEO VIDEO_BPP16 VIDEO_BPP32 VIDEO_BPP8 VIDEO_LOGO X86_32BIT_INIT version 3 changes: Dropped changes to puma-rk3399 and ringneck-px30 in favor of Quentin Schulz's patch https://patchwork.ozlabs.org/project/uboot/patch/20230301-tsd-env-nowhere-k… https://patchwork.ozlabs.org/project/uboot/patch/20230301-tsd-env-nowhere-k… Please apply them before this series. Drop gateworks: venice: Always define setup_fec and setup_eqos Drop arm: cpu: armv7: ls102xa: fdt: remove eth_device support Simon's patches took care of these Add to todo list, these new questionable uses that snuck into the code. PARTITION_TYPE_GUID PHY_ATHEROS RTC_SANDBOX (no changes since v1) Troy Kisky (1): CI: add test/usage_of_is_enabled_check.sh .azure-pipelines.yml | 11 ++ .gitlab-ci.yml | 5 + test/usage_of_is_enabled_check.sh | 19 +++ test/usage_of_is_enabled_commit.sh | 12 ++ test/usage_of_is_enabled_correct.sh | 50 +++++++ test/usage_of_is_enabled_exempt.txt | 9 ++ test/usage_of_is_enabled_list.sh | 86 +++++++++++ test/usage_of_is_enabled_splcfg.txt | 21 +++ test/usage_of_is_enabled_todo.txt | 213 ++++++++++++++++++++++++++++ 9 files changed, 426 insertions(+) create mode 100755 test/usage_of_is_enabled_check.sh create mode 100755 test/usage_of_is_enabled_commit.sh create mode 100755 test/usage_of_is_enabled_correct.sh create mode 100644 test/usage_of_is_enabled_exempt.txt create mode 100755 test/usage_of_is_enabled_list.sh create mode 100644 test/usage_of_is_enabled_splcfg.txt create mode 100644 test/usage_of_is_enabled_todo.txt -- 2.34.1

1 3

[PATCH 00/20] sunxi: Allwinner T113s support
by Andre Przywara 27 Sep '23

27 Sep '23

Hi, this is finally the series adding support for the new SoC series that covers the Allwinner D1 siblings R528 and T113s. They all share the same die, although the D1 and D1s use RISC-V cores, which requires more plumbing, to use the sunxi code across two architectures. Getting the R528 support in should help a bit in sorting out what's new peripheral code and what is architecture dependent. IIUC, Samuel has that running, although with some hacks, the number of which this series tries to reduce. The most interesting part of this is the pincontroller rework, this tackles two issues: - For the first time in the history of mainline Allwinner support the pincontroller changed the register layout. The code here tries to abstract the differences away, so both variants can share the code peacefully. - For the above mentioned reason, the pincontroller code is quite old, and is mostly spread out across arch/arm, in a pre-DM style, even though we have real DM support in U-Boot proper. We need the non-DM version for the (ARM-only?) legacy SPL, so can't get rid of that completely. This series also tries to modernise that code, and moves it into board/sunxi/, where it can be more easily shared with RISC-V. The main feature is then of course the T113s support, of which the new pinctroller is only one part. Apart from the new pincontroller and the usual new SoC bits (like clock and pinmux support), this includes the DRAM controller code. With the basics in, we add support for the MangoPi MQ-R board, which uses the T113s and seems to be a popular board. This should also serve as a blueprint for supporting similar boards. The DTs are copied from the kernel (as usual). There are some bits missing, prominently PSCI support. There are good patches out there, I just didn't manage to test and review them yet, but hopefully they can follow directly in the wake of this series. This series is based on top of current sunxi/master, which covers the first part of the 2023.10 pull request. Compared to the RFC post from December(!), there were numerous changes, inspired by comments from the community reviewers, many thanks to all of them! A branch is available at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git t113s Please have a look, review and test. Cheers, Andre Andre Przywara (18): net: sunxi_emac: chase DT nodes to find PHY regulator sunxi: remove CONFIG_MACPWR pinctrl: sunxi: add GPIO in/out wrappers pinctrl: sunxi: remove struct sunxi_gpio pinctrl: sunxi: move pinctrl code and remove GPIO_EXTRA_HEADER pinctrl: sunxi: move PIO_BASE into sunxi_gpio.h pinctrl: sunxi: add new D1 pinctrl support sunxi: introduce NCAT2 generation model pinctrl: sunxi: add Allwinner D1 pinctrl description sunxi: clock: D1/R528: Enable PLL LDO during PLL1 setup sunxi: clock: support D1/R528 PLL6 clock sunxi: clock: h6: prepare for PRCM less SoCs Kconfig: sunxi: prepare for using drivers/ram/sunxi sunxi: add R528/T113-s3/D1(s) DRAM initialisation code sunxi: add Allwinner R528/T113 SoC support sunxi: refactor serial base addresses to avoid asm/arch/cpu.h ARM: dts: sunxi: add Allwinner T113-s SoC .dtsi sunxi: add MangoPi MQ-R board support Samuel Holland (2): clk: sunxi: Add support for the D1 CCU riscv: dts: allwinner: Add the D1/D1s SoC devicetree arch/arm/Kconfig | 1 - arch/arm/cpu/armv7/sunxi/sram.c | 1 + arch/arm/cpu/armv8/fel_utils.S | 1 + arch/arm/dts/Makefile | 2 + .../arm/dts/sun8i-t113s-mangopi-mq-r-t113.dts | 35 + arch/arm/dts/sun8i-t113s.dtsi | 59 + arch/arm/dts/sunxi-d1s-t113-mangopi-mq-r.dtsi | 126 ++ arch/arm/dts/sunxi-u-boot.dtsi | 7 + arch/arm/include/asm/arch-sunxi/boot0.h | 2 + arch/arm/include/asm/arch-sunxi/clock.h | 3 +- .../include/asm/arch-sunxi/clock_sun50i_h6.h | 12 +- arch/arm/include/asm/arch-sunxi/cpu.h | 2 + arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 17 - .../include/asm/arch-sunxi/cpu_sun50i_h6.h | 7 - arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 9 - .../include/asm/arch-sunxi/cpu_sunxi_ncat2.h | 39 + arch/arm/include/asm/arch-sunxi/mmc.h | 2 +- arch/arm/include/asm/arch-sunxi/prcm.h | 2 +- arch/arm/include/asm/arch-sunxi/serial.h | 32 + arch/arm/include/asm/arch-sunxi/timer.h | 2 +- arch/arm/mach-sunxi/Kconfig | 36 +- arch/arm/mach-sunxi/Makefile | 2 +- arch/arm/mach-sunxi/board.c | 31 +- arch/arm/mach-sunxi/clock_sun50i_h6.c | 60 +- arch/arm/mach-sunxi/cpu_info.c | 2 + arch/arm/mach-sunxi/dram_suniv.c | 2 +- arch/arm/mach-sunxi/gtbus_sun9i.c | 1 + arch/arm/mach-sunxi/pinmux.c | 78 - arch/arm/mach-sunxi/spl_spi_sunxi.c | 1 + arch/arm/mach-sunxi/timer.c | 1 + arch/riscv/dts/sun20i-common-regulators.dtsi | 28 + arch/riscv/dts/sun20i-d1.dtsi | 66 + arch/riscv/dts/sun20i-d1s.dtsi | 76 + arch/riscv/dts/sunxi-d1-t113.dtsi | 15 + arch/riscv/dts/sunxi-d1s-t113.dtsi | 846 ++++++++++ board/sunxi/Makefile | 1 + board/sunxi/board.c | 13 +- board/sunxi/chip.c | 2 +- board/sunxi/pinctrl.c | 115 ++ common/spl/Kconfig | 3 +- configs/Bananapi_M2_Ultra_defconfig | 1 - configs/Bananapi_defconfig | 1 - configs/Bananapro_defconfig | 1 - configs/Lamobo_R1_defconfig | 1 - configs/Mele_A1000_defconfig | 1 - configs/Orangepi_defconfig | 1 - configs/Orangepi_mini_defconfig | 1 - configs/bananapi_m1_plus_defconfig | 1 - configs/bananapi_m2_plus_h3_defconfig | 1 - configs/bananapi_m2_plus_h5_defconfig | 1 - configs/i12-tvbox_defconfig | 1 - configs/jesurun_q5_defconfig | 1 - configs/mangopi_mq_r_defconfig | 15 + configs/mixtile_loftq_defconfig | 1 - configs/nanopi_m1_plus_defconfig | 1 - configs/nanopi_neo_plus2_defconfig | 1 - configs/nanopi_r1s_h5_defconfig | 1 - configs/orangepi_pc2_defconfig | 1 - configs/orangepi_plus2e_defconfig | 1 - configs/orangepi_plus_defconfig | 1 - configs/orangepi_win_defconfig | 1 - configs/pine_h64_defconfig | 1 - configs/zeropi_defconfig | 1 - drivers/Makefile | 1 + drivers/clk/sunxi/Kconfig | 7 + drivers/clk/sunxi/Makefile | 1 + drivers/clk/sunxi/clk_d1.c | 84 + drivers/clk/sunxi/clk_sunxi.c | 5 + drivers/gpio/axp_gpio.c | 1 + drivers/gpio/sunxi_gpio.c | 50 +- drivers/i2c/mvtwsi.c | 3 +- drivers/i2c/sun6i_p2wi.c | 2 +- drivers/i2c/sun8i_rsb.c | 2 +- drivers/mmc/sunxi_mmc.c | 12 +- drivers/net/sun8i_emac.c | 9 +- drivers/net/sunxi_emac.c | 39 + drivers/pinctrl/sunxi/Kconfig | 5 + drivers/pinctrl/sunxi/pinctrl-sunxi.c | 43 +- drivers/ram/Kconfig | 3 +- drivers/ram/Makefile | 3 + drivers/ram/sunxi/Kconfig | 72 + drivers/ram/sunxi/Makefile | 4 + drivers/ram/sunxi/dram_sun20i_d1.c | 1432 +++++++++++++++++ drivers/ram/sunxi/dram_sun20i_d1.h | 73 + drivers/video/hitachi_tx18d42vm_lcd.c | 1 + drivers/video/ssd2828.c | 1 - drivers/video/sunxi/sunxi_display.c | 1 + drivers/video/sunxi/sunxi_lcd.c | 1 + include/configs/sunxi-common.h | 2 +- include/dt-bindings/clock/sun20i-d1-ccu.h | 158 ++ include/dt-bindings/clock/sun20i-d1-r-ccu.h | 19 + include/dt-bindings/reset/sun20i-d1-ccu.h | 79 + include/dt-bindings/reset/sun20i-d1-r-ccu.h | 16 + .../arch-sunxi/gpio.h => include/sunxi_gpio.h | 104 +- 94 files changed, 3723 insertions(+), 287 deletions(-) create mode 100644 arch/arm/dts/sun8i-t113s-mangopi-mq-r-t113.dts create mode 100644 arch/arm/dts/sun8i-t113s.dtsi create mode 100644 arch/arm/dts/sunxi-d1s-t113-mangopi-mq-r.dtsi create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h create mode 100644 arch/arm/include/asm/arch-sunxi/serial.h delete mode 100644 arch/arm/mach-sunxi/pinmux.c create mode 100644 arch/riscv/dts/sun20i-common-regulators.dtsi create mode 100644 arch/riscv/dts/sun20i-d1.dtsi create mode 100644 arch/riscv/dts/sun20i-d1s.dtsi create mode 100644 arch/riscv/dts/sunxi-d1-t113.dtsi create mode 100644 arch/riscv/dts/sunxi-d1s-t113.dtsi create mode 100644 board/sunxi/pinctrl.c create mode 100644 configs/mangopi_mq_r_defconfig create mode 100644 drivers/clk/sunxi/clk_d1.c create mode 100644 drivers/ram/sunxi/Kconfig create mode 100644 drivers/ram/sunxi/Makefile create mode 100644 drivers/ram/sunxi/dram_sun20i_d1.c create mode 100644 drivers/ram/sunxi/dram_sun20i_d1.h create mode 100644 include/dt-bindings/clock/sun20i-d1-ccu.h create mode 100644 include/dt-bindings/clock/sun20i-d1-r-ccu.h create mode 100644 include/dt-bindings/reset/sun20i-d1-ccu.h create mode 100644 include/dt-bindings/reset/sun20i-d1-r-ccu.h rename arch/arm/include/asm/arch-sunxi/gpio.h => include/sunxi_gpio.h (73%) -- 2.35.8

4 38

Trying to boot custom kernel on Wink Hub (i.MX28)
by Rogan Dawes 26 Sep '23

26 Sep '23

Hi folks, I am trying to boot a custom kernel on a Wink Hub v1, which has an i.MX28 CPU, and is running U-Boot (U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38)). I have tried compiling my own modern kernel and putting it in place of the vendor (Linux version 2.6.35.3-flex-dvt) kernel on the flash chip, but when loading, I simply get the expected U-Boot loading messages, but then nothing at all from the serial port after that. I'm trying to figure out where my problem is most likely to be. As far as I am aware from long-ago poking at U-Boot, the way that U-Boot passes arguments to the kernel has changed recently? Previously it was ATAGS, and now it expects a Device Tree Blob? Might this explain the failure to boot that I am seeing? And yes, I understand that given that Many thanks! Rogan P.S. I have also tried to boot the OpenWrt Duckbill kernel (a few years ago), with the same results ( https://forum.openwrt.org/t/porting-openwrt-to-winkhub-v1/56966): U-Boot 2014.01-14400-gda781c6-dirty (Apr 30 2014 - 22:35:38) CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: NAND, 3V3 DRAM: 64 MiB NAND: 128 MiB In: serial Out: serial Err: serial Net: FEC0 [PRIME] Hit any key to stop autoboot: 0 => setenv bootargs 'noinitrd console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi'; mtdparts default && ubi part database && ubifsmount ubi0:database && ubifsload ${loadaddr} openwrt-19.07.1-mxs-uImage 1799536 && bootm ${loadaddr} UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=3" UBI: MTD device size: 8 MiB UBI: number of good PEBs: 64 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 6 UBI: total number of reserved PEBs: 58 UBI: number of PEBs reserved for bad PEB handling: 2 UBI: max/mean erase counter: 63/45 UBIFS: mounted UBI device 0, volume 0, name "database" UBIFS: mounted read-only UBIFS: file system size: 5459968 bytes (5332 KiB, 5 MiB, 43 LEBs) UBIFS: journal size: 1015809 bytes (992 KiB, 0 MiB, 6 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: LZO UBIFS: reserved for root: 269835 bytes (263 KiB) Loading file 'openwrt-19.07.1-mxs-uImage' to addr 0x42000000 with size 1799536 (0x001b7570)... Done ## Booting kernel from Legacy Image at 42000000 ... Image Name: ARM OpenWrt Linux-4.14.167 Created: 2020-01-29 16:05:35 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1799472 Bytes = 1.7 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ...

2 31

[BUG] issues with new bootflow, uefi and virtio
by Vincent Stehlé 23 Sep '23

23 Sep '23

Hi, I am hitting an issue with the new bootflow when booting with UEFI from a virtio device on Qemu Arm. It seems the device number computation in efiload_read_file() does not work in the general virtio case, where it will pick the virtio device number instead of the block device index. On Qemu arm virt machine, many virtio mmio devices are provisioned in the memory map and no assumption can be made on the number of the actual virtio device in use in the general case. This is an extract of the output of `dm tree' on this platform, focused on the virtio device from which I would like to boot: virtio 31 [ + ] virtio-mmio |-- virtio_mmio@a003e00 blk 0 [ + ] virtio-blk | |-- virtio-blk#31 partition 0 [ + ] blk_partition | | |-- virtio-blk#31:1 partition 1 [ + ] blk_partition | | `-- virtio-blk#31:2 bootdev 2 [ + ] virtio_bootdev | `-- virtio-blk#31.bootdev In this extract the actual virtio device number is 31, as will be picked by efiload_read_file(), but the desired block device index is zero, as would be used with e.g. `ls virtio 0'. This can be reproduced for example with Buildroot qemu_aarch64_ebbr_defconfig or qemu_arm_ebbr_defconfig and updating the U-Boot version to v2023.04. This was working properly with U-Boot versions up to v2023.01. This seems to be very specific to virtio, as the numbers align much more nicely for e.g. USB mass storage or NVMe. To help debugging, the following patch forces the device number to zero in the case of virtio, which allows to boot again with UEFI and virtio on Qemu Arm. Hopefully this should give a hint of what is going on. I tried to create a fix by looking for the first child device of UCLASS_BLK, and use its devnum instead in the case of virtio. Sadly, I am not able to confirm if this is a proper fix as I am hitting other boot issues in the case of multiple boot devices of the same class it seems... Vincent. [1]: https://buildroot.org --- boot/bootmeth_efi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c index 6a97ac02ff5..e5b0d8614ff 100644 --- a/boot/bootmeth_efi.c +++ b/boot/bootmeth_efi.c @@ -117,7 +117,9 @@ static int efiload_read_file(struct blk_desc *desc, struct bootflow *bflow) * this can go away. */ media_dev = dev_get_parent(bflow->dev); - snprintf(devnum_str, sizeof(devnum_str), "%x", dev_seq(media_dev)); + snprintf(devnum_str, sizeof(devnum_str), "%x", + device_get_uclass_id(media_dev) == UCLASS_VIRTIO ? 0 : + dev_seq(media_dev)); strlcpy(dirname, bflow->fname, sizeof(dirname)); last_slash = strrchr(dirname, '/'); -- 2.39.2

3 10

[PATCH] rpi: Use OF_BOARD rather than OF_EMBED
by Peter Robinson 23 Sep '23

23 Sep '23

The use of OF_EMBED isn't recommended for standard use and the OF_BOARD is actually a better fit for the Raspberry Pi as the prior firmware provides a DT that can be used by U-Boot and the subsequent OS too, but it still allows the loading of a DT from disk as well if users wish to use the upstream kernel DT. Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> --- configs/rpi_0_w_defconfig | 2 +- configs/rpi_2_defconfig | 2 +- configs/rpi_3_32b_defconfig | 2 +- configs/rpi_3_b_plus_defconfig | 2 +- configs/rpi_3_defconfig | 2 +- configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/rpi_defconfig | 2 +- 9 files changed, 9 insertions(+), 6 deletions(-) diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig index 5249b29d76c..8c217848ca2 100644 --- a/configs/rpi_0_w_defconfig +++ b/configs/rpi_0_w_defconfig @@ -23,7 +23,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index 154284765f4..bfc5679fb7e 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -24,7 +24,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig index ef1f25d2ad7..54cdcee980a 100644 --- a/configs/rpi_3_32b_defconfig +++ b/configs/rpi_3_32b_defconfig @@ -23,7 +23,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y diff --git a/configs/rpi_3_b_plus_defconfig b/configs/rpi_3_b_plus_defconfig index 154615d78a1..3008c7a1c18 100644 --- a/configs/rpi_3_b_plus_defconfig +++ b/configs/rpi_3_b_plus_defconfig @@ -22,7 +22,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig index f0cf7f8e236..f7b9108ba00 100644 --- a/configs/rpi_3_defconfig +++ b/configs/rpi_3_defconfig @@ -22,7 +22,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index 713b2ee231c..fa20ab767fe 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -24,6 +24,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 24f70b14fe8..741d4dbbbf4 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -24,6 +24,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 1d1ff12a58c..5e1195dd786 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -23,6 +23,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_TFTP_TSIZE=y diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index 28b92b14456..1504093eddf 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -23,7 +23,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -- 2.39.2

3 2

[PATCH] net: wget: Avoid packet queue overflow
by Richard Weinberger 23 Sep '23

23 Sep '23

Make sure to stay within bounds, as a misbehaving HTTP server can trigger a buffer overflow if not properly handled. Cc: Joe Hershberger <joe.hershberger(a)ni.com> Cc: Ramon Fried <rfried.dev(a)gmail.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> --- net/wget.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/wget.c b/net/wget.c index 2dbfeb1a1d5b..8bb4d72db1ae 100644 --- a/net/wget.c +++ b/net/wget.c @@ -35,7 +35,8 @@ struct pkt_qd { * The actual packet bufers are in the kernel space, and are * expected to be overwritten by the downloaded image. */ -static struct pkt_qd pkt_q[PKTBUFSRX / 4]; +#define PKTQ_SZ (PKTBUFSRX / 4) +static struct pkt_qd pkt_q[PKTQ_SZ]; static int pkt_q_idx; static unsigned long content_length; static unsigned int packets; @@ -202,6 +203,13 @@ static void wget_connected(uchar *pkt, unsigned int tcp_seq_num, pkt_q[pkt_q_idx].tcp_seq_num = tcp_seq_num; pkt_q[pkt_q_idx].len = len; pkt_q_idx++; + + if (pkt_q_idx >= PKTQ_SZ) { + printf("wget: Fatal error, queue overrun!\n"); + net_set_state(NETLOOP_FAIL); + + return; + } } else { debug_cond(DEBUG_WGET, "wget: Connected HTTP Header %p\n", pkt); /* sizeof(http_eom) - 1 is the string length of (http_eom) */ -- 2.26.2

2 4