Hi Jonas,

Il giorno dom 20 set 2026 alle ore 18:19 Jonas Karlman
<[email protected]> ha scritto:
>
> 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.

Here with "any change to [...] code" I suppose you mean any change of global
data and/or BSS sizes, correct? As code size itself is checked against
TPL_MAX_SIZE at build time. Regarding build time checks, I have a couple
of doubts about [1]:
- shouldn't we check for less than or equal against TPL_MAX_SIZE, instead of
  strictly less than?
- shouldn't be more correct to check the TPL "footprint" size against the 10
  (or 11 or 12) KiB limit, instead only the code size?

With the new layout the check should be:
code size + BSS + GD_SIZE + TPL_SYS_MALLOC_F_LEN + <min_stack> <= 12 KiB

[1] 
https://github.com/u-boot/u-boot/blob/main/arch/arm/mach-rockchip/u-boot-tpl-v8.lds

>
> 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.

The new layout is certainly safer, but I wonder if we are losing the
opportunity for TPL to have approximately 2 extra KiB as they are not used by
BootROM once TPL returns to it. I mean, it would be useful to know where
initial values of TPL_STACK and TPL_SYS_MALLOC_F_LEN came from, and the
rationales behind them. If Rockchip were to assure that preserving only the
first 2 KiB of SRAM is enough for SPL loading, keeping these 2 extra KiB on
the radar could be useful for future TPL development and/or maintenance.

Regards,
Massimo

>
> 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]>
> ---
> The overflow/wrapping was runtime validated on a RK3326 ODROID-GO Super
> by printing out content of [0xff0e0000, 0xff0e5000] and comparing the
> initial 4 KiB with the 16-20 KiB and the data matched 1:1.
>
> Changes in v3:
> - Drop TPL_MAX_SIZE change
> - Keep a small 512 byte malloc area
> - Update commit message to reflect changes
>
> Changes in v2:
> - Mention BSS in commit message
> - Update spelling in commit message
> - Collect r-b tag
> ---
>  arch/arm/mach-rockchip/px30/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/px30/Kconfig 
> b/arch/arm/mach-rockchip/px30/Kconfig
> index adba1b49a52b..0088d436d36f 100644
> --- a/arch/arm/mach-rockchip/px30/Kconfig
> +++ b/arch/arm/mach-rockchip/px30/Kconfig
> @@ -81,10 +81,10 @@ config TPL_TEXT_BASE
>         default 0xff0e1000
>
>  config TPL_STACK
> -       default 0xff0e4fff
> +       default 0xff0e4000
>
>  config TPL_SYS_MALLOC_F_LEN
> -       default 0x600
> +       default 0x200
>
>  config DEBUG_UART_CHANNEL
>         int "Mux channel to use for debug UART2/UART3"
> --
> 2.55.0
>

Reply via email to