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 <[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.
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
signature.asc
Description: PGP signature
