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. -- Best, Chaoyi
