[PATCH v4 7/8] clk: sunxi-ng: a733: Add bus clock gates
Enzo Adriano
enzo.adriano.code at gmail.com
Mon Sep 21 13:05:12 PDT 2026
Hi Junhui,
I tested the exact v4 series on a Radxa Cubie A7S. I used v7.3-rc1,
applied the four-patch A523 single-divider prerequisite, this eight-patch
series, and Andre's current seven-patch A733 pinctrl series. The test DT is
a minimal Cubie A7S harness with the main and R CCUs, RTC, pinctrl, UART0,
and MMC0. The Image, DTB, and initramfs were loaded into RAM from U-Boot.
The exact posted stack starts all eight CPUs, probes the RTC and the A733
pinctrl driver, and binds UART0. Serial output then stops immediately after
the 8250 driver replaces the boot console:
sun60i-a733-pinctrl 2000000.pinctrl: initialized sunXi PIO driver
printk: console [ttyS0] disabled
2500000.serial: ttyS0 MMIO32:0x0000000002500000 ... is a 16550A
printk: console [ttyS0] enabled
printk: legacy bootconsole [uart8250] disabled
It never reaches the initramfs `/bin/sh` readiness line. There is no panic or
oops in the captured output.
As a private comparator, I changed only `ahb_cpus_clk` at 0x5c0 bit 28 to
`CLK_IS_CRITICAL`. That advances the same build to:
clk: Disabling unused clocks
but serial output stops there and PID 1 is still not reached. I also added
private begin/done tracing around each individual enabled clock in
`clk_disable_unused_subtree()`. Neither trace marker appears, so the second
loss occurs before the first individual unused-clock disable is attempted.
Each run used the same RAM-only payload and was followed by an
identity-checked 120-second power recovery. The board returned to its exact
vendor kernel and eMMC root after all three runs.
So I cannot add a Tested-by for v4 as posted. The `ahb-cpus` gate appears to
be one issue, but marking it critical is not sufficient on this board. Could
you please check the CPUS/AHB dependency and the path entered immediately
after `clk: Disabling unused clocks`? I can retest a focused change or v5 on
the Cubie A7S.
Assisted-by: Codex:gpt-5
I reviewed this report and take responsibility for its contents.
Regards,
Enzo
More information about the linux-arm-kernel
mailing list