Hi Jonas,
On 9/20/26 6:19 PM, Jonas Karlman wrote:
The PX30/RK3326 has 16 KiB SRAM at [0xff0e0000, 0xff0e4000), with the
initial 4 KiB at [0xff0e0000, 0xff0e1000) reserved for BootROM at boot.
SRAM addressing only seems to use 14 bits, meaning that reading from
0xff0e4000+ wraps around and instead reads back data at 0xff0e0000+.
Using a TPL_STACK at 0xff0e4ff0 (16-bytes aligned) means TPL use BootROM
reserved region for its global data, malloc area and runtime stack.
TPL on PX30/RK3326 does not have any use for the malloc area, the
generated GD_SIZE is typically around 304 bytes and BSS around 72 bytes.
Current memory layout possibly looks something like:
[0xff0e0000, 0xff0e4000) 16 KiB SRAM
[0xff0e0000, 0xff0e1000) 4 KiB BROM area
[..., 0xff0e08c0) stack area
[0xff0e08c0] stack pointer
[0xff0e08c0, 0xff0e09f0) 304 bytes global data (zeroed)
[0xff0e09f0, 0xff0e0ff0) 1536 bytes malloc area (untouched)
[0xff0e1000, 0xff0e4000) 12 KiB TPL area
[0xff0e1000, 0xff0e3800) 10 KiB code
[0xff0e3800, 0xff0e3848) 72 bytes BSS
TPL currently does not touch the malloc area, instead the reserved
TPL_SYS_MALLOC_F_LEN bytes help push the zeroed global data struct and
the TPL stack addresses deeper into the BootROM reserved area.
Using current offsets for global data and stack does not seem to cause
any known issue for BootROM after TPL returns to BootROM to load SPL
into DRAM, however any change to TPL_STACK, TPL_SYS_MALLOC_F_LEN or code
could theoretically change this and cause issues for BootROM.
Update TPL_STACK to use the top of SRAM address and reduce MALLOC_F_LEN
to 0x200 to avoid overflowing global data, malloc area and stack into
the BootROM reserved region.
With these changes the memory layout looks something like:
[0xff0e0000, 0xff0e4000) 16 KiB SRAM
[0xff0e0000, 0xff0e1000) 4 KiB BROM area
[0xff0e1000, 0xff0e4000) 12 KiB TPL area
[0xff0e1000, 0xff0e3800) 10 KiB code
[0xff0e3800, 0xff0e3848) 72 bytes BSS
[0xff0e3848, 0xff0e3cd0) 1160 bytes stack area
[0xff0e3cd0] stack pointer
[0xff0e3cd0, 0xff0e3e00) 304 bytes global data
[0xff0e3e00, 0xff0e4000) 512 bytes malloc area (unused)
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
I intend to take this for 2027.01. We've lived with this mistake since
forever and I would like to avoid changes with potentially big
consequences like this one here so late in the development cycle.
Looking forward for what was split from v2 into other patches
(specifically bumping TPL_MAX_SIZE to the one used in downstream).
Thanks!
Quentin
