Hi Tom,
On 1/22/24 18:54, Tom Rini wrote:
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.
Ack, will be trying this one out, thanks for the heads up.
FYI, it was also missing "px30" among the terms to pass to buildman. Now I get 101 boards, the same as with my script :)
Cheers, Quentin