[PATCH] doc: rockchip: Clarify the rkspi image format further
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-032d88dfb9cd@kwiboo.s... [2] https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=LKKyob7fZo79AFkUQKy0e1HBb0zyJ...
Signed-off-by: Dragan Simic dsimic@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. + +See the section above for instructions on how to write an SPI image.
rkmux.py --------
On Sat, Feb 10, 2024 at 07:18:10PM +0100, Dragan Simic wrote:
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-032d88dfb9cd@kwiboo.s... [2] https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=LKKyob7fZo79AFkUQKy0e1HBb0zyJ...
Signed-off-by: Dragan Simic dsimic@manjaro.org
doc/README.rockchip | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
Can we please convert this content to rst under doc/board/rockchip/ then enhance it?
Hello Tom,
On 2024-02-11 00:41, Tom Rini wrote:
On Sat, Feb 10, 2024 at 07:18:10PM +0100, Dragan Simic wrote:
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-032d88dfb9cd@kwiboo.s... [2] https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=LKKyob7fZo79AFkUQKy0e1HBb0zyJ...
Signed-off-by: Dragan Simic dsimic@manjaro.org
doc/README.rockchip | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
Can we please convert this content to rst under doc/board/rockchip/ then enhance it?
Sure, I'll do that, but it will take some time.
On 2/10/24 19:18, Dragan Simic wrote:
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
This not a bug.
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-032d88dfb9cd@kwiboo.s... [2] https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=LKKyob7fZo79AFkUQKy0e1HBb0zyJ...
Signed-off-by: Dragan Simic dsimic@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.
On rk3066 an image should start before page address: NAND : 50 SPI : 13 EMMC : 1
Not sure about start limits for other SoC's. (Kever ??)
Also rk3066 and rk3188 use RC4 crypto.
-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.
This not a bug. It's a design choice to reuse the reading function in the boot ROM shared by EMMC, NAND and SPI etc. due to size restrictions.
See NAND example: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/blob/master/drive...
This NAND code also applies to SPI with minor tweaks. Code will never read more then 2k regardless of the page size.
=== This info must be written in a more neutral wording.(no bugs involved) Just describe the 2 formats and the SoC's that use it.
Johan
=== Extra:
Could someone cleanup README.rockchip The file README.rockchip has most building scenarios covered by now. Please have a look if all the boot log listing in that file are still needed or can be removed.
===
Is there a need for SPI programmer code a la RKMTD with common base and block interface tools?
===
Is someone able to extract rk3568 boot ROM code in order to study NAND boot behavior for a future RKMTD NFC V9 upgrade?
+See the section above for instructions on how to write an SPI image.
rkmux.py
Hello Johan,
On 2024-02-11 15:07, Johan Jonker wrote:
On 2/10/24 19:18, Dragan Simic wrote:
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
This not a bug.
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-032d88dfb9cd@kwiboo.s... [2] https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=LKKyob7fZo79AFkUQKy0e1HBb0zyJ...
Signed-off-by: Dragan Simic dsimic@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.
On rk3066 an image should start before page address: NAND : 50 SPI : 13 EMMC : 1
Not sure about start limits for other SoC's. (Kever ??)
Also rk3066 and rk3188 use RC4 crypto.
-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.
This not a bug. It's a design choice to reuse the reading function in the boot ROM shared by EMMC, NAND and SPI etc. due to size restrictions.
See NAND example: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/blob/master/drive...
This NAND code also applies to SPI with minor tweaks. Code will never read more then 2k regardless of the page size.
=== This info must be written in a more neutral wording.(no bugs involved) Just describe the 2 formats and the SoC's that use it.
Thank you for the clarification! I'll make sure to get the wording adjusted to be more neutral.
=== Extra:
Could someone cleanup README.rockchip The file README.rockchip has most building scenarios covered by now. Please have a look if all the boot log listing in that file are still needed or can be removed.
There's much more in README.rockchip that should be cleaned up and refreshed a bit. I'll convert the file into the RST format and do a few cleanups. After that, everyone will be more than welcome to perform more cleanups.
===
Is there a need for SPI programmer code a la RKMTD with common base and block interface tools?
===
Is someone able to extract rk3568 boot ROM code in order to study NAND boot behavior for a future RKMTD NFC V9 upgrade?
+See the section above for instructions on how to write an SPI image.
rkmux.py
Hi all,
On 2/10/24 19:18, Dragan Simic wrote:
[You don't often get email from dsimic@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-032d88dfb9cd@kwiboo.s... [2] https://lore.kernel.org/u-boot/CACdvmAjfCWicRd=LKKyob7fZo79AFkUQKy0e1HBb0zyJ...
Signed-off-by: Dragan Simic dsimic@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
participants (4)
-
Dragan Simic -
Johan Jonker -
Quentin Schulz -
Tom Rini