Hi Jonas,
On 2/5/25 8:54 PM, Jonas Karlman wrote:
Hi Quentin,
On 2025-02-05 17:51, Quentin Schulz wrote:
Hi Jonas,
On 1/29/25 11:36 PM, Jonas Karlman wrote:
The v2 image format supports defining a load address and flag for each
embedded image.
Add initial support for writing the image load address and flag to the
v2 image format header.
This may later be used for RK3576 to embed a minimal initial image that
if required to fix booting from SD-card due to a BootROM issue.
Would have been better with RK3576 support so we can see how it will be
used. Especially, the flag member is very obscure. If we do nothing with
it and document it as "no use", should we really add code for it?
I fully agree that this patch should possible be dropped from this
series and instead be included in a future rk3576 sd-card workaround
series.
I can only find FLAG=0x10007 for RV1106 in rkbin/RKBOOT, i.e. "no use"
in current state for mainline. However, a few SoCs seem to have use for
a LOAD_ADDR= different from the BootROM default.
Below is what I am playing with. I am not happy with current state and
would instead like to embed the binary code in some way, similar to [1].
See my rk3576-2025.04-wip branch at [2] for the full commit.
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20250103215904.2590769-3-jo...@kwiboo.se/
[2] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3576-2025.04-wip/
commit e431562260a6313f765dbea9ed4f696fa97c5abc
Author: Jonas Karlman <jo...@kwiboo.se>
Date: Tue Jan 28 01:30:12 2025 +0000
WIP: rockchip: mkimage: Add rk3576 align and sd-card workaround
The BootROM on RK3576 has an issue loading boot images from an SD-card.
This issue can be worked around by injecting an initial boot image
before TPL that:
writel(0x3ffff800, 0x3ff803b0)
Extrapolating here, but I guess it works good enough to load this small
boost.bin but not enough for the full TPL (which is the DRAM init blob
from Rockchip) and thus adding boost.bin before Rockchip's DRAM init
blob makes it the whole thing able to boot from SD?
Shouldn't that rather be fixed by Rockchip in their blob? Ideally we
shouldn't need this trick if and once we get an open-source DRAM init.
Prepend an image containing binary code that does this and return to
BootROM to load next image, TPL.
TODO: embed the binary code into rkcommon.c
Signed-off-by: Jonas Karlman <jo...@kwiboo.se>
diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index 8b57ba69cde6..7125b1de9fe9 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -143,7 +143,7 @@ static struct spl_info spl_infos[] = {
{ "rv1126", "110B", 0x10000 - 0x1000, false, RK_HEADER_V1 },
{ "rk3528", "RK35", 0x10000 - 0x1000, false, RK_HEADER_V2 },
{ "rk3568", "RK35", 0x10000 - 0x1000, false, RK_HEADER_V2 },
- { "rk3576", "RK35", 0x80000 - 0x1000, false, RK_HEADER_V2 },
+ { "rk3576", "RK35", 0x80000 - 0x1000, false, RK_HEADER_V2, 8 },
{ "rk3588", "RK35", 0x100000 - 0x1000, false, RK_HEADER_V2 },
};
@@ -271,6 +271,22 @@ int rkcommon_check_params(struct image_tool_params *params)
return EXIT_FAILURE;
}
+ if (!strcmp(params->imagename, "rk3576")) {
+ size = rkcommon_get_aligned_filesize(params,
"rk3576-boost.bin");
+ if (size < 0)
+ return EXIT_SUCCESS;
+
+ for (i = ARRAY_SIZE(spl_params.images) - 1; i > 0; i--) {
+ spl_params.images[i] = spl_params.images[i - 1];
+ }
+
+ spl_params.images[0].file = "rk3576-boost.bin";
+ spl_params.images[0].size = size;
+
+ spl_params.images[0].address = 0x3ffc0000;
+ spl_params.images[1].address = 0x3ff81000;
+ }
+
Can't we add a new node to the rk3576-u-boot.dtsi in
/binman/simple-bin/mkimage which is before rockchip-tpl which generates
this new binary?
Cheers,
Quentin
