Hi Quentin, On 10/27/2026 6:42 PM, 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.
We cannot be 100% sure, however as stated in the commit message, the BootROM stack is located in the initial 4 KiB of SRAM, [0xff090000, 0xff091000), and its stack-pointer is typically at 0xff090f50 when entering into the init code, i.e. it matches the pattern used for all other Rockchip SoCs where the BootROM stack is located before the init code load address. The issue with RK3328 is likely that some datasheets/TRMs mentioned 32 KiB of SRAM in some places and the correct 36 KiB in others. Right now, we reserve initial 4 KiB for BootROM, allow 30 KiB for init code and for no reason restrict use of the last 2 KiB of SRAM. The limits imposed by mkimage should not care about what the init code does, it should only impose real HW limits and not make assumption on what U-Boot TPL is doing. Let's say I created a custom binary that takes up entire load address to end of SRAM and can safely run, right now mkimage cannot be used for such binary due to this self-imposed limit, for all other Rockchip SoCs such binary would be accepted by mkimage. Any limits e.g. due to use of TPL stack, malloc area or back to BootROM feature is specific to the U-Boot TPL binary and should be limited using TPL_MAX_SIZE or similar, not by the init code size limit of mkimage. > >> 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. Would be nice to get a confirmation, however my runtime testing should already help prove that we can load and run a 32 KiB binary on this SoC, and that the limit imposed by mkimage is correct for all other SoCs I could run same test on: rk3228, rk3288, rk3308, rk3326 (after patch 1), rk3399, all rk35xx variants, rv1106, rv1103b and rv1126b. Regards, Jonas > > Cheers, > Quentin
