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. -- Tom
signature.asc
Description: PGP signature