Re: [PATCH v4 7/8] clk: sunxi-ng: a733: Add bus clock gates

["Junhui Liu" <junhui.liu@pigmoral.tech>]

Hi Enzo,
Thank you for the detailed information.

On Sun Sep 27, 2026 at 5:02 AM CST, Enzo Adriano wrote:
> Hi Junhui,
>
> Attached are the exact minimal board DTS and SoC DTSI used for both runs,
> plus the configuration extracted from the tested Image and reproduction
> notes. I rebuilt the DTB from the recorded source and recovered config;
> it matches the tested 4497-byte DTB byte-for-byte (SHA-256):
>
>   4c7b762757392334e8b7ac525e60bf5757ec23b34efdcc949d2093c238b1ed16
>
> The support archive contains the two local integration/comparator diffs,
> the four A733 clock/reset headers, source history and short UART excerpts.
> Applying the 19 published patches and these local diffs to v7.3-rc1
> reproduces the tested source tree. This is the minimal diagnostic DT,
> not my newer DTS work; its fixed card supply is part of that test setup.
>
> Both the September 21 failing run and September 26 clk_ignore_unused run
> report identical firmware banners:
>
>   U-Boot 2018.07-12-boot-aw2501-gb2d229198b2-dirty
>   (Jan 06 2026 - 03:45:33 +0000) Allwinner Technology
>   BL31: v2.5(debug):5fc237a6a
>   BL31: Built : 09:05:28, Feb 26 2025

I have now successfully reproduced the issue using the same vendor boot
firmware version. The root cause is that the vendor U-Boot selects
pll-periph0-480M as the parent of the GIC clock. However, the current
Linux A733 CCU driver does not model the GIC clock, so the common clock
framework considers pll-periph0-480M unused and disables it during late
initialization. This stops the GIC and causes the system to hang.

I will model the GIC clock properly in the next version and mark it as
CLK_IS_CRITICAL. Although the GIC node can reference this clock in the
device tree, the generic GICv3 driver currently ignores the clock
property and therefore does not acquire or enable it.

>
> These tests used the vendor firmware already installed on the A7S;
> I did not build or flash U-Boot or TF-A for them. Unfortunately, I cannot
> establish the original installation/download image, the U-Boot dirty
> delta, or the BL31 source/build inputs. I also do not have verified hashes
> of the installed firmware binaries. Earlier source-correlation records
> point to Radxa's downstream U-Boot, but the retained candidate build is
> a different revision and is not a reproducible source for this firmware.
>
> reproduce.txt includes the actual ext4load/booti commands and bootargs.
> In particular, I set the U-Boot environment variable drm_debug=1 as well
> as including it in bootargs. U-Boot reports FDT fixup errors and "update
> dts" before Linux, also on the successful run; the excerpts retain those
> messages. The DTB hash above describes the file loaded into RAM. I did
> not capture the final post-fixup tree passed to Linux, so I cannot yet
> rule out a firmware or DT-fixup difference from your A7A.

Thanks again for providing the exact test setup. It was essential for
identifying the difference between the mainline and vendor U-Boot
behavior.

>
> Assisted-by: Codex:gpt-6
>
> Regards,
> Enzo

-- 
Best regards,
Junhui Liu