Hi again,
On 9/28/2026 11:13 PM, Jonas Karlman wrote:
> Hi Quentin and Massimo,
>
> On 9/28/2026 11:10 AM, Quentin Schulz wrote:
>> Hi Massimo,
>>
>> On 9/28/26 8:42 AM, Massimo Pegorer wrote:
>>> Hi Quentin,
>>>
>>> On 9/24/26 12:03 PM, Quentin Schulz wrote:
>>>> Hi Massimo,
>>>>
>>>> On 9/23/26 7:52 PM, Massimo Pegorer wrote:
>>>>> Hi Jonas,
>>>>>
>>>>> Il giorno mar 22 set 2026 alle ore 15:28 Jonas Karlman ha scritto:
>>>>>>
>>>>>> Hi Massimo,
>>>>>>
>>>>>> On 9/22/2026 1:35 PM, Massimo Pegorer wrote:
>>>>>>> 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?
>>>>>>
>>>>>> Not only, the change to TPL_STACK, TPL_SYS_MALLOC_F_LEN or 'struct
>>>>>> global_data' would affect where the TPL stack ends up. However, and any
>>>>>> change to the code may change how the stack is used and thus possible
>>>>>> write to more/less/other data inside the BootROM area.
>>>>>>
>>>>>>> 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?
>>>>>>
>>>>>> Correct, this was also briefly discussed/mentioned in the v2 thread.
>>>>>> However,
>>>>>> this patch only tries to address the issue with TPL stack being placed
>>>>>> inside
>>>>>> BootROM reserved area.
>>>>>
>>>>> Indeed. I was just wondering if in a future patch we should avoid
>>>>> TPL_MAX_SIZE
>>>>> configuration, and instead have just TPL_MAX_FOOTPRINT configured to
>>>>> 0x3000
>>>>> adding GD_SIZE and TPL_SYS_MALLOC_F_LEN in the linker check.
>>>>>
>>>>
>>>> I had never heard of that symbol before and went checking. It has never
>>>> been used (there isn't even a Kconfig symbol for it!) so we would need a
>>>> bit of work to make this work (probably not a crazy amount though :) ).
>>>>
>>>> I'm not sure we still need arch/arm/mach-rockchip/u-boot-tpl-v8.lds
>>>> though. It's only used for evb-px5_defconfig, all PX30, all RK3328, all
>>>> RK3399 and RV1126.
>>>> I think it was necessary when added back in 2019 because
>>>> arch/arm/cpu/armv8/u-boot-spl.lds didn't allow yet to remove the SDRAM
>>>> part in it (c.f. 3cbec0ad090f ("rockchip: add u-boot-tpl-v8.lds") which
>>>> claims "we don't have both SRAM and SDRAM in TPL" but we have SRAM
>>>> access in TPL, don't we?), but that has changed since 2024. They are a
>>>> bit different though and I have no experience with linker scripts so no
>>>> clue if it makes sense to merge them (if at all possible). I'm guessing
>>>> the additional asserts would make sense for everybody anyway.
>>>
>>> Me too, almost no experience with linker scripts. Anyway, I had a quick look
>>> at arch/arm/cpu/armv8/u-boot-spl.lds for TPL building purpose, and IMO it's
>>> broken by design because of SPL specific configuration options dependencies:
>>> SPL_SEPARATE_BSS and SPL_RECOVER_DATA_SECTION. I will check more in depth.
>>>
>>
>> We can always migrate those to CONFIG_IS_ENABLED(SEPARATE_BSS),
>> CONFIG_IS_ENABLED(RECOVER_DATA_SECTION), CONFIG_VAL(BSS_START_ADDR),
>> CONFIG_VAL(BSS_MAX_SIZE), etc., if needed.
>
> I did a quick test with my TPL stubs on RK3568 and RK3528 and we can
> likely use arch/arm/cpu/armv8/u-boot-spl.lds after your suggested
> changes.
>
> However, we must also ensure to disable TPL_SEPARATE_BSS and not let it
> use the default TPL_SEPARATE_BSS=SPL_SEPARATE_BSS, and also ensure that
> TPL_MAX_SIZE is defined, as it will define the LENGTH of the MEMORY,
> i.e. work as a built in size check that image+bss fit inside .sram.
>
> And then we possible could to add a new size check, or possible manually
> just ensure that TPL_MAX_SIZE is reduced by GD_SIZE, TPL_SYS_MALLOC_F_LEN
> and a guestimated usage need for the runtime stack.
>
>>
>>> BTW, the .sram MEMORY segment definition in the script would do the game:
>>> here
>>> the size that linker would check against TPL_MAX_SIZE includes BSS (consider
>>> the case SPL_SEPARATE_BSS not defined, of course), while u-boot-tpl-v8.lds
>>> checks size without BSS against TPL_MAX_SIZE.
>>>
>>
>> We would have the same behavior of size checking if we had
>> TPL_SEPARATE_BSS enabled I believe. But if we had TPL_SEPARATE_BSS
>> enabled, then we would have an .sdram section too, which is the reason
>> for having a separate linker script in the first place.
>
> Correct, we should use TPL_SEPARATE_BSS=n if we want to replace the
> custom rockchip tpl armv8 linker script and keep current behavior.
>
>>
>> I'm also not sure about IMAGE_TEXT_BASE (set by CONFIG_TEXT_BASE) only
>> used in the armv8 linker script and the first
>>
>> . = 0x00000000;
>>
>> in Rockchip's TPL linker script.
>
> It does not seem like this line is needed in the linker script.
>
>>
>> But maybe we should really have BSS part of the size check.
>
> As mentioned above, with a TPL_MAX_SIZE the .sram LENGTH is assigned and
> we get a built in size check, e.g. using TPL_MAX_SIZE=0x100 stop build:
>
> LD tpl/u-boot-tpl
> /usr/bin/aarch64-linux-gnu-ld.bfd: address 0xfe481570 of u-boot-tpl section
> `.text' is not within region `.sram'
> /usr/bin/aarch64-linux-gnu-ld.bfd: u-boot-tpl section `.rodata' will not
> fit in region `.sram'
> /usr/bin/aarch64-linux-gnu-ld.bfd: address 0xfe481570 of u-boot-tpl section
> `.text' is not within region `.sram'
> /usr/bin/aarch64-linux-gnu-ld.bfd: address 0xfe481570 of u-boot-tpl section
> `.text' is not within region `.sram'
> /usr/bin/aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 1464 bytes
> make[2]: *** [scripts/Makefile.xpl:546: tpl/u-boot-tpl] Error 1
>
>>
>> I'm out of my depth here though, no clue what would be proper.
>
> For my forth coming TPL refactor series I tried to sync a few changes
> into the Rockchip custom linker script, probably better to try and drop
> it instead.
>
> On a side note, the TPL stub runtime tests on RK3568 and RK3528 revealed
> that in special cases we possible could use the BootROM stack, but I
> still think that can be risky and that it is safer that we keep U-Boot
> TPL stack and malloc area separate from the BootROM stack.
>
> Test run of TPL stub on RK3528:
>
> U-Boot TPL 2026.10-rc5 (Sep 28 2026 - 20:23:41)
> x0: fe480458
> x1: 00000008
> x2: fe481000
> sp: fe480ef0
> DRAM init failed
>
> Test run of TPL stub on RK3568:
>
> U-Boot TPL 2026.10-rc5 (Sep 28 2026 - 20:22:26)
> x0: fdcc0098
> x1: 00000008
> x2: fdcc1000
> sp: fdcc0f30
> DRAM init failed
>
> Above is the values x0, x1, x2 and sp register had when BootROM called
> the TPL code.
>
> The stack pointer seem to be near the end of the BootROM reserved area.
> Not sure what x0 or x1 values could be, but x2 seem to match
> TPL_TEXT_BASE, so possible the address BootROM called/jumped to.
I did similar testing on a RK3288 TinkerBoard-S, it seem to reveal that
we are currently limiting TPL size to 32 KiB, however using the entire
96 KiB SRAM on RK3288 seems to be working.
With u-boot-tpl.bin that is 0x878 bytes:
U-Boot TPL 2026.10-rc5 (Sep 29 2026 - 07:32:40)
0: 32334b52 ("RK32")
1: eaffffff
2: ffffffff
3: ff704882 (payload size?, 0x878 vs 0x882)
4: ff702964
5: 00000002
6: 00000000
7: ff703790 (sp)
DRAM init failed
and with u-boot-tpl.bin that is 0x13878 bytes (.space 0x13000 padding
before reset symbol):
U-Boot TPL 2026.10-rc5 (Sep 29 2026 - 07:38:06)
0: 32334b52 ("RK32")
1: eaffffff
2: ffffffff
3: ff717882 (payload size?, 0x13878 vs 0x17882)
4: ff702964
5: 00000002
6: 00000000
7: ff703790 (sp)
DRAM init failed
I will try to run similar tests on my other RK SoCs to see how they
behave and to verify rkcommon.c limit matches actual limits.
Regards,
Jonas
>
> Also x3-x7 did not seem to have any useful values or they changed each
> board reset.
>
> What I take away from all above is that I will shortly update my rk3562
> work-in-progress branch to also define TPL_MAX_SIZE to be the result of
> TPL_STACK-TPL_TEXT_BASE for all added TPL stubs.
>
> Regards,
> Jonas
>
>>
>> Cheers,
>> Quentin
>
