Hi all,
On 2/10/24 19:18, Dragan Simic wrote:
[You don't often get email from dsi...@manjaro.org. Learn why this is important
at https://aka.ms/LearnAboutSenderIdentification ]
As discussed on the U-Boot mailing list, [1][2] only some Rockchip SoCs
suffer from a bug in their BROMs that requires a specific format for their
SPI images, which was the reason for the rkspi format to be introduced.
Improve the description of the rkspi format a bit to mention this, for
future reference and to make understanding it easier.
[1]
https://lore.kernel.org/u-boot/c32129ba-db25-4b9d-9a4a-032d88dfb...@kwiboo.se/
[2]
https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=lkkyob7fzo79afkuqky0e1hbb0zyjuoo...@mail.gmail.com/
Signed-off-by: Dragan Simic <dsi...@manjaro.org>
---
doc/README.rockchip | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/doc/README.rockchip b/doc/README.rockchip
index 84caff8a24d3..e0c5c395ec6a 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -649,7 +649,12 @@ sector is used. The header is the same as with rksd and
the maximum size is
also 32KB (before spreading). The image should be written to the start of
SPI flash.
-See above for instructions on how to write a SPI image.
+Only the BROMs of some Rockchip SoCs, such as the RK3399, suffer from a bug
+that mandates the above-described data spreading, thus requiring the rkspi
+format to be used for their SPI images. Rockchip SoCs that don't suffer
+from this bug use the rksd format for their SPI images.
+
Then I would suggest we move
"""
args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
"""
from arch/arm/dts/rockchip-u-boot.dtsi
to the SoCs -u-boot.dtsi that are impacted?
e.g.
"""
#ifdef CONFIG_SPL
&binman {
#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
simple-bin-image {
mkimage {
args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
};
};
#endif
};
#endif
"""
in arch/arm/dts/rockchip/rk3399-u-boot.dtsi
and have "rksd" in rockchip-u-boot.dtsi instead?
We can then document this rkspi type specifically for those SoCs.
Because this kinda means we're currently virtually inflating the size of
the TPL/SPL on non-impacted SoCs for no reason whatsoever.
Cheers,
Quentin
