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.sch...@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
