On 10/28/2026 4:41 PM, 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. >
Typo.. It is RK3328. -- Best, Chaoyi
