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

[Jonas Karlman]

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.

> 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