[PATCH v3 0/6] clk: support arbitrary clk_register() sequence
Yang Xiwen
forbidden405 at outlook.com
Sat Feb 7 15:58:16 CET 2026
On 2/4/2026 12:15 AM, Tom Rini wrote:
> On Tue, Feb 03, 2026 at 11:28:03PM +0800, Yang Xiwen wrote:
>> On 2/3/2026 4:17 AM, Tom Rini wrote:
>>> On Tue, Jan 20, 2026 at 03:07:17AM +0800, Yang Xiwen wrote:
>>>
>>>> Currently, the U-Boot clk framework mandates that clock registration
>>>> begins at the root and proceeds to children. This creates an additional
>>>> requirement that does not exist in the Linux kernel, making the porting
>>>> of clk drivers more difficult.
>>>>
>>>> This series handles the dependency entirely within the clk framework,
>>>> allowing drivers the freedom to register clocks in any order.
>>>>
>>>> This is achieved by assigning the parent "lazily". The framework caches
>>>> the parent name in the core clk struct and attempts to resolve the
>>>> actual parent when clk consumers call clk_get_parent(). The process is
>>>> transparent to clk consumers as long as they use standard clk framework
>>>> APIs.
>>>>
>>>> I've run `ut dm clk*` and verified these commits do not break any
>>>> existing test cases. It also passes the new test case.
>>>>
>>>> This feature is disabled for xPLs by default. I have not found a clean
>>>> way to enable this separately for xPLs without introducing a repetitive
>>>> Kconfig entry (e.g., xPL_CLK_LAZY_REPARENT), which looks very ugly.
>>>>
>>>> Signed-off-by: Yang Xiwen <forbidden405 at outlook.com>
>>> This, like some previous clk reworks, leads to run-time breakage
>>> (failure to boot) on TI K3 and likely other platforms (I want to say
>>> some rockchip was broken last time) as well.
>>>
>> It's sad to hear that. Could you please provide the log so I can try to fix
>> that? This also means our testcases can't cover all cases.
> On am62x_beagleplay_a53 + am62x_beagleplay_r5:
> U-Boot SPL 2026.04-rc1-00076-gfd070b0e7186 (Feb 03 2026 - 16:07:42 +0000)
> SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.7--v09.02.07 (Kool Koala)')
> Set clock rates for '/a53 at 0', CPU: 1250MHz at Speed Grade 'T'
> SPL initial stack usage: 13464 bytes
> Trying to boot from MMC2
> Starting ATF on ARM64 core...
>
> NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c
> NOTICE: BL31: Built : 14:04:51, Jun 24 2024
> I/TC:
> I/TC: OP-TEE version: 4.2.0-22-g16fbd46d2 (gcc version 13.2.0 (GCC)) #4 Mon Jun 24 20:04:07 U
> TC 2024 aarch64
> I/TC: WARNING: This OP-TEE configuration might be insecure!
> I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guide
> lines.html
> I/TC: Primary CPU initializing
> I/TC: GIC redistributor base address not provided
> I/TC: Assuming default GIC group status and modifier
> I/TC: SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.7--v09.02.07 (Kool Koala)')
> I/TC: HUK Initialized
> I/TC: Primary CPU switching to normal world boot
>
> U-Boot SPL 2026.04-rc1-00076-gfd070b0e7186 (Feb 03 2026 - 16:09:31 +0000)
> SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.7--v09.02.07 (Kool Koala)')
> SPL initial stack usage: 2048 bytes
> Trying to boot from MMC2
>
>
> U-Boot 2026.04-rc1-00076-gfd070b0e7186 (Feb 03 2026 - 16:09:31 +0000)
>
> SoC: AM62X SR1.0 GP
> Reset reason: POR
> Model: BeagleBoard.org BeaglePlay
> DRAM: 2 GiB
> I/TC: Reserved shared memory is enabled
> I/TC: Dynamic shared memory is enabled
> I/TC: Normal World virtualization support is disabled
> I/TC: Asynchronous notifications are disabled
> Core: 112 devices, 33 uclasses, devicetree: separate
> MMC: mmc at fa10000: 0, mmc at fa00000: 1, mmc at fa20000: 2
> Loading Environment from nowhere... OK
> In: serial at 2800000
> Out: serial at 2800000
> Err: serial at 2800000
> Net: "Synchronous Abort" handler, esr 0x02000000
> elr: 00000000808c1b28 lr : 00000000808357b0 (reloc)
> elr: 00000000fffd2b28 lr : 00000000fff467b0
> x0 : 00000000fdef7340 x1 : 00000000fffd2b28
> x2 : 000000000000000a x3 : 0000000000000000
> x4 : 000000000000000d x5 : 0000000000000064
> x6 : 00000000fffb088b x7 : 0000000000000044
> x8 : 000000000000000a x9 : 0000000000000034
> x10: 0000000000000002 x11: 00000000ffffffff
> x12: 00000000fdede730 x13: 0000000000007040
> x14: 00000000fdede730 x15: 00000000ffffffff
> x16: 00000000fff53ac8 x17: 0000000000000000
> x18: 00000000fdef1e10 x19: 0000000000000000
> x20: 00000000fdef7340 x21: 00000000fffccfc0
> x22: 00000000fffd4ed0 x23: 00000000fffd4000
> x24: 00000000fdefac18 x25: 00000000fdefac18
> x26: 00000000fff7bcfc x27: 00000000fff7bdb4
> x28: 00000000fffaa8f0 x29: 00000000fdede5b0
>
> Code: fffd2b08 00000000 fffd2b08 00000000 (fffd2b18)
> Resetting CPU ...
>
> resetting ...
>
Is the uboot image built by buildman toolchain or some other toolchain?
I've tried to generate the image with `tools/buildman/buildman -M -k
am62x_beagleplay_r5` and debug it with `gdb-multiarch
../current/am62x_beagleplay_r5/u-boot`. But the result doesn't seem correct.
The output of gdb:
(gdb) disas/r 0x808357b0
Dump of assembler code for function menu_destroy.isra.0:
0x8083578c <+0>: b5f8 push {r3, r4, r5, r6, r7, lr}
0x8083578e <+2>: 4605 mov r5, r0
0x80835790 <+4>: 4604 mov r4, r0
0x80835792 <+6>: f855 3f24 ldr.w r3, [r5, #36]!
0x80835796 <+10>: 681e ldr r6, [r3, #0]
0x80835798 <+12>: 42ab cmp r3, r5
0x8083579a <+14>: d108 bne.n 0x808357ae
<menu_destroy.isra.0+34>
0x8083579c <+16>: 68a0 ldr r0, [r4, #8]
0x8083579e <+18>: b108 cbz r0, 0x808357a4
<menu_destroy.isra.0+24>
0x808357a0 <+20>: f7d6 fae6 bl 0x8080bd70 <free>
0x808357a4 <+24>: 4620 mov r0, r4
0x808357a6 <+26>: e8bd 40f8 ldmia.w sp!, {r3, r4, r5, r6,
r7, lr}
0x808357aa <+30>: f7d6 bae1 b.w 0x8080bd70 <free>
0x808357ae <+34>: f853 0c08 ldr.w r0, [r3, #-8]
0x808357b2 <+38>: f1a3 0708 sub.w r7, r3, #8
0x808357b6 <+42>: b108 cbz r0, 0x808357bc
<menu_destroy.isra.0+48>
0x808357b8 <+44>: f7d6 fada bl 0x8080bd70 <free>
0x808357bc <+48>: 4638 mov r0, r7
0x808357be <+50>: f7d6 fad7 bl 0x8080bd70 <free>
0x808357c2 <+54>: 4633 mov r3, r6
0x808357c4 <+56>: 6836 ldr r6, [r6, #0]
0x808357c6 <+58>: e7e7 b.n 0x80835798
<menu_destroy.isra.0+12>
End of assembler dump.
--
Regards,
Yang Xiwen
More information about the U-Boot
mailing list