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 <[email protected]>

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 <[email protected]>
---
  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!

[1] https://lore.kernel.org/u-boot/[email protected]/

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.

[...]

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 :)

Cheers,
Quentin

Reply via email to