[PATCH v3 4/6] rockchip: find U-boot proper boot device by inverting the logic that sets it

[Tom Rini]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240122/843f6320/attachment.sig>