[PATCH] rockchip: spl-boot-order: Defer probe of boot device

[Quentin Schulz]

Hi Jonas,

On 7/15/25 5:22 PM, Jonas Karlman wrote:
> Hi Quentin,
> 
> On 7/15/2025 3:11 PM, Quentin Schulz wrote:
>> Hi Jonas,
>>
>> On 7/15/25 11:36 AM, Jonas Karlman wrote:
>>> Hi Quentin,
>>>
>>> On 7/15/2025 11:07 AM, Quentin Schulz wrote:
>>>> Hi Jonas,
>>>>
>>>> On 7/12/25 11:12 PM, Jonas Karlman wrote:
>>>>> Boot devices are being probed when SPL boot order is determined. This
>>>>> may delay boot slightly and can prevent booting from SPI Flash on boards
>>>>> that use same pins for SPI Flash and eMMC due to pinctrl being applied
>>>>> prior to booting.
>>>>>
>>>>
>>>> How would that be possible? One cannot have the same pins used for SPI
>>>> flash and eMMC at the same time? So that would be an issue in the DT or
>>>> a misconfigured DT for the board?
>>>
>>> Correct, basically there are SoCs, RK3576 and RK3588S comes to mind,
>>> that share/mux pins for FSPI and EMMC. And some devices with those SoCs
>>> have options to mount a SPI flash or eMMC module using same connector.
>>>
>>> E.g. Radxa has a SPI flash module for ROCK 5A/5C that can be mounted on
>>> the eMMC connector. And ROCK 4D has a shared eMMC/UFS connector with a
>>> SPI flash mounted onboard (in some configurations).
>>>
>>> When I tried to boot from SPI flash on my ROCK 4D and was trying to
>>> describe the eMMC module, SPL would instead first probe the SPI flash
>>> module and apply the pinctrl for FSPI func, and then when it tries to
>>> lookup more boot options, it instead probed the sdhci controller and
>>> applied pinctrl for emmc so loading FIT from SPI flash then failed.
>>>
>>
>> Yeah... but that's an invalid DT you just used, no? SPI flash AND eMMC
>> cannot be used at the same time? So we should either have SPI flash or
>> eMMC enabled in the DT and not both? Or are you planning on supporting
>> booting from SPI flash entirely and then somehow have proper load stuff
>> from the eMMC and not SPI flash or something?
> 
> Something like that, some scenarios I envision for future:
> a) an eMMC module is mounted and BROM report eMMC as bootsource.
> b) a SPI flash module is mounted and BROM report SPINOR as bootsource.
> 

Seems fine if the system is booting from the eMMC or SPI flash, gets 
more difficult if it doesn't as we'll not be able to rely on the BootROM 
to tell us what's populated.

> For now only scenario a) is possible on ROCK 5A/5C, because the sdhci is
> currently enabled in the FDT that would be loaded in next boot phase.
> 
> For scenario b) a DTBO or an alternative FDT config in FIT can be
> selected that disabled sdhci and instead enable SPI flash controller.
> 
> Main reason to support something like this will be to use the cheap SPI
> flash module for bootloader and use NVMe for storage without requiring
> a special DT or build of U-Boot.
> 

Makes sense, it just makes things difficult when not booting from this 
external module (e.g. via an SD card) to know if there's any external 
module plugged in and if so, which one. I would assume the plan is also 
to patch the kernel DTB to support whatever is plugged there but not 
necessarily force booting U-Boot from it (though this can be done later 
on I guess :) ).

>>
>>> With probe and thus apply of pinctrl happening later when images are
>>> loaded we should be able to create a single boot image that dynamically
>>> can apply correct FDT/DTBO depending if it was booted from SPI flash or
>>> eMMC. Or for the ROCK 4D case (can only boot from FSPI->UFS->USB) being
>>> able to boot from SPI flash and then switch to use eMMC for storage.
>>>
>>
>> I see... So the point would be to have a DTBO with pluggable eMMC which
>> disables the SPI flash and another one with pluggable UFS flash and load
>> the appropriate one based on the boot medium used by the BootROM to load
>> the TPL? This however makes a fallback impossible (e.g. booting from
>> SD/SPI flash so we don't know whether UFS, eMMC or no pluggable storage
>> medium is provided, no or corrupted proper on SD/SPI flash, how to know
>> which next storage to try?).
> 
> Correct, for the ROCK 5A/5C their DT currently enable sdhci controller
> because this is the most likely use-case. However if the user use a SPI
> flash module instead of the eMMC module (same connector), runtime could
> determine this and use special FDT or apply an DTBO as you cannot mount
> both a SPI flash and eMMC module at the same time.
> 

If booted from that medium, the BootROM would give us the information so 
yes it's fine. If not, we need to attempt autodetection I guess to 
figure if and what is connected there.

> If I am not mistaken vendor u-boot may already do something to this
> effect, try to identify SPI flash and load a special FDT in such case.
> 
> Such feature would only be board specific, and possible may require a
> special boot only DT for SPL, something to investigate in future.
> 

And likely two different DTs one for eMMC and one for SPI?

>>
>> Maybe we would need to tentatively apply pluggable eMMC DTBO, try to
>> probe, remove the drivers, apply pluggable UFS DTBO, try to probe,
>> remove the drivers, etc... Seems very complex though :/
>>
>>> Something to investigate more in a follow up series.
>>>
>>
>> Have fun :)
> 
> Hehe, I do not think it needs to be that complex, but this idea could
> very likely also never amount to anything :-)
> 
>>
>> Don't we need to describe the eMMC (sdhci) controller with the pinmux
>> for SPL to be able to load proper from it? Which would conflict with the
>> one from the eMMC controller's? This all seems to be due to some WIP
>> state, bring-up of Rock 4D and odd HW configurations rather than stuff
>> we should support in the long run?
> 
> The ROCK 4D variant I have come with onboard SPI flash and a UFS module
> mount. I think there may be future variants without SPI flash that
> instead can support use of an eMMC module.
> 

The product page hints at supporting the typical Radxa eMMC module but 
not at the same time as the on-board SPI flash, are you expecting they 
will have a 4D variant without an on-board SPI flash at all?

> Current board variant that have an onboard SPI flash also configure BROM
> to use FSPI->UFS->USB boot order (or USB when MSAK-button is pressed).
> These models cannot be booted directly from a SD-card (or eMMC).
> 

Interesting design decision.

>>
>> I'm still a bit confused by what the plan for 4D and the additional
>> pluggable storage medium are, do you have anything in mind?
> 
> With my current ROCK 4D series only SPI flash boot is supported. UFS
> boot support would be interesting but I have no current plans to look
> into that. Fallback to read FIT from SD-card should also be supported.
> 

Would be, but if you cannot boot from the SD card at all, I'm not sure 
it's that big of a deal? You would only be able to store proper on the 
SD card then (better than nothing I guess, but still odd).

> Trying to boot from SPI flash and then later switch to eMMC was just
> something I was entertaining as an interesting idea, mostly because I
> had no UFS module until one was delivered earlier today ;-)
> 
>>
>> With my current understanding, I would say that we simply should remove
>> the part about preventing to boot from other storage medium as that is
>> the result of some WIP state that shouldn't make it to upstream U-Boot?
>> We can describe the current limitations in the documentation if you want.
> 
> I can try to simplify the commit message in a v2.
> 

That'd be great thanks.

Cheers,
Quentin