[PATCH v2 2/3] rockchip: make rksd the default format for SPI images
Jonas Karlman
jonas at kwiboo.se
Tue Dec 16 18:57:15 CET 2025
Hi Quentin,
On 12/16/2025 5:35 PM, Quentin Schulz wrote:
> Hi Jonas,
>
> On 12/16/25 5:11 PM, Jonas Karlman wrote:
>> Hi Quentin,
>>
>> On 12/16/2025 12:26 PM, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz at cherry.de>
>>>
>>> I believe (hope) that the new SoCs should now have this fixed and not
>>> require the "hack" implemented in rkspi format which almost doubles the
>>> size of TPL+SPL (idbloader.img).
>>>
>>> It's known to be fixed on RK3566/RK3568, RK3576 and RK3588(S) (according
>>> to the DTS setting the mkimage format for the SPI's idbloader.img to
>>> rksd explicitly).
>>>
>>> Since I do not have any board with a bootable SPI flash except on RK3399
>>> where this work-around is required, I simply invert the logic by having
>>> rkspi explicitly set for all SoCs that didn't and remove rksd from SoCs
>>> that did. It doesn't mean that the SoC actually requires rkspi format,
>>> just that it's been the case until now (maybe because nobody tested).
>>>
>>> Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
>>> ---
>>> arch/arm/dts/px30-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk3036-u-boot.dtsi | 13 +++++++++++++
>>> arch/arm/dts/rk3066a-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk3128-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk3188-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk322x-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk3288-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk3308-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk3326-u-boot.dtsi | 1 -
>>> arch/arm/dts/rk3328-u-boot.dtsi | 1 -
>>> arch/arm/dts/rk3368-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk3399-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk3528-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rk356x-u-boot.dtsi | 1 -
>>> arch/arm/dts/rk3576-u-boot.dtsi | 1 -
>>> arch/arm/dts/rk3588s-u-boot.dtsi | 1 -
>>> arch/arm/dts/rockchip-u-boot.dtsi | 1 -
>>> arch/arm/dts/rv1108-u-boot.dtsi | 12 ++++++++++++
>>> arch/arm/dts/rv1126-u-boot.dtsi | 12 ++++++++++++
>>> 19 files changed, 157 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/dts/px30-u-boot.dtsi b/arch/arm/dts/px30-u-boot.dtsi
>>> index 2f726b0aaba..7385de7d6ae 100644
>>> --- a/arch/arm/dts/px30-u-boot.dtsi
>>> +++ b/arch/arm/dts/px30-u-boot.dtsi
>>> @@ -27,6 +27,18 @@
>>> };
>>> };
>>>
>>> +#ifdef CONFIG_SPL
>>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>>> +&binman {
>>> + simple-bin-spi {
>>> + mkimage {
>>> + args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
>>> + };
>>> + };
>>> +};
>>> +#endif
>>> +#endif
>>
>> This is probably wrong, rk3326 use rksd format.
>>
>
> Yes, in v1 I said[1] they probably are the same, but I cannot test it so
> I leave it as it is today. This patch does NOT aim at fixing anything,
> it is simply inverting the logic such that for any *newly* supported
> SoC, the default will be rksd format for SPI booting, and not rkspi. For
> current support, nothing is changed in this commit, if it currently uses
> rkspi (as is the default if unspecified in SoC DTSI), then it'll
> explicitly specify rkspi in the SoC DTSI now that rksd will be the
> default. If it is using the wrong format, it already is and thus can be
> changed in a separate commit. This is intended to be a zero-sum change!
For boards of most of the SoCs that you flip to add use of rkspi in
<soc>-u-boot.dtsi do not have any defconfig or implied/selected value
for ROCKCHIP_SPI_IMAGE and are also missing necessary
BROM_BOOTSOURCE_SPI* mapping in boot_devices.
To me this zero-sum change is just adding lots of unnecessary/unconfirmed
lines to <soc>-u-boot.dtsi files that is not going to be included anyway,
adding the rkspi to socs that regardless have broken SPI flash boot
support make little sense to me.
I would rather you just flip for the socs that have working or at least
a possibility of working SPI flash boot.
Currently this is following socs, based on U-Boot code, Kconfig and
Linux DTs.
- px30/rk3326
- rk3288
- rk3308
- rk3328
- rk3368
- rk3399
- rk3528
- rk3568
- rk3576
- rk3588
- rv1126
Adding the possible correct use of rkspi/rksd gives a false sense that
SPI flash is expected to work for the other socs.
>
> [1]
> https://lore.kernel.org/u-boot/5f45b4ed-d01e-41f8-a05e-c617039228e0@cherry.de/
>
>> Also seeing how the rk3308 has a later model number than PX30/RK3326
>> I would guess that this also applies to RK3308.
>>
>
> /me shrugs. Not tested, won't guess, not worth it.
I have been told that this 2k for each 4k page read bug should have been
fixed sometime after rk3399, so far this has been true based on my
observation, especially for socs using sfc/fspi controller.
Unfortunately I have no reference to provide.
>
> [...]
>
>>> diff --git a/arch/arm/dts/rk3528-u-boot.dtsi b/arch/arm/dts/rk3528-u-boot.dtsi
>>> index a18d33b3d36..f21d76b0e6e 100644
>>> --- a/arch/arm/dts/rk3528-u-boot.dtsi
>>> +++ b/arch/arm/dts/rk3528-u-boot.dtsi
>>> @@ -30,6 +30,18 @@
>>> };
>>> };
>>>
>>> +#ifdef CONFIG_SPL
>>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>>> +&binman {
>>> + simple-bin-spi {
>>> + mkimage {
>>> + args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
>>> + };
>>> + };
>>> +};
>>> +#endif
>>> +#endif
>>
>> This is wrong, please drop for rk3528. I have commits pending for adding
>> proper SPI flash boot support on RK3528 once the E24C model lands in
>> upstream linux, see commits at [1].
>>
>
> Maybe it is wrong, but it is the **current** value. If this series is
> merged after your (yet-to-be-sent?) series, you'll need to rebase to
> remove the args line. If it's the other way around, I'll rebase like I
> did for this one after the RAMBoot series got merged and remove the args
> line (see what I did for rk3576 between v1 and v2), no biggie :)
What you are adding for rk3528 is wrong, and SPI flash boot is currently
not enabled/working for any in-tree rk3528 board, because of this I
intentionally left out use of rksd in rk3528-u-boot.dtsi until SPI flash
boot could be confirmed working.
Can you please provide a fix commit as part of this series in case you
insist on flipping current state 100% in this commit?
Regards,
Jonas
>
> Cheers,
> Quentin
More information about the U-Boot
mailing list