Re: [PATCH v5 0/8] clk: sunxi-ng: Add support for Allwinner A733 CCU and PRCM

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

Hi Norman,

Thanks for testing this. You saved my A7Z board from an almost certain
sacrifice. :)

On Sat Oct 3, 2026 at 11:05 PM CST, Norman Herms wrote:
> Hi Junhui,
>
>> Thanks for pointing this out. This is indeed something I had not
>> considered before. I will try enabling secure boot on my spare Cubie A7Z
>> board and test it on actual hardware.
>
> First a correction to my earlier reply in this thread. I answered
> ChenYu's "presumably ... the secure/non-secure access bit isn't in
> effect" with "yes" and quoted the UM note that these registers are
> always non-secure in non-security mode. On our non-fused A7S boards
> (SID + 0xA0 = 0, also when read from EL3) that does not hold for every
> register. Read from EL3 with a test BL31, CCMU_SEC_SWITCH_REG is 0x7
> after BL31's security setup, S_TWD_BGR_REG is 0x1 and the SPC status
> registers are 0xffffffff, but from non-secure all of them read 0, and
> non-secure writes to the first two do not stick. So secure filtering
> is active on these parts even without the fuse.

I will double-check this on my side and add the relevant comments as
Chen-Yu suggested.

>
>> For the PLL and AHB/APB bus clock controls, the user manual indicates
>> that the relevant security bits can be set by TF-A to allow the kernel
>> to access these registers. This also appears to be how this has
>> traditionally been handled on sunxi platforms. So I think we can do the
>> same in TF-A for the A733.
>
> That is what the BL31 on our boards does: PRCM_SEC_SWITCH_REG |= 0x7
> and 0x7 to CCMU_SEC_SWITCH_REG at CCU + 0x1F00, as the vendor BL31
> does. From EL3 both read 0 before and 0x7 after. The 0x1F00 versus
> 0x0F00 trap in the A733 TF-A port is in my first reply.
>
>> For bus_r_twd_clk, I will test whether the register is indeed always
>> secure. If it is, I think the clock can be removed from the kernel and
>> left enabled by its hardware reset value or by the boot firmware.
>
> On our non-fused boards it is already inaccessible from the non-secure
> side (reads 0, writes ignored). From EL3 it reads 0x1, the UM default,
> so the gate is open. Details are in my reply to ChenYu on patch 3/8,
> which crossed with yours.

Understood. This bus gate is therefore not meaningful to the kernel,
so I will remove the clock in the next version.

>
> Same boards and caveats as before: AI agents (Claude) on my boards, a
> report, not a Tested-by.
>
> Thanks,
> Norman

-- 
Best regards,
Junhui Liu