Hi Jonas,
On 12/16/25 6:57 PM, Jonas Karlman wrote:
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 <[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!
For boards of most of the SoCs that you flip to add use of rkspi in
I don't add use of rkspi, it already is using rkspi.
[...]
Adding the possible correct use of rkspi/rksd gives a false sense that
SPI flash is expected to work for the other socs.
So is being able to set ROCKCHIP_SPI_IMAGE=y with menuconfig for SoCs we
don't have the necessary stuff to fully boot from SPI. Though I assume
we could have idbloader.img from SPI and then fallback to other
supported media (MMC) even if fulling booting from SPI isn't supported yet.
[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.
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.
I've asked which SoCs are impacted by this "quirk" multiple times on
this ML but never got an answer from Rockchip people. This would make
everything so much easier.
This patch is pretty clear in what it is doing. I can add a comment in
each untested SoC specifying we don't know if this is working so that
people will not be confused as you claim they will. I will not be doing
a partial patch. I believe this patch is useful to avoid having to do
what you're doing for every new SoC where we need to add to its DTSI an
args property to mkimage to change from rkspi to rksd format for the
bootable SPI image.
This has been the case for years now, so if there's no consensus, I
guess we can just keep doing this for every new SoC, it isn't a big deal
to me. Patch 1 and 3 can still be applied individually regardless of
patch 2.
Cheers,
Quentin
