June 2024 - U-Boot

[PATCH] arm: mvebu: Enable bootstd and other modernization for Synology DS414 (Armada XP) board
by Tony Dinh 12 Jun '24

12 Jun '24

- Switch to standard boot (in include/configs/ds414.h and configs/ds414_defconfig) - Implement board_late_init() to ensure successful enumeration of USB3 devices - Remove unnecessary misc_init_r(), since NET_RANDOM_ETHADDR is now configured in - Remove unnecessary checkboard() - Updated IDENT_STRING to indicate this u-boot supports both Synology DS414 and DS214+ boards - Add SYS_THUMB_BUILD to reduce binary size - Add NET_RANDOM_ETHADDR - Add CONFIG_LBA48 and CONFIG_SYS_64BIT_LBA to support >2TB HDD/SDD Signed-off-by: Tony Dinh <mibodhi(a)gmail.com> --- board/Synology/ds414/ds414.c | 15 +++-------- configs/ds414_defconfig | 20 ++++++-------- include/configs/ds414.h | 51 ++++++++++++++++++++++-------------- 3 files changed, 42 insertions(+), 44 deletions(-) diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c index abe6f9eb5e..f0b55fa095 100644 --- a/board/Synology/ds414/ds414.c +++ b/board/Synology/ds414/ds414.c @@ -181,18 +181,9 @@ int board_init(void) return 0; } -int misc_init_r(void) +int board_late_init(void) { - if (!env_get("ethaddr")) { - puts("Incomplete environment, populating from SPI flash\n"); - do_syno_populate(0, NULL); - } - return 0; -} - -int checkboard(void) -{ - puts("Board: DS414\n"); - + /* Do late init to ensure successful enumeration of XHCI devices */ + pci_init(); return 0; } diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig index ecf9501ba5..501ed51129 100644 --- a/configs/ds414_defconfig +++ b/configs/ds414_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_CPU_INIT=y +CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_MVEBU=y CONFIG_SUPPORT_PASSING_ATAGS=y CONFIG_CMDLINE_TAG=y @@ -25,44 +26,40 @@ CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=250000000 +CONFIG_IDENT_STRING="\nSynology DS214+/DS414 2/4-Bay Diskstation" CONFIG_SYS_LOAD_ADDR=0x800000 CONFIG_PCI=y CONFIG_DEBUG_UART=y +CONFIG_BOOTSTD_FULL=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyS0,115200 ip=off initrd=0x8000040,8M root=/dev/md0 rw syno_hw_version=DS414r1 ihd_num=4 netif_num=2 flash_size=8 SataLedSpecial=1 HddHotplug=1" -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="sf probe; sf read ${loadaddr} 0xd0000 0x2d0000; sf read ${ramdisk_addr_r} 0x3a0000 0x430000; bootm ${loadaddr} ${ramdisk_addr_r}" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_MISC_INIT_R=y +CONFIG_BOARD_LATE_INIT=y CONFIG_SPL_MAX_SIZE=0x1bfd0 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set CONFIG_SPL_I2C=y +CONFIG_SYS_PROMPT="DS414> " CONFIG_SYS_MAXARGS=32 CONFIG_CMD_I2C=y CONFIG_CMD_PCI=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y -# CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_CMD_TFTPPUT=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_FAT=y CONFIG_CMD_JFFS2=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_UBI=y -CONFIG_ISO_PARTITION=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_SPI_MAX_HZ=50000000 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ARP_TIMEOUT=200 CONFIG_NET_RETRY_COUNT=50 +CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_OF_TRANSLATE=y +CONFIG_LBA48=y +CONFIG_SYS_64BIT_LBA=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y # CONFIG_MMC is not set @@ -83,4 +80,3 @@ CONFIG_USB_XHCI_HCD=y # CONFIG_USB_XHCI_MVEBU is not set CONFIG_USB_XHCI_PCI=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y diff --git a/include/configs/ds414.h b/include/configs/ds414.h index 9446acba79..bbefe632e0 100644 --- a/include/configs/ds414.h +++ b/include/configs/ds414.h @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* + * Copyright (C) 2024 Tony Dinh <mibodhi(a)gmail.com> * Copyright (C) 2014 Stefan Roese <sr(a)denx.de> */ @@ -16,14 +17,9 @@ * U-Boot into it. */ -/* I2C */ #define CFG_I2C_MVTWSI_BASE0 MVEBU_TWSI_BASE -/* - * mv-common.h should be defined after CMD configs since it used them - * to enable certain macros - */ -#include "mv-common.h" +#define PHY_ANEG_TIMEOUT 16000 /* PHY needs a longer aneg time */ /* * Memory layout while starting into the bin_hdr via the @@ -38,23 +34,38 @@ * L2 cache thus cannot be used. */ -/* SPL */ -/* Defines for SPL */ +/* Keep device tree and initrd in lower memory so the kernel can access them */ +#define RELOCATION_LIMITS_ENV_SETTINGS \ + "fdt_high=0x10000000\0" \ + "initrd_high=0x10000000\0" + +/* + * mv-common.h should be defined after CMD configs since it used them + * to enable certain macros + */ +#include "mv-common.h" + +#ifndef CONFIG_SPL_BUILD -/* Default Environment */ +#define KERNEL_ADDR_R __stringify(0x1000000) +#define FDT_ADDR_R __stringify(0x2000000) +#define RAMDISK_ADDR_R __stringify(0x2200000) +#define SCRIPT_ADDR_R __stringify(0x1800000) +#define PXEFILE_ADDR_R __stringify(0x1900000) -#define CFG_EXTRA_ENV_SETTINGS \ - "initrd_high=0xffffffff\0" \ - "ramdisk_addr_r=0x8000000\0" \ - "usb0Mode=host\0usb1Mode=host\0usb2Mode=device\0" \ - "ethmtu=1500\0eth1mtu=1500\0" \ - "update_uboot=sf probe; dhcp; " \ - "mw.b ${loadaddr} 0x0 0xd0000; " \ - "tftpboot ${loadaddr} u-boot-with-spl.kwb; " \ - "sf update ${loadaddr} 0x0 0xd0000\0" +#define LOAD_ADDRESS_ENV_SETTINGS \ + "kernel_addr_r=" KERNEL_ADDR_R "\0" \ + "fdt_addr_r=" FDT_ADDR_R "\0" \ + "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \ + "scriptaddr=" SCRIPT_ADDR_R "\0" \ + "pxefile_addr_r=" PXEFILE_ADDR_R "\0" +#define CFG_EXTRA_ENV_SETTINGS \ + RELOCATION_LIMITS_ENV_SETTINGS \ + LOAD_ADDRESS_ENV_SETTINGS \ + "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ + "console=ttyS0,115200\0" -/* increase autoneg timeout, my NIC sucks */ -#define PHY_ANEG_TIMEOUT 16000 +#endif /* CONFIG_SPL_BUILD */ #endif /* _CONFIG_SYNOLOGY_DS414_H */ -- 2.39.2

2 5

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

11 Jun '24

Changes in v2: - Use generic code by utilizing FS_TYPE_ANY - Change filename from bootcount_ext.c to bootcount_fs.c v1: https://lore.kernel.org/u-boot/20240605181041.68317-1-vassilisamir@gmail.co… 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 | 53 +++++++++++++------ drivers/bootcount/Makefile | 2 +- .../{bootcount_ext.c => bootcount_fs.c} | 12 ++--- 4 files changed, 50 insertions(+), 29 deletions(-) rename drivers/bootcount/{bootcount_ext.c => bootcount_fs.c} (81%) -- 2.25.1

4 13

[PATCH] doc: Fix link reference to general verified boot docs
by Alexander Dahl 11 Jun '24

11 Jun '24

Fixes: ad29e08b79fd ("doc: Bring in FIT signature files") Signed-off-by: Alexander Dahl <ada(a)thorsis.com> --- doc/usage/fit/signature.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst index 03a71b5192d..b868dcbf9fd 100644 --- a/doc/usage/fit/signature.rst +++ b/doc/usage/fit/signature.rst @@ -15,7 +15,7 @@ that it can be verified using a public key later. Provided that the private key is kept secret and the public key is stored in a non-volatile place, any image can be verified in this way. -See verified-boot.txt for more general information on verified boot. +See :doc:`verified-boot` for more general information on verified boot. Concepts base-commit: 1ebd659cf020843fd8e8ef90d85a66941cbab6ec -- 2.39.2

2 1

[PATCH v2 0/4] Generate capsules from config files
by Sughosh Ganu 11 Jun '24

11 Jun '24

Add support for generating capsules through a config file. Multiple capsules can be generated through a single invocation of the mkeficapsule tool, where the capsule parameters are fetched from the config file. The format of the config file pretty similar to the one used by the capsule generation tool in EDKII. The functionality is enabled on the sandbox variant and the EFI capsule update test is now configured to generate the capsules through a config file. The sandbox_flattree variant generates capsules through binman, thus covering both the paths. This is a rebased version of the earlier patch series that was sent to the mailing list [1]. That series was not getting merged as Simon had asked for generation of capsules as part of the sandbox platform build. Those patches have since been merged. Moreover, there has been adoption of the capsule generation logic by TI platforms as well, so that should address the concern which Tom had about it's usage. These patches are more of a step in the direction of adding support for generation of a multi-payload capsule. There has been a request for it's support for a platform [2]. [1] - https://lists.denx.de/pipermail/u-boot/2023-November/538223.html [2] - https://lists.denx.de/pipermail/u-boot/2024-March/548126.html Sughosh Ganu (4): tools: mkeficapsule: Add support for parsing capsule params from config file doc: Document capsule generation through a config file sandbox: capsule: Add a config file for generating capsules test: capsule: Generate capsules through config file configs/sandbox_defconfig | 2 + doc/develop/uefi/uefi.rst | 70 ++++ .../test_efi_capsule/capsule_gen_binman.dts | 2 + test/py/tests/test_efi_capsule/conftest.py | 7 + .../test_efi_capsule/sandbox_capsule_cfg.txt | 73 ++++ tools/Kconfig | 15 + tools/Makefile | 1 + tools/eficapsule.h | 114 ++++++ tools/mkeficapsule.c | 87 +++-- tools/mkeficapsule_parse.c | 352 ++++++++++++++++++ 10 files changed, 692 insertions(+), 31 deletions(-) create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt create mode 100644 tools/mkeficapsule_parse.c -- 2.34.1

3 9

Proposal: U-Boot memory management
by Simon Glass 11 Jun '24

11 Jun '24

Hi, This records my thoughts after a discussion with Ilias & Heinrich re memory allocation in U-Boot. 1. malloc() malloc() is used for programmatic memory allocation. It allows memory to be freed. It is not designed for very large allocations (e.g. a 10MB kernel or 100MB ramdisk). 2. lmb lmb is used for large blocks of memory, such as those needed for a kernel or ramdisk. Allocation is only transitory, for the purposes of loading some images and booting. If the boot fails, then all lmb allocations go away. lmb is set up by getting all available memory and then removing what is used by U-Boot (code, data, malloc() space, etc.) lmb reservations have a few flags so that areas of memory can be provided with attributes There are some corner cases...e.g. loading a file does an lmb allocation but only for the purpose of avoiding a file being loaded over U-Boot code/data. The allocation is dropped immediately after the file is loaded. Within the bootm command, or when using standard boot, this would be fairly easy to solve. Linux has renamed lmb to memblock. We should consider doing the same. 3. EFI EFI has its own memory-allocation tables. Like lmb, EFI is able to deal with large allocations. But via a 'pool' function it can also do smaller allocations similar to malloc(), although each one uses at least 4KB at present. EFI allocations do not go away when a boot fails. With EFI it is possible to add allocations post facto, in which case they are added to the allocation table just as if the memory was allocated with EFI to begin with. The EFI allocations and the lmb allocations use the same memory, so in principle could conflict. EFI allocations are sometimes used to allocate internal U-Boot data as well, if needed by the EFI app. For example, while efi_image_parse() uses malloc(), efi_var_mem.c uses EFI allocations since the code runs in the app context and may need to access the memory after U-Boot has exited. Also efi_smbios.c uses allocate_pages() and then adds a new mapping as well. EFI memory has attributes, including what the memory is used for (to some degree of granularity). See enum efi_memory_type and struct efi_mem_desc. In the latter there are also attribute flags - whether memory is cacheable, etc. EFI also has the x86 idea of 'conventional' memory, meaning (I believe) that below 4GB that isn't reserved for the hardware/system. This is meaningless, or at least confusing, on ARM systems. 4. reservations It is perhaps worth mentioning a fourth method of memory management, where U-Boot reserves chunks of memory before relocation (in board_init_f.c), e.g. for the framebuffer, U-Boot code, the malloc() region, etc. Problems —------- There are no urgent problems, but here are some things that could be improved: 1. EFI should attach most of its data structures to driver model. This work has started, with the partition support, but more effort would help. This would make it easier to see which memory is related to devices and which is separate. 2. Some drivers do EFI reservations today, whether EFI is used for booting or not (e.g. rockchip video rk_vop_probe()). 3. U-Boot doesn't really map arch-specific memory attributes (e.g. armv8's struct mm_region) to EFI ones. 4. EFI duplicates some code from bootm, some of which relates to memory allocation (e.g. FDT fixup). 5. EFI code is used even if EFI is never used to boot 6. EFI allocations can result in the same memory being used as has already been allocated by lmb. Users may load files which overwrite memory allocated by EFI. Lifetime -------- We have three different memory allocators with different purposes. Can we unify them a little? Within U-Boot: - malloc() space lives forever - lmb lives while setting out images for booting - EFI (mostly) lives while booting an EFI app In practice, EFI is set up early in U-Boot. Some of this is necessary, some not. EFI allocations stay around forever. This works OK since large allocations are normally not done in EFI, so memory isn't really consumed to any great degree by the boot process. What happens to EFI allocations if the app returns? They are still present, in case another app is run. This seems fine. API –-- Can we unify some APIs? It should be possible to use lmb for large EFI memory allocations, so long as they are only needed for booting. We effectively do this today, since EFI does not manage the arrangement of loaded images in memory. for the most part. It would not make sense to use EFI allocation to replace lmb and malloc(), of course. Could we use a common (lower-level) API for allocation, used by both lmb and EFI? They do have some similarities. However they have different lifetime constraints (EFI allocations are never dropped, unlikely lmb). ** Overall, it seems that the existence of memory allocation in boot-time services has created confusion. Memory allocation is muddled, with both U-Boot code and boot-time services calling the same memory allocator. This just has not been clearly thought out. Proposal —------- Here are some ideas: 1. For video, use the driver model API to locate the video regions, or block off the entire framebuffer memory, for all devices as a whole. Use efi_add_memory_map() 2. Add memory attributes to UCLASS_RAM and use them in EFI, mapping to the EFI_MEMORY_... attributes in struct efi_mem_desc. 3. Add all EFI reservations just before booting the app, as we do with devicetree fixup. With this model, malloc() and lmb are used for all allocation. Then efi_add_memory_map() is called for each region in turn just before booting. Memory attributes are dealt with above. The type (enum efi_memory_type) can be determined simply by the data structure stored in it, as is done today. For example, SMBIOS tables can use EFI_ACPI_RECLAIM_MEMORY. Very few types are used and EFI code understands the meaning of each. 4. Avoid setting up EFI memory at the start of U-Boot. Do it only when booting. This looks to require very little effort. 5. Avoid calling efi_allocate_pages() and efi_allocate_pool() outside boot-time services. This solves the problem 6. If memory is needed by an app, allocate it with malloc() and see 3. There are only two efi_allocate_pages() (smbios and efi_runtime). There are more calls of efi_allocate_pool(), but most of these seem easy to fix up. For example, efi_init_event_log() allocates a buffer, but this can be allocated in normal malloc() space or in a bloblist. 6. Don't worry too much about whether EFI will be used for booting. The cost is likely not that great: use bootstage to measure it as is done for driver model. Try to minmise the cost of its tables, particularly for execution time, but otherwise just rely on the ability to disable EFI_LOADER. – Regards, Simon

6 51

[PATCH 0/4] alist: Implement a pointer list / array of structs
by Simon Glass 11 Jun '24

11 Jun '24

This data structure provides a list of pointers / array of structures. I was planning to use it for the lmb restructure, to allow it to support any number of entries, but then I gave up on it. There are quite a few places in U-Boot where such a list would be useful, since it supports growing the array. The series includes a patch to convert an existing function to use this. It adds a little under 300 bytes of code with Thumb2. Example: struct my_struct obj; struct my_struct *ptr = alist_add(&lst, &obj, struct my_struct); // now ptr is in the list [1] https://patchwork.ozlabs.org/project/uboot/list/?series=371258&state=* Simon Glass (4): malloc: Support testing with realloc() lib: Handle a special case with str_to_list() alist: Add support for an allocated pointer list lib: Convert str_to_list() to use alist common/dlmalloc.c | 4 + include/alist.h | 205 ++++++++++++++++++++++++++++++++++++++++++++++ lib/Makefile | 1 + lib/alist.c | 154 ++++++++++++++++++++++++++++++++++ lib/strto.c | 33 ++++---- test/lib/Makefile | 1 + test/lib/alist.c | 197 ++++++++++++++++++++++++++++++++++++++++++++ test/str_ut.c | 4 +- 8 files changed, 582 insertions(+), 17 deletions(-) create mode 100644 include/alist.h create mode 100644 lib/alist.c create mode 100644 test/lib/alist.c -- 2.34.1

1 4

[NEXT] Pull request efi-next-20240611
by Heinrich Schuchardt 11 Jun '24

11 Jun '24

Dear Tom, This pull request is for the next branch. The following changes since commit 4f836fb324ba500ecabdba4146c3ca9e1600cdf5: memory: ti-gpmc: use printf to dump settings/timings (2024-06-07 14:07:23 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-next-20240611 for you to fetch changes up to 535321c2ea76de44896330040d2e43aa4645d026: efi_loader: rename struct efi_initrd_dp to efi_lo_dp_prefix (2024-06-10 11:43:37 +0200) Gitlab CI reported no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/21059 ---------------------------------------------------------------- Pull request efi-next-20240611 UEFI: * Allow specifying a device-tree in an EFI load option using the efidebug or eficonfig command. * Let the EFI boot manager fall back to an OS provided device-tree if no device-tree is specified. ---------------------------------------------------------------- Heinrich Schuchardt (9): efi_loader: allow concatenation with contained end node cmd: eficonfig: add support for setting fdt cmd: efidebug: add support for setting fdt efi_loader: load device-tree specified in boot option efi_loader: move distro_efi_get_fdt_name() efi_loader: return binary from efi_dp_from_lo() efi_loader: export efi_load_image_from_path efi_loader: load distro dtb in bootmgr efi_loader: rename struct efi_initrd_dp to efi_lo_dp_prefix boot/bootmeth_efi.c | 60 +------------- cmd/eficonfig.c | 83 ++++++++++++++----- cmd/efidebug.c | 129 ++++++++++++++++++++--------- include/efi_load_initrd.h | 12 ++- include/efi_loader.h | 24 +++++- lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_bootbin.c | 2 +- lib/efi_loader/efi_bootmgr.c | 81 +++++++++++++++++- lib/efi_loader/efi_boottime.c | 3 +- lib/efi_loader/efi_device_path.c | 40 +++++---- lib/efi_loader/efi_device_path_utilities.c | 2 +- lib/efi_loader/efi_fdt.c | 117 ++++++++++++++++++++++++++ lib/efi_loader/efi_helper.c | 44 ++++++++++ lib/efi_loader/efi_load_initrd.c | 2 +- lib/efi_loader/initrddump.c | 2 +- 15 files changed, 463 insertions(+), 139 deletions(-) create mode 100644 lib/efi_loader/efi_fdt.c

2 1

Debugging gpio-hogs which don't get probed
by Chris Webb 11 Jun '24

11 Jun '24

I'm building u-boot for a mt7981a board, very similar to the in-tree mt7981-emmc-rfb. For reference, my device tree and output of make savedefconfig are here: https://gist.github.com/arachsys/98048980728c652bea641b42cfd41a40 Everything boots fine, but I have a handful of gpios which need to be set to fixed values before booting the kernel to enable a 5g modem. I can do this with gpio clear 10; gpio set 5; gpio set 9; gpio 11 which works fine, but I think the 'official' solution for this might be using u-boot's gpio-hog support? With that in mind, I added &gpio { hub_power { gpio-hog; gpios = <5 GPIO_ACTIVE_HIGH>; output-high; }; modem_control { gpio-hog; gpios = <9 GPIO_ACTIVE_HIGH>; output-high; }; modem_reset { gpio-hog; gpios = <10 GPIO_ACTIVE_HIGH>; output-low; }; modem_power { gpio-hog; gpios = <11 GPIO_ACTIVE_HIGH>; output-high; }; }; with CONFIG_GPIO_HOG=y, but this doesn't seem to work on either u-boot.git HEAD or 2024.07-rc. To try to see what was going on better, I added some debug printfs: --- a/u-boot/drivers/gpio/gpio-uclass.c +++ b/u-boot/drivers/gpio/gpio-uclass.c @@ -328,6 +330,8 @@ static int gpio_hog_of_to_plat(struct udevice *dev) static int gpio_hog_probe(struct udevice *dev) { + printf("gpio_hog_probe called\n"); + struct gpio_hog_data *plat = dev_get_plat(dev); struct gpio_hog_priv *priv = dev_get_priv(dev); int ret; @@ -1518,6 +1523,8 @@ void devm_gpiod_put(struct udevice *dev, struct gpio_desc *desc) static int gpio_post_bind(struct udevice *dev) { + printf("gpio_post_bind called\n"); + if (CONFIG_IS_ENABLED(GPIO_HOG) && dev_has_ofnode(dev)) { struct udevice *child; ofnode node; @@ -1539,6 +1546,7 @@ static int gpio_post_bind(struct udevice *dev) * since hogs can be essential to the hardware * system. */ + printf("found a gpio-hog\n"); dev_or_flags(child, DM_FLAG_PROBE_AFTER_BIND); } } This shows gpio_post_bind being called, then the four gpio-hogs found and set to probe after bind, but the gpio_hog_probe function is never actually called. Presumably this is the problem - if they're not probed then they'll never take effect? I enabled CONFIG_DM_WARN and CONFIG_DM_DEBUG, which confirm that nothing ever seems to be probing the gpio-hog children, but there aren't obviously any errors or warnings related to them either. Nothing relevant happens after gpio_post_bind is called. Is this a bug or is there some basic config/dts mistake on my part here? Is there some other debug info I can get that might shed light on what's going on, or some config prerequisite for DM_FLAG_PROBE_AFTER_BIND to work that I'm likely to be missing? Best wishes, Chris.

1 1

[PATCH 0/7] MIPS: Enable EFI support
by Jiaxun Yang 11 Jun '24

11 Jun '24

Hi all, This series enabled EFI support to MIPS platform. Although MIPS is not defined by UEFI specification, there are quite a few firmware implementations available, including MIPS-EFI[1] for Loongson-2F, Lemote's proprietary EDK2 implementation on Loongson-3[2], Kunlun firmware for Loongson-3[3], efiffy[4] for MIPS Creator CI20 and another mystery EDK implementation shipped with some Creator CI20 board. Available applications including gnu-efi, Loongson's GRUB fork[5], Ventoy[6]. My implementation in U-Boot is aiming to follow conventions made by other implementations for architecture stuff and remain compliance with spec for general aspects. bootefi hello and selftest passed on both 32 and 64 bit system, gnu-efi, grub and ventoy are tested on mips64el with my pending platform works. mips32el efi executable from efiffy is tested as well. Please review. Thanks [1]: https://github.com/kontais/EFI-MIPS [2]: https://github.com/loongson-community/firmware-nonfree [3]: http://www.kunluntech.com.cn/klbiosxl [4]: https://sourceforge.net/projects/efify/ [5]: https://github.com/loongson-community/grub [6]: https://www.ventoy.net/en/index.html Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Jiaxun Yang (7): MIPS: Implement setjmp efi: Allow runtime relocate to be disabled Makefile.lib: Preserve .rodata section for EFI file Makefile.lib: Enforce EFI CFLAGS/AFLAGS MIPS: Add smbios_start to arch_global_data MIPS: Define MIPS EFI related bits everywhere MIPS: Implement EFI supporting stuff Makefile | 3 + arch/mips/config.mk | 9 + arch/mips/include/asm/global_data.h | 3 + arch/mips/include/asm/setjmp.h | 36 ++++ arch/mips/lib/Makefile | 15 ++ arch/mips/lib/crt0_mips_efi.S | 239 ++++++++++++++++++++++ arch/mips/lib/elf_mips_efi.lds | 113 ++++++++++ arch/mips/lib/reloc_mips_efi.c | 99 +++++++++ arch/mips/lib/setjmp32.S | 51 +++++ arch/mips/lib/setjmp64.S | 56 +++++ include/asm-generic/pe.h | 5 + include/config_distro_bootcmd.h | 6 + include/efi_default_filename.h | 8 + include/efi_loader.h | 26 ++- include/elf.h | 8 + lib/efi_loader/Kconfig | 12 +- lib/efi_loader/efi_image_loader.c | 18 ++ lib/efi_loader/efi_memory.c | 14 +- lib/efi_loader/efi_runtime.c | 11 +- lib/efi_loader/efi_var_mem.c | 6 +- lib/efi_selftest/Makefile | 2 +- lib/efi_selftest/efi_selftest_miniapp_exception.c | 2 + scripts/Makefile.lib | 10 +- 23 files changed, 734 insertions(+), 18 deletions(-) --- base-commit: ad7dce5abd49ef3b5c93da5303e15449c8c162b4 change-id: 20240517-mips-efi-c9a1ad819c2d Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

4 27

[PATCH 00/13] Arm64 big endian enablement
by Jiaxun Yang 11 Jun '24

11 Jun '24

Hi all, This series enabled big endian support for arm64, enabled qemu-arm board for arm64be and slightly adjusted our Kconfig handling on endianness. In practical I think most Arm SoCs do support little endian only, for those SoCs with big endian support they are usually bi-endian and expected bootloader in little endian. The only big-endian only Arm SoC I know is a network processor from ZTE ZXIC, I doubt if upstream U-Boot will ever support it. However enabling arm64be can enable us to take more care on big endian targets, given that arm64 is the most feature rich arch in U-Boot, we can run more test on big endian systems. Boot tested on qemu. Please review. Thanks Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- Jiaxun Yang (13): tools/relocate-rela: Fix Big Endian elf64 handling arm: Don't select ARM_ASM_UNIFIED on arm64 arm: Fix assembler.h for arm64 arm: Introduce CPU_LE/CPU_BE macros arm: Define endian related bits in system.h armv8: Big Endian enablement for compiler and linker arm: Perform byte swap for read and write in io.h armv8: Allow endianness to be setted at reset entry armv8: spin_table: Perform byte swap for jump address lib/crc32: Don't perform byte swap for arm64 crc32b Kconfig: Unify endian support option config: Use CONFIG_SYS_BIG_ENDIAN in code whenever possible qemu-arm: Big endian enablement for arm64 Makefile | 2 +- arch/Kconfig | 34 ++++++++--- arch/arc/include/asm/arc-bcr.h | 10 +-- arch/arm/Kconfig | 3 +- arch/arm/config.mk | 14 +++++ arch/arm/cpu/armv8/Kconfig | 9 +++ .../arm/cpu/armv8/linux-kernel-image-header-vars.h | 4 +- arch/arm/cpu/armv8/spin_table_v8.S | 2 + arch/arm/cpu/armv8/start.S | 26 ++++++++ arch/arm/cpu/armv8/u-boot-spl.lds | 6 ++ arch/arm/cpu/armv8/u-boot.lds | 4 ++ arch/arm/include/asm/assembler.h | 25 ++++++++ arch/arm/include/asm/io.h | 12 ++-- arch/arm/include/asm/system.h | 3 + arch/arm/lib/elf_aarch64_efi.lds | 7 +++ arch/mips/Kconfig | 20 +++--- arch/mips/mach-ath79/Kconfig | 8 +-- arch/mips/mach-bmips/Kconfig | 20 +++--- arch/mips/mach-jz47xx/Kconfig | 2 +- arch/mips/mach-mscc/Kconfig | 4 +- arch/mips/mach-pic32/Kconfig | 2 +- board/emulation/qemu-arm/Kconfig | 2 + board/emulation/qemu-arm/MAINTAINERS | 1 + configs/qemu_arm64be_defconfig | 71 ++++++++++++++++++++++ doc/board/emulation/qemu-arm.rst | 7 ++- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 2 +- lib/crc32.c | 3 +- scripts/Makefile.build | 2 +- scripts/Makefile.lib | 3 +- tools/relocate-rela.c | 40 +++++++----- 30 files changed, 271 insertions(+), 77 deletions(-) --- base-commit: 3be9f399e911cfc437a37ac826441f1d96da1c9b change-id: 20240518-aarch64-be-1ec99cf7f28b Best regards, -- Jiaxun Yang <jiaxun.yang(a)flygoat.com>

2 14