Hi Quentin,
On 8/12/2025 10:02 AM, Quentin Schulz wrote:
> 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 <jo...@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 did a quick test of using offset 0 of SPI flash on ROCK 4D and it
booted fine, will however keep the 32 KiB offset in v3 to use consistent
offset with the other RK35xx SoCs/boards.
>
> 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?).
Agree, possible adding use of a Kconfig symbol for offsets could be
something for a future follow-up series.
>
>>>
>>>> + };
>>>> + };
>>>> +};
>>>> +#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?
I think this make sense, and something for a future series :-)
Regards,
Jonas
>
> Cheers,
> Quentin
