On Mon, Jan 22, 2024 at 11:49:23AM +0100, Quentin Schulz wrote:
Hi Kever,
On 1/18/24 11:12, Kever Yang wrote:
Hi Quentin,
On 2024/1/18 01:22, Quentin Schulz wrote:
From: Quentin Schulz quentin.schulz@theobroma-systems.com
BOOT_DEVICE_* is set by spl_node_to_boot_device() depending on the block device number associated with the MMC device the SPL used to load U-Boot proper from. It is NOT related to the mmc alias in the Device Tree.
For SPI flashes, all SPI flashes will return BOOT_DEVICE_SPI so there's currently no way to know from which one the SPL loaded U-Boot proper from. Therefore, let's just find the first valid candidate in /chosen/u-boot,spl-boot-order that is a SPI flash and return that path. This is a best effort.
While the original implementation may have worked, using the exact same mechanism but in inverted fashion makes it less likely to have surprising corner-cases or side-effects.
A nice side-effect is that all existing and future Rockchip SoCs now automatically have their /chosen/u-boot,spl-boot-device set.
Error happen in some 32bit SoC:
+arch/arm/mach-rockchip/spl-boot-order.c: In function 'spl_perform_fixups': +arch/arm/mach-rockchip/spl-boot-order.c:242:31: error: 'struct spl_image_info' has no member named 'fdt_addr' + 242 | void *blob = spl_image->fdt_addr; + | ^~ +make[3]: *** [scripts/Makefile.build:257: spl/arch/arm/mach-rockchip/spl-boot-order.o] Error 1
It'd be nice to say **which** boards aren't working so that I can reproduce locally :)
I eventually figured we have GitLab CI/CD for your maintainer branch/repo here: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines. This also helped me figure out this wasn't the only build failure and I could send another patch before you had the opportunity to tell me I had broken something else :)
Giving the link of the failed pipeline would really help, please think about it for next time :) Thanks!
For people interested in build-testing all Rockchip platforms locally, I used the following script:
Please note that you can also build all of the rockchip platforms locally with: tools/buildman/buildman --allow-missing rk rv
It won't be bootable as it will fake all require blobs, but all platforms will be built. And buildman can be told a number of things to be built, but "rockchip" only catches the cases where the board vendor is "rockhip" rather than ARCH_ROCKCHIP, but "rk" and "rv" catch all of the rkXXXX and rvXXXX SoCs.