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 <[email protected]>
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@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@fa10000: 0, mmc@fa00000: 1, mmc@fa20000: 2
Loading Environment from nowhere... OK
In: serial@2800000
Out: serial@2800000
Err: serial@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
