Hi Chaoyi,
On 10/28/26 9:41 AM, Chaoyi Chen wrote:
Hi Quentin,
On 10/28/2026 1:42 AM, Quentin Schulz wrote:
Hi Jonas,
On 10/16/26 11:25 PM, Jonas Karlman wrote:
Hi Quentin,
On 10/16/2026 12:31 PM, Quentin Schulz wrote:
Hi Jonas,
On 10/4/26 9:58 PM, Jonas Karlman wrote:
The RK3328 has 36 KiB SRAM at [0xff090000, 0xff099000). With 4 KiB of
the initial SRAM typically reserved for BootROM during early boot.
BootROM will load init code of up to 32 KiB (0x8000 bytes) to address
0xff091000 in SRAM, before jumping to it.
BootROM typically jumps to init code with following registers:
x0: 00000000 ff091004
x1: 00000000 32334b52
x2: 00000000 ff520000
x3: 00000000 ff500000
sp: 00000000 ff090f50
mkimage is enforcing a 30 KiB init code size limit for RK3328.
However, the BootRAM can load up to 32 KiB of init code.
s/BootRAM/BootROM/
Change the init code size limit to 32 KiB using the <size> - <reserved>
pattern to closer match the actual limit of BootROM on RK3328.
Downstream still uses 0x8000 - 0x800 so unless someone from Rockchip
confirms this is safe, I would rather not modify what we have today.
Maybe my commit message was unclear, but I have runtime confirmed that
BootROM is capable of loading binary code up to 32 KiB from SD-card and
eMMC and the code was fully functional even when padded so _reset was
placed at the very end of binary, in the last and lost 2 KiB.
Most likely the mkimage size limit was used to impose limitations for
stack and malloc area, very similar to the issue with PX30/RK3326.
Runtime test consisted of running a minimal <2 KiB TPL binary that only
initialized DEBUG UART and dumped passed x0-x6/r0-r6 and stack pointer.
The binary used no malloc area, its stack was pointed to PMU SRAM or at
half of BootROM reserved stack area, and the binary was .space padded to
push code to very end of the loaded binary.
How can you be sure that we aren't corrupting the BootROM stack? Between TPL
and SPL we actually go back to BootROM so code from there run for sure after
TPL has run.
I did similar runtime tests on all rk3288/rk33xx/rk35xx/rv11xx SoCs I
have access to and all current limits in rkcommon.c beside PX30 and
RK3328 matches the runtime limitations.
On RK3288 (96 KiB SRAM) we can even load a binary up to full 96 KiB,
however from SD-card, only current limit of 32 KiB worked.
Please reconsider and/or hopefully Kever is able to confirm my findings.
I'm not sure we'll get to see Kever much anymore and I don't know who exactly
we should be asking. I've been told Chaoyi Chen might be a good point of
contact now, so trying this here.
@Chaoyi, can you confirm we can use 32KiB of SRAM on RK3328? See
https://lore.kernel.org/u-boot/[email protected]/t/#u for
the whole context.
I'm not quite sure whether I caught what you meant. And I guess you
want to know the stack and data ranges used by the RK3288 Bootrom?
If that is the case, then the RK3288 BootROM will use the 0–4KB space
for the stack and data, while the remaining SRAM stores the init code.
With the SRAM being 36KiB according to the RK3328 v1.2 datasheet and
your comment above, we should be able to use 32KiB for the init code as
stated by Jonas in this patch.
However, Rockchip's downstream U-Boot limits the size to 30KiB (0x8000 -
0x800), c.f.
https://github.com/rockchip-linux/u-boot/blob/1c535d65b8509f388d09e49fb6961f49fda35a1d/tools/rkcommon.c#L143.
I was thus asking for confirmation because we are about to diverge from
Rockchip's downstream U-Boot and I don't like to do this, especially for
things we (non-Rockchip people) cannot know if it's not documented.
My understanding with your answer is that Jonas's patch to increase the
max init code size from 30KiB to 32KiB is fine, and I will therefore
merge this patch. Please shout in the next few days if that is
incorrect, so I don't merge it.
Thanks Chaoyi for the prompt answer, much appreciated!
Acked-by: Quentin Schulz <[email protected]>
Cheers,
Quentin
