December 2024 - U-Boot

[PATCH next RFC 0/5] rockchip: panic() when DRAM init fails
by Quentin Schulz 17 Jan '25

17 Jan '25

I am the unfortunate owner of an RK3399 Puma that is failing DRAM init every now and then with the following cryptic error message: """ pctl_start: Failed to init pctl channel 0 """ When it fails, the current logic is implemented in such a way that the board enters an infinite while loop. This is not ideal for embedded systems that are not easily accessible and also an issue when having devices in a CI lab for example. Therefore, let's simply panic if the DRAM fails to init. This was tested only on RK3399 Puma, similar changes may be required for other SoCs to properly propagate the errors. While this is all but a work-around instead of fixing the DRAM init sequence, I believe it is important for resilience of devices in the field. Marking this as RFC because: 1) panic()s for all Rockchip SoCs but only tested on RK3399 2) unsure about error return values (ENODEV and the likes), not sure what would be better than that though :/ Note that one can still hang() if they want by setting PANIC_HANG symbol. Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Quentin Schulz (5): ram: rk3399: allow to fail DRAM init if pctl_start fails ram: rk3399: fail probe if DRAM init failed rockchip: spl/tpl: panic when DRAM init failed ram: rk3399: merge two consecutive ifs with same condition ram: rk3399: fail DRAM init when pctl channel init fails instead of hanging arch/arm/mach-rockchip/spl.c | 7 +++---- arch/arm/mach-rockchip/tpl.c | 6 ++---- drivers/ram/rockchip/sdram_rk3399.c | 24 +++++++++++------------- 3 files changed, 16 insertions(+), 21 deletions(-) --- base-commit: 56accc56b9aab87ef4809ccc588e1257969cd271 change-id: 20241105-rk3399-dram-init-207325c2d9ca Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

3 10

[PATCH] dfu: Prevent set_dfu_alt_info() from overwriting a previous value
by Jonathan Humphreys 17 Jan '25

17 Jan '25

If CONFIG_SET_DFU_ALT_INFO is enabled, the dfu_alt_info environment variable is dynamically set when initializing the DFU entities, which is done as part of normal flow of a DFU operation. The USB DFU boot support will set it's own specific value for dfu_alt_info before performing the DFU operation. This means that if CONFIG_SET_DFU_ALT_INFO is enabled, the dfu_alt_info environment variable that the USB DFU boot path had set is overwritten, causing USB DFU boot to fail. Likewise, if the user sets their own value for dfu_alt_info, say at the U-Boot prompt, it get's overwritten if CONFIG_SET_DFU_ALT_INFO is enabled. This patch will first check that dfu_alt_info isn't already set before calling set_dfu_alt_info(), when CONFIG_SET_DFU_ALT_INFO is enabled. Signed-off-by: Jonathan Humphreys <j-humphreys(a)ti.com> --- drivers/dfu/dfu.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c index 756569217bb..ab8abae1d89 100644 --- a/drivers/dfu/dfu.c +++ b/drivers/dfu/dfu.c @@ -169,10 +169,13 @@ int dfu_init_env_entities(char *interface, char *devstr) dfu_reinit_needed = false; dfu_alt_info_changed = false; + str_env = env_get("dfu_alt_info"); #ifdef CONFIG_SET_DFU_ALT_INFO - set_dfu_alt_info(interface, devstr); + if (!str_env) { + set_dfu_alt_info(interface, devstr); + str_env = env_get("dfu_alt_info"); + } #endif - str_env = env_get("dfu_alt_info"); if (!str_env) { pr_err("\"dfu_alt_info\" env variable not defined!\n"); return -EINVAL; -- 2.34.1

6 8

[PATCH 0/3] fdt_support: improve board_fdt_chosen_bootargs() for flexibility
by Dmitry Rokosov 17 Jan '25

17 Jan '25

This series consists of three patches. The first patch modifies the function documentation style in the include/fdt_support.h file to comply with kernel-doc requirements. The second patch modifies the board_fdt_chosen_bootargs() function to return a const char* type. This change clarifies to the caller that the returned string should neither be freed nor modified. It aligns with the existing fdt_setprop() function, which already utilizes a const char* parameter. This promotes consistency within the codebase and enhances code safety by preventing unintended modifications to the returned string. The third patch addresses the need for flexibility in providing kernel command line arguments (bootargs) for different kernel images within the same U-Boot environment. It introduces a read-only (RO) fdt_property argument to the board_fdt_chosen_bootargs() function, allowing access to the original chosen/bootargs data. This is crucial for scenarios where different kernel versions require distinct console setups (e.g., ttyS0 for vendor kernels and ttyAML0 for upstream kernels). By enabling board developers to either merge or replace the original bootargs, this patch enhances the configurability of U-Boot for various kernel images without relying on outdated configurations like CMDLINE_EXTEND. CI/CD results: https://github.com/u-boot/u-boot/pull/716/checks Signed-off-by: Dmitry Rokosov <ddrokosov(a)salutedevices.com> --- Dmitry Rokosov (3): include/fdt_support: fix docstyle to comply with kernel-doc requirements fdt_support: board_fdt_chosen_bootargs() should return const char* common: fdt: hand over original fdt bootargs into board chosen handler boot/fdt_support.c | 7 +- include/fdt_support.h | 173 ++++++++++++++++++++++++++++++-------------------- 2 files changed, 107 insertions(+), 73 deletions(-) --- base-commit: 69bd83568c57813cd23bc2d100c066a17e7e349d change-id: 20241219-board_fdt_chosen_bootargs_improvements-7646b2029ba7 Best regards, -- Dmitry Rokosov <ddrokosov(a)salutedevices.com>

5 12

[PATCH] usb: xhci-dwc3: Bail out if "dr_mode" is "peripheral"
by Siddharth Vadapalli 16 Jan '25

16 Jan '25

Since the compatible "snps,dwc3" can be specified in the device-tree for the Designware USB Controller configured for not only Host and OTG modes of operation, but also for Peripheral mode of operation, bail out if "dr_mode" is "peripheral". Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> --- Hello, This patch is based on commit 448add55297 Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-pmic of the master branch of U-Boot. Regards, Siddharth. drivers/usb/host/xhci-dwc3.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c index e3e0ceff43e..7b1311503fe 100644 --- a/drivers/usb/host/xhci-dwc3.c +++ b/drivers/usb/host/xhci-dwc3.c @@ -208,6 +208,9 @@ static int xhci_dwc3_probe(struct udevice *dev) writel(reg, &dwc3_reg->g_usb2phycfg[0]); dr_mode = usb_get_dr_mode(dev_ofnode(dev)); + if (dr_mode == USB_DR_MODE_PERIPHERAL) + return -ENODEV; + if (dr_mode == USB_DR_MODE_OTG && dev_read_bool(dev, "usb-role-switch")) { dr_mode = usb_get_role_switch_default_mode(dev_ofnode(dev)); -- 2.43.0

3 4

[PATCH v4 00/19] bootstd: Support recording images
by Simon Glass 16 Jan '25

16 Jan '25

This series provides a way to keep track of the images used in bootstd, including the type of each image. At present this is sort-of handled by struct bootflow but in quite an ad-hoc way. The structure has become quite large and is hard to query. Future work will be able to reduce its size. Ultimately the 'bootflow info' command may change to also show images as a list, but that is left for later, as this series is already fairly long. So for now, just introduce the concept and adjust bootstd to use it, with a simple command to list the images. This series includes various alist enhancements, to make use of this new data structure a little easier. Changes in v4: - Make sure that bflow->buf is set correctly - Rebase on top of -master (which now has bootflow_efi() test) Changes in v3: - Add a helper in bootflow - Add a new patch supporting ad-hoc bootflows - Add new patch to export bootdev_get_from_blk() - Add new patch to record loaded files in an ad-hoc bootflow - Update bootstd_add_bootflow() to return the element number - Use the helper function Changes in v2: - Add an image type extension in bootflow.h - Change the tag to bootmeth_efi - Drop patches already applied - Drop patches which add new image types - Update to use a new image-type enum in bootflow.h - Use the word 'feature' instead of 'hack' Simon Glass (19): bootstd: Move bootflow-adding to bootstd bootstd: Move bootflow-clearing to bootstd bootstd: Add a function to get bootstd only if available bootstd: Drop the bootdev-specific list of bootflows bootstd: Move the bootflow list into an alist bootstd: Maintain a list of images bootstd: Update bootmeth_alloc_file() to record images boot: pxe: Drop the duplicate comment on get_pxe_file() bootmeth_efi: Simplify reading files by using the common function bootmeth: Update the read_file() method to include a type bootmeth_efi: Check the filename-allocation in the network path boot: Update extlinux pxe_getfile_func() to include type boot: Update pxe bootmeth to record images Update bootmeth_alloc_other() to record images bootstd: Update cros bootmeth to record images bootstd: Add a simple command to list images bootstd: Export bootdev_get_from_blk() bootstd: Add the concept of an ad-hoc bootflow fs: Record loaded files in an ad-hoc bootflow boot/bootdev-uclass.c | 78 ++++++------------- boot/bootflow.c | 77 +++++++++++++++---- boot/bootmeth-uclass.c | 29 +++++-- boot/bootmeth_android.c | 3 +- boot/bootmeth_cros.c | 17 ++++- boot/bootmeth_efi.c | 16 ++-- boot/bootmeth_efi_mgr.c | 3 +- boot/bootmeth_extlinux.c | 7 +- boot/bootmeth_pxe.c | 10 ++- boot/bootmeth_qfw.c | 3 +- boot/bootmeth_sandbox.c | 3 +- boot/bootmeth_script.c | 7 +- boot/bootstd-uclass.c | 104 +++++++++++++++++++++++-- boot/pxe_utils.c | 36 ++++----- boot/vbe_simple.c | 5 +- cmd/Kconfig | 9 +++ cmd/Makefile | 1 + cmd/bootdev.c | 2 +- cmd/bootflow.c | 11 +-- cmd/bootstd.c | 65 ++++++++++++++++ cmd/pxe.c | 2 +- cmd/sysboot.c | 6 +- doc/develop/bootstd/overview.rst | 24 +++++- doc/usage/cmd/bootstd.rst | 79 +++++++++++++++++++ doc/usage/index.rst | 1 + fs/fs.c | 15 ++++ include/bootdev.h | 36 +++------ include/bootflow.h | 88 ++++++++++++++++++--- include/bootmeth.h | 22 ++++-- include/bootstd.h | 69 ++++++++++++++++- include/pxe_utils.h | 14 +++- test/boot/bootflow.c | 126 +++++++++++++++++++++++++++++++ test/py/tests/test_ut.py | 3 +- 33 files changed, 790 insertions(+), 181 deletions(-) create mode 100644 cmd/bootstd.c create mode 100644 doc/usage/cmd/bootstd.rst -- 2.34.1

2 38

[PATCH v5 0/8] bootstd: sunxi: Migrate to standard boot
by Simon Glass 15 Jan '25

15 Jan '25

This series attempts to migrate all sunxi boards to use standard boot, along with a text environment. Unfortunately a late-breaking problem has come up with bootmgr. There are two ways to fix this, both included in this series: - Drop bootmgr for sunxi - Change efi_mgr bootmeth back to sandbox-only Based on the mailing-list discussion I have selected the first one and marked the second as RFC. Changes in v5: - Add new patch to drop bootmgr for sunxi Changes in v4: - Reword Kconfig - Add a name for the bootflow - Drop UUID_GPT_SYSTEM and UUID_GPT_ESP definitions - Drop special case for ARM64's devicetree subdir - Drop unwanted quotations and indentation in KERNEL_COMPAT path Changes in v3: - Drop wip (work-in-progress) comment in commit - Fix 'supressed' typo - Use backquotes to highlight DEFAULT_DEVICE_TREE Changes in v2: - Add new patch to resolve BOOTSTD->BLK recursion with Kconfig - Put the FEL bootmeth before all other global bootmeths - Convert the other DISTRO_DEFAULTS in the Kconfig too - Keep BOOTCMD_SUNXI_COMPAT - Keep bootcmd_sunxi_compat if OLD_SUNXI_KERNEL_COMPAT is enabled Simon Glass (8): bootstd: Avoid depending on BLK sunxi: Add a bootmeth for FEL efi_loader: bootstd: Drop bootmgr for sunxi RFC: Revert "bootstd: Make efi_mgr bootmeth work for non-sandbox setups" sunxi: Move to bootstd sunxi: Drop old distro boot variables env: Provide a work-around for unquoting fdtfile sunxi: Move to text environment Makefile | 1 + arch/arm/Kconfig | 10 +- board/sunxi/sunxi.env | 140 +++++++++++ boot/Kconfig | 18 +- boot/Makefile | 1 + boot/bootmeth_efi_mgr.c | 18 +- boot/bootmeth_fel.c | 84 +++++++ .../gardena-smart-gateway-mt7688_defconfig | 1 + doc/usage/environment.rst | 12 + include/configs/sunxi-common.h | 238 ------------------ 10 files changed, 261 insertions(+), 262 deletions(-) create mode 100644 board/sunxi/sunxi.env create mode 100644 boot/bootmeth_fel.c -- 2.34.1

5 31

[PATCH v4 0/5] rpi: Tidy up booting
by Simon Glass 15 Jan '25

15 Jan '25

This series allows rpi to boot a compressed Ubuntu kernel with ~100MB ramdisk, by expanding the available space. It also tidies up some strange behaviour with the provided FDT, where a separate pointer is maintained to it, even though U-Boot has copied it and placed it in its own space. This avoids strange bugs where it accidentally gets overwritten when loading a file into memory. The patch to expand the devicetree was dropped, meaning that people should be careful to unset fdt_addr in the environment. In version 2, it incorporates some changes to fdt_addr, etc. suggested by Tom, as well as adding myself as a maintainer. Changes in v4: - Expand the comment on set_fdt_addr() - Update the commit message to talk in terms of my testing Changes in v3: - Add to the existing comment block - Update the comment block with the new values, including compression Changes in v2: - Add new patch to make myself an rpi maintainer - Add new patch to set bootm_size - Add new patch to drop fdt_high and initrd_high - Drop patch to allow expanding the devicetree during relocation Simon Glass (5): rpi: Add myself to the list of maintainers rpi: Set bootm_size to 512MB rpi: Drop fdt_high and initrd_high rpi: Update environment to support booti and large initrd rpi: Use the U-Boot control FDT for fdt_addr MAINTAINERS | 1 + board/raspberrypi/rpi/rpi.c | 20 +++++++++---------- board/raspberrypi/rpi/rpi.env | 37 +++++++++++++++++++---------------- 3 files changed, 31 insertions(+), 27 deletions(-) -- 2.34.1

1 6

[PATCH v3 00/25] led: Remove old status-LED code
by Simon Glass 15 Jan '25

15 Jan '25

There has been an LED framework in U-Boot which uses driver model for about 9 years now. Recent work is underway to improve it and provide more features. It is probably a good time to drop the old code, which is only used by 5 boards: ./tools/qconfig.py -f LED_STATUS 5 matches eb_cpu5282 eb_cpu5282_internal mx23_olinuxino pinephone socfpga_vining_fpga This series attempts that. The new /options node provides a way to provide U-Boot settings, and LEDs are implemented there. For now I have brought into the options schema from upstream. We can update it once the LED additions land there. Changes in v3: - Update commit message - Combine removal and enable patches - Combine removal and enable patches - Combine removal and enable patches Changes in v2: - Combine code-removal and defconfig changes - Add a patch to enable LED and LED_BOOT for these boards - Enable LED on the 5 affected platforms - Reorder patches for bisectability - Add dt-schema bindings for LED Simon Glass (25): eb_cpu5282: Drop status-LED code and enable LED vining_fpga: Drop status-LED code and use LED mx23_olinuxino: Drop status-LED code and use LED pinephone: Drop status-LED code and use LED led: Drop LED_STATUS_BOARD_SPECIFIC arm: Drop old LED support common: doc: Drop old LED support st: stm32f429: Drop old LED code led: Make the LED config common led: Drop LED_STATUS from Kconfig led: Drop the legacy LED command misc: Drop gpio_led driver pca9551_led: Delete driver misc: status_led: Delete driver m68k: Drop unused status_led.h header file powerpc: Drop status-LED code igep00x0: Drop unused status_led.h header file sunxi: Drop status-LED code common: Drop status-LED code in board_r image: Drop unused status_led.h header file ide: Drop unused status_led.h header file mpc83xx: Drop status-LED code net: Drop status-LED code led: Drop status_led header file doc: Add devicetree bindings for options arch/arm/lib/crt0.S | 4 - arch/m68k/lib/bootm.c | 3 - arch/powerpc/lib/interrupts.c | 6 - board/BuS/eb_cpu5282/eb_cpu5282.c | 20 -- board/isee/igep00x0/igep00x0.c | 1 - board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 - board/softing/vining_fpga/socfpga.c | 4 - board/st/stm32f429-discovery/Makefile | 1 - board/st/stm32f429-discovery/led.c | 39 --- board/sunxi/board.c | 6 - boot/image.c | 4 - cmd/Makefile | 1 - cmd/ide.c | 4 - cmd/legacy_led.c | 185 ---------- common/board_f.c | 22 -- common/board_r.c | 27 -- configs/eb_cpu5282_defconfig | 8 +- configs/eb_cpu5282_internal_defconfig | 8 +- configs/mx23_olinuxino_defconfig | 10 +- configs/pinephone_defconfig | 7 +- configs/socfpga_vining_fpga_defconfig | 13 +- doc/README.LED | 77 ----- doc/device-tree-bindings/options.yaml | 79 +++++ doc/device-tree-bindings/options/u-boot.yaml | 136 ++++++++ drivers/led/Kconfig | 342 +------------------ drivers/misc/Kconfig | 13 - drivers/misc/Makefile | 3 - drivers/misc/gpio_led.c | 106 ------ drivers/misc/pca9551_led.c | 170 --------- drivers/misc/status_led.c | 124 ------- drivers/timer/mpc83xx_timer.c | 5 - include/configs/eb_cpu5282.h | 6 - include/status_led.h | 115 ------- net/bootp.c | 7 - net/net.c | 33 -- 35 files changed, 236 insertions(+), 1360 deletions(-) delete mode 100644 board/st/stm32f429-discovery/led.c delete mode 100644 cmd/legacy_led.c delete mode 100644 doc/README.LED create mode 100644 doc/device-tree-bindings/options.yaml create mode 100644 doc/device-tree-bindings/options/u-boot.yaml delete mode 100644 drivers/misc/gpio_led.c delete mode 100644 drivers/misc/pca9551_led.c delete mode 100644 drivers/misc/status_led.c delete mode 100644 include/status_led.h -- 2.43.0

4 58

[PATCH 0/2] efi_loader: efi_setup: Add efi_start_obj_list() and use it to set PXE IP address
by Adriano Cordova 15 Jan '25

15 Jan '25

The command bootefi calls efi_init_obj_list to do the efi set up before launching an .efi payload, but efi_init_obj_list is called only once. There are some initializations which depend on the environment and should be done each time a payload gets launched and not only once and can now be done in efi_start_obj_list(). A motivation for this change is the following order of events: 1. Launch an EFI application (e.g. bootefi hello) 2. Change the ip address 3. Launch another application which uses the pxe protocol As the EFI pxe protocol was initialized when the handles for efi net were created in 1., the ip was hardcoded there. In this example, another possibility would be to make a callback for ip address changes to go all the way up to efi_net. Adriano Cordova (2): efi_loader: efi_setup: Add efi_start_obj_list() to efi_setup.c efi_loader: efi_net: Add efi_net_start() to efi_net.c include/efi_loader.h | 1 + lib/efi_loader/efi_net.c | 31 ++++++++++++++++++++++++------- lib/efi_loader/efi_setup.c | 24 +++++++++++++++++++++++- 3 files changed, 48 insertions(+), 8 deletions(-) -- 2.43.0

5 9

[PATCH 0/5] pxe: Support an automatic localboot
by Simon Glass 15 Jan '25

15 Jan '25

It seems that extlinux expects that boards know how to boot a local OS from attached media. U-Boot currently assumes that boards define a "localcmd" environment variable to support this. None does. Provide an automatic means to find a kernel and ramdisk, using common filenames. This addresses booting on MAAS, at least. Simon Glass (5): test/py: Refactor extlinux-image creation into a function test: bootflow: Avoid a confusing error condition pxe_utils: Allow the FDT to be missing pxe_utils: Support a backup for localboot pxe_utils: Support the SAY command arch/sandbox/dts/test.dts | 8 ++++ boot/Kconfig | 9 +++++ boot/pxe_utils.c | 50 ++++++++++++++++++++--- test/boot/bootflow.c | 56 +++++++++++++++++++++++++- test/py/tests/test_ut.py | 85 ++++++++++++++++++++++++++------------- 5 files changed, 173 insertions(+), 35 deletions(-) -- 2.34.1

3 22