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
