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

[Quentin Schulz]

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

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