[PATCH RFC 02/18] clk: rockchip: rk3568: Fix probe with OF_PLATDATA enabled

Jonas Karlman jonas at kwiboo.se
Wed May 27 23:06:51 CEST 2026 

Hi Pavel,

On 5/26/2026 7:59 PM, Pavel Golikov wrote:
> Hi Jonas,
> 
> On Tue, May 26, 2026 at 06:41:39PM +0200, Jonas Karlman wrote:
>> Hi Pavel,
>>
>> On 5/26/2026 5:14 PM, Pavel Golikov wrote:
>>> Hi Jonas,
>>>
>>> On Tue, May 26, 2026 at 10:17:16AM +0200, Jonas Karlman wrote:
>>>> Hi Pavel,
>>>>
>>>> On 5/24/2026 9:39 PM, Pavel Golikov wrote:
>>>>> Hi Jonas,
>>>>>
>>>>> On Sun, May 24, 2026 at 08:42:33PM +0200, Jonas Karlman wrote:
>>>>>> Hi Pavel,
>>>>>>
>>>>>> On 5/17/2026 9:24 PM, Pavel Golikov wrote:
>>>>>>> Properly initialize cru address space reference when CONFIG_OF_PLATDATA
>>>>>>> is enabled.
>>>>>>
>>>>>> Do we have to use OF_PLATDATA for TPL to fit into SRAM?
>>>>>
>>>>> DRAM driver is heavily based on one for rv1126. rv1126 utilizes OF_PLATDATA,
>>>>> even though it is 32 bit (with the same amount of SRAM), and 32 bit TPL should
>>>>> be even smaller.
>>>>
>>>> None of the existing Rockchip TPL implementation is very optimized and
>>>> likely not a good candidate on how optimized DRAM init can be handled :-)
>>>>
>>>>>> Also, why do we need CLK driver in TPL? Based on small glance at the
>>>>>> code it looks like the DPLL was handled by the RAM driver itself.
>>>>>
>>>>> I'm getting
>>>>>
>>>>> aarch64-linux-gnu-ld: arch/arm/mach-rockchip/rk3568/clk_rk3568.o: in function `rockchip_get_clk':
>>>>> <...>/build-tpl/../arch/arm/mach-rockchip/rk3568/clk_rk3568.c:14: undefined reference to `_u_boot_list_2_driver_2_rockchip_rk3568_cru'
>>>>> aarch64-linux-gnu-ld: <...>/build-tpl/../arch/arm/mach-rockchip/rk3568/clk_rk3568.c:14: undefined reference to `_u_boot_list_2_driver_2_rockchip_rk3568_cru'
>>>>>
>>>>> when trying to build TPL without CLK (both with OF_PLATDATA and OF_REAL).
>>>>> rockchip_get_clk is needed by sysreset_rockchip, which, in turn, is always
>>>>> built for ARCH_ROCKCHIP (sorry).
>>>>
>>>> Correct, as I mentioned, there are dependency issues that needs to be
>>>> resolved, the question remains, does the DRAM init code need to
>>>> initialize any clocks that is currently handled in the clock driver?
>>>
>>> No, it does not.
>>
>> Great :-)
>>
>>>> Or could macros from cru_rk3568.h be used directly in DRAM init code
>>>> to save on size?
>>>>
>>>> Anyway, I have some work-in-progress code [1] that cleanup some of these
>>>> dependency issues and should allow for a very light TPL.
>>>>
>>>>   make generic-rk3568_defconfig rockchip-tpl-lpddr4.config
>>>>
>>>> With that I get a ~2 KiB TPL that could be used as a starting ground
>>>> for a size optimized DRAM init.
>>>
>>> Did a quick rebase on top of your branch here [1]. It works without TPL_DM, but
>>> requires CFG_SYS_NS16550_CLK and CFG_SYS_NS16550_COM1 definitions to make it
>>> all buildable.
>>
>> Yeah, I did a quick run myself and noticed debug uart was not part of
>> the build, did some more tuning and with TPL_FRAMEWORK=n and some HACK
>> for TPL_SERIAL_PRESENT=n the resulting binary of ~1600 bytes could run:
>>
>>   U-Boot TPL 2026.07-rc3-00120-g5e02efad2ee9-dirty (May 26 2026 - 16:13:44)
>>   DRAM init failed
>>   Returning to boot ROM...
>>
>> on RK3568 (and RK3576).
>>
>> With TPL_FRAMEWORK=n and dropping printf() in tpl.c, tiny-printf could
>> be avoided to help save some space.
>>
>>> 46184 vs 37288 bytes for TPL, and no malloc in the image. Impressive.
>>
>> Impressive!
>>
>>> But still board_init_f_alloc_reserve(0xfdcd8000). I also wonder why we move
>>> stack pointer on TPL start, instead of using the stack provided by bootrom.
>>> I suspect that 0xfdcc0600 - 0xfdcc1000 is a bootrom stack region.
>>
>> Yeah, 0xfdcd8000 looks like a strange stack addr to use? I tested with
>> 0xfdcd0000 as the stack addr (end of sys sram). We should avoid touching
>> anything in bootrom stack, since we jump back to bootrom to load next
>> stage.
> 
> As strange as rv1126. It also places its stack somwhere in undocumented memory
> region.

That sounds very weird, do not think I have any rv1126 device, so cannot
do any runtime tests on that SoC myself.

> I'm talking about something like
> 
> diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
> index 3e7627aa389..ec4df0e57b5 100644
> --- a/arch/arm/lib/crt0_64.S
> +++ b/arch/arm/lib/crt0_64.S
> @@ -70,7 +70,7 @@ ENTRY(_main)
>   * Set up initial C runtime environment and call board_init_f(0).
>   */
>  #if CONFIG_IS_ENABLED(HAVE_INIT_STACK)
> -	ldr	x0, =CONFIG_VAL(STACK)
> +	mov	x0, sp
>  #elif defined(CONFIG_INIT_SP_RELATIVE)
>  #if CONFIG_POSITION_INDEPENDENT
>  	adrp	x0, __bss_start     /* x0 <- Runtime &__bss_start */
> diff --git a/arch/arm/mach-rockchip/rk3568/Kconfig b/arch/arm/mach-rockchip/rk3568/Kconfig
> index 893185291d8..86eddf01b03 100644
> --- a/arch/arm/mach-rockchip/rk3568/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3568/Kconfig
> @@ -78,10 +78,10 @@ config TPL_LDSCRIPT
>  	default "arch/arm/mach-rockchip/u-boot-tpl-v8.lds"
>  
>  config TPL_STACK
> -	default 0xfdcd8000
> +	default 0xcafebabe
>  
>  config TPL_SYS_MALLOC_F_LEN
> -	default 0x2000
> +	default 0x1
>  
>  config TPL_TEXT_BASE
>  	default 0xfdcc1000
> diff --git a/arch/arm/mach-rockchip/tpl.c b/arch/arm/mach-rockchip/tpl.c
> index 2eb72dfdd20..235ff6e5268 100644
> --- a/arch/arm/mach-rockchip/tpl.c
> +++ b/arch/arm/mach-rockchip/tpl.c
> @@ -42,6 +42,9 @@ void board_init_f(ulong dummy)
>  	 * printascii("string");
>  	 */
>  	debug_uart_init();
> +
> +	char buffer[16];
> +	printf("Our stack: %x", (uint32_t)(void *)buffer);
>  #ifdef CONFIG_TPL_BANNER_PRINT
>  	printascii("\nU-Boot TPL " PLAIN_VERSION " (" U_BOOT_DATE " - " \
>  				U_BOOT_TIME ")\n");
> 
> DRAM init still works with this applied. And I'm getting
> 
> Our stack: fdcc0e10
> U-Boot TPL 2026.07-rc3-ge39964c734f3-dirty (May 26 2026 - 20:53:34)
> ...
> 
> So, bootrom calls us with valid stack pointer, and there is a little sence in
> moving the stack anywhere if we fit into it. 0x110 bytes on the stack is taken
> by struct global_data.

I still think it is best to use our own stack and leave the brom stack
as-is for when we eventually longjmp back to brom. We never know what
Kconfig options end users try to enable, some of them could require a
larger stack or could potentially corrupt some internal state for brom.

Btw, I continued to shave off a few bytes and started to split some of
the changes into separate commits as a preparation for a proper series.

Using my latest force-push ci-branch, a skeleton TPL that call dram init
and then go back to BootROM to load next image take up around:

  TPL_SERIAL=n, LTO=y:   848 bytes
  TPL_SERIAL=n, LTO=n:   904 bytes
  TPL_SERIAL=y, LTO=y:  1256 bytes
  TPL_SERIAL=y, LTO=n:  1368 bytes

Will validate on older RK SoCs that these changes do not brake anything,
and then start sending some of the changes to the list, likely later
this weekend.

Regards,
Jonas

> 
>>> I also noticed that debug_uart_init() is called twice. Once in
>>> crt0.S/crt0_64.S, and once in board_init_f. Is this behaviour intended?
>>
>> Great find, I dropped the call in tpl.c and did a re-test on my rk3568
>> and rk3576 boards, then pushed two new commits to my ci branch that
>> included the above mentioned tuning. Not happy with the SERIAL_PRESENT
>> hack, but it could compile and reduced code size ;-)
>>
>> I will try to cleanup and push out a few patches later this week, after
>> doing some runtime validation on the other RK SoCs that currently use
>> TPL.
>>
>>>> Implement board_debug_uart_init(), sdram_init() and the missing RK3568
>>>> specific TPL Kconfig options, i.e. TPL_TEXT_BASE etc. and hopefully that
>>>> should be enough for a size optimized DRAM init.
>>>>
>>>> [1] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/ci
>>>>
>>>> I will rework some of those patches and send to list later this week.
>>>>
>>>> Regards,
>>>> Jonas
>>>>
>>>>>
>>>>> We could actually delegate DPLL to CLK, but there is no API to configure spread
>>>>> spectrum (although it is disabled by default in loader_params). I also have no
>>>>> idea of how MSCH clock tree looks like.
>>>>>
>>>>> Regards,
>>>>> Pavel 
>>>>
>>>
>>> [1] https://github.com/Paullo612/u-boot/tree/ci-rk3568-raminit-rfc-v2
>>
>> Will take a closer look/review of your patches and do some runtime tests
>> later.
>>
>> Regards,
>> Jonas
>>
>>>
>>> Regards,
>>> Pavel
>>
> 
> Regards,
> Pavel

More information about the U-Boot mailing list