[PATCH v2 3/4] rockchip: rk3576: Add SPI Flash boot support

[Quentin Schulz]

Hi Jonas,

On 8/12/25 12:02 AM, Jonas Karlman wrote:
> Hi Quentin,
> 
> On 8/11/2025 11:59 AM, Quentin Schulz wrote:
>> Hi Jonas,
>>
>> On 8/1/25 11:06 PM, Jonas Karlman wrote:
>>> The bootsource ids reported by BootROM of RK3576 for SPI NOR and USB
>>> differs slightly compared to prior SoCs:
>>>
>>> - Booting from sfc0 (ROCK 4D) report the normal bootsource id 0x3.
>>> - Booting from sfc1 M1 (NanoPi M5) report a new bootsource id 0x23.
>>> - Booting from sfc1 M0 has not been tested (no board using this config).
>>> - Booting from USB report a new bootsource id 0x81.
>>>
>>> Add a RK3576 specific read_brom_bootsource_id() function to help decode
>>> the new bootsource id values and the required boot_devices mapping of
>>> sfc0 and sfc1 to help support booting from SPI flash on RK3576.
>>>
>>> Signed-off-by: Jonas Karlman <jonas at kwiboo.se>
>>> ---
>>> v2: No change
>>> ---
>>>    arch/arm/dts/rk3576-u-boot.dtsi        | 36 ++++++++++++++++++++++++++
>>>    arch/arm/mach-rockchip/rk3576/rk3576.c | 23 ++++++++++++++++
>>>    2 files changed, 59 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/rk3576-u-boot.dtsi b/arch/arm/dts/rk3576-u-boot.dtsi
>>> index fb5a107f47d9..c7ed09e03eec 100644
>>> --- a/arch/arm/dts/rk3576-u-boot.dtsi
>>> +++ b/arch/arm/dts/rk3576-u-boot.dtsi
>>> @@ -6,6 +6,11 @@
>>>    #include "rockchip-u-boot.dtsi"
>>>    
>>>    / {
>>> +	aliases {
>>> +		spi5 = &sfc0;
>>> +		spi6 = &sfc1;
>>> +	};
>>> +
>>>    	chosen {
>>>    		u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
>>>    	};
>>> @@ -16,6 +21,17 @@
>>>    	};
>>>    };
>>>    
>>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>>> +&binman {
>>> +	simple-bin-spi {
>>> +		mkimage {
>>> +			args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
>>> +			offset = <0x8000>;
>>
>> Is this a requirement of the SoC or just a default?
>>
>> E.g. on my RK3399 I can flash at offset 0 u-boot-rockchip-spi.bin and
>> it'll happily boot. Is it still the same on RK3576 but you preferred to
>> have a similar offset than for eMMC/SD (and/or have space to store a
>> partition table before?)
> 
> Not sure if I ever tested using offset 0 for rk3576, will do before v3.
> 
> If I remember correctly the rk356x/rk3588 (and/or others SoCs) would not
> boot when using offset 0, so I probably only tested the 32 KiB offset

Possibly, I only own one board with a bootable SPI, my old RK3399 Puma 
so that's about the sample size I can get :)

> that is known working for other rk35xx SoCs. And on RK3326 (probably
> also PX30) a 64 KiB offset resulted in working boot from SPI flash.
> 

IIRC, I mistakenly flashed on 32KiB offset for RK3399 as well and it 
booted (the SPL, then it broke because it's so much space constrained on 
RK3399 Puma that I cannot afford the 32KiB offset).

I guess this could also be something we could have as default. If you 
want a different offset, then you can update it in your board 
-u-boot.dtsi (or have a Kconfig symbol, but IIRC we don't have one for 
MMC so why have one for SPI only?).

>>
>>> +		};
>>> +	};
>>> +};
>>> +#endif
>>
>> Not a blocker for this patch but I think it would make sense to invert
>> the logic globally now so that we don't need to have to do this for
>> every new Rockchip SoC we'll support.
>>
>> Have -T rksd in rockchip-u-boot.dtsi and all SoCs that have an SPI
>> controller and do not override this property would have -T rkspi set in
>> their SoC DTSI, e.g. rk3399-u-boot.dtsi would now get
>>
>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>> +&binman {
>> +	simple-bin-spi {
>> +		mkimage {
>> +			args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
>> +		};
>> +	};
>> +};
>> +#endif
> 
> I fully agree, there is now a minority using the special rkspi format so
> a flip to have rksd (and possible also the 32 KiB offset) in
> rockchip-u-boot.dtsi is a very good idea for a future series.
> 
>  From a quick grep maybe only rk3288 and rk3399 may need this special
> rkspi format? Probably also some older SoCs, not sure we really support
> building working SPI flash images for such older SoCs anyway.
> 

What we can start with is doing a flip which results in the exact same 
binary before and after the flip. Then whichever SoC doesn't actually 
need the rkspi trick can disable it on the SoC level I guess in a later 
patch?

Cheers,
Quentin