[PATCH v3 0/6] clk: support arbitrary clk_register() sequence
Tom Rini
trini at konsulko.com
Mon Feb 9 15:23:05 CET 2026
On Sat, Feb 07, 2026 at 10:58:16PM +0800, Yang Xiwen wrote:
> 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.
I can send you the binaries if needed, off-list. But the likely answer
is that we're on the a53 part of the system and not the r5 part of the
system at this point.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260209/92611924/attachment.sig>
More information about the U-Boot
mailing list