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

[Jonas Karlman]

Hi Quentin,

On 8/11/2025 11:49 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).
> 
> I would refrain from adding partial support for it then.

Sure, I will remove anything related to sfc1 M0 in v3.

> 
>> - 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>;
>> +		};
>> +	};
>> +};
>> +#endif
>> +
>>   &cru {
>>   	bootph-all;
>>   };
>> @@ -45,6 +61,16 @@
>>   	bootph-some-ram;
>>   };
>>   
>> +&fspi0_csn0 {
>> +	bootph-pre-ram;
>> +	bootph-some-ram;
>> +};
>> +
>> +&fspi0_pins {
>> +	bootph-pre-ram;
>> +	bootph-some-ram;
>> +};
>> +
>>   &ioc_grf {
>>   	bootph-all;
>>   };
>> @@ -116,6 +142,16 @@
>>   	bootph-some-ram;
>>   };
>>   
>> +&sfc0 {
>> +	bootph-some-ram;
>> +	u-boot,spl-sfc-no-dma;
>> +};
>> +
>> +&sfc1 {
>> +	bootph-some-ram;
>> +	u-boot,spl-sfc-no-dma;
>> +};
>> +
>>   &sys_grf {
>>   	bootph-all;
>>   };
>> diff --git a/arch/arm/mach-rockchip/rk3576/rk3576.c b/arch/arm/mach-rockchip/rk3576/rk3576.c
>> index a6c2fbdc4840..3d5bdeeeb846 100644
>> --- a/arch/arm/mach-rockchip/rk3576/rk3576.c
>> +++ b/arch/arm/mach-rockchip/rk3576/rk3576.c
>> @@ -36,8 +36,17 @@
>>   #define USB_GRF_BASE		0x2601E000
>>   #define USB3OTG0_CON1		0x0030
>>   
>> +enum {
>> +	BROM_BOOTSOURCE_FSPI0 = 3,
>> +	BROM_BOOTSOURCE_FSPI1_M0 = 4,
>> +	BROM_BOOTSOURCE_FSPI1_M1 = 6,
>> +};
>> +
>>   const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
>>   	[BROM_BOOTSOURCE_EMMC] = "/soc/mmc at 2a330000",
>> +	[BROM_BOOTSOURCE_FSPI0] = "/soc/spi at 2a340000/flash at 0",
>> +	[BROM_BOOTSOURCE_FSPI1_M0] = "/soc/spi at 2a300000/flash at 0",
> 
> This in addition to BROM_BOOTSOURCE_FSPI1_M0 in the enum may mislead the 
> user into believing it is supported whereas we most likely need to do 
> another mapping in read_brom_bootsource_id() below, so I would just not 
> add either to this patch.

You are correct, this will most likely not work as-is, I re-used the SPI
NAND value for fspi1 M0, as it may not be used for anything. 6 is the
only unused/unknown value, 7 is used for UFS as indicated by vendor tree.

Will drop FSPI1_M0 from v3.

> 
>> +	[BROM_BOOTSOURCE_FSPI1_M1] = "/soc/spi at 2a300000/flash at 0",
>>   	[BROM_BOOTSOURCE_SD] = "/soc/mmc at 2a310000",
>>   };
>>   
>> @@ -85,6 +94,20 @@ void board_debug_uart_init(void)
>>   {
>>   }
>>   
>> +u32 read_brom_bootsource_id(void)
>> +{
>> +	u32 bootsource_id = readl(BROM_BOOTSOURCE_ID_ADDR);
>> +
>> +	if (bootsource_id == 0x23)
>> +		return BROM_BOOTSOURCE_FSPI1_M1;
>> +	else if (bootsource_id == 0x81)
>> +		return BROM_BOOTSOURCE_USB;
> 
> I believe this differs from what we've done for all other SoCs where we 
> have an entry at the offset bootsource_id in the boot_devices array.
> 
> On RK3588 it seems we're doing something similar of defining new 
> BROM_BOOTSOURCE_ values in another enum and using them in the 
> boot_devices array as indices. However, it seems we're using them 
> verbatim instead of doing the mapping like we do here in rk3576.c. The 
> only reason I could think of that is that 0x81 would create a pretty big 
> array for no specific reason. Considering we already have an entry for 
> the exact same scenario with a different number, I feel like it's fair 
> to do the mapping.
> 
> It would be nice at least to provide some information on why it's done 
> this way since it differs from what we've done until now. Especially 
> that the enum doesn't match the raw value from the register anymore.

Yes, the table size was the only reason for using a different type
re-mapping here, for rk3588 the actual raw values changed meaning so
using a new enum worked fine. For rk3576 the values changes completely,
and vendor U-Boot does not give any hint, so re-mapping known values
seem least intrusive until more details are uncovered.

I will add comment about reson for re-mapping in v3.

Maybe @Kever have some insights in how boot source id is encoded by the
boot-rom for rk3576?

Regards,
Jonas

> 
> Cheers,
> Quentin