[RFC PATCH v2 0/7] Add support for ZTE zx297520v3

[Stefan Dösinger]

Am Freitag, 30. Januar 2026, 17:02:16 Ostafrikanische Zeit schrieben Sie:
> Hi Stefan,
> > 1) The GIC is a GICv3, but there are some extra registers (probably on a
> > different chip) to switch PPIs and SPIs between level high/level low or
> > rising edge/falling edge.
> 
> Wouldn't it be possible to fix this up in firmware and not bother the
> kernel with it? It would treat this like some very platform specific
> setup, as there is probably also very little point it ever doing it any
> other way?

Yes, this is certainly possible, and it is in a way what I am doing right now. 
As far as I understand the hardware I won't have to switch this at runtime, it 
just needs a sane default.

> The arm64 booting.rst specifies the expectations of the kernel very
> clearly, for instance it demands the GIC to be setup correctly and be
> booted in non-secure state. The arm(32) kernel was much more forgiving,
> mostly because many firmwares couldn't be fixed, so there was no choice.
> But I feel like for "new" devices we should lean on the safe side and
> use the firmware to bring the system in a sane state (pun intended).
> 
> It looks like you have access to the firmware and can change it?

Yes, we can replace Uboot on the NAND and boot our own via USB as well. ZTE 
actually provided uboot sources too. And I can certainly add some preload code 
into uimages to fix up registers, so these kinds of setup quirks won't go into 
the main kernel.

How we handle this for user-installable systems is still open. It depends on 
the risk of producing a bricked device. But we certainly have options.

And yes, they are begging to be called "insanechips" :-)

> > 3) The SoC has clock and reset controls in the same MMIO space, even the
> > same 32 bit registers. What is the preferred way to handle this? Two
> > separate clk and reset drivers that write into the same place? One
> > multifunction driver that exposes clock and resets? One syscon that
> > contains the reg values and two separate clk and reset drivers that
> > consume the syscon?
> 
> That's quite common, and the solution is to have one driver, that acts
> as both a clock and reset controller (registers to both subsystems).
> Look at sunxi, for instance (from the sun50i-a64.dtsi):

Thanks for the pointer, I'll use this as guidance.

> Allwinner cores also reset into EL3/AArch32, there an RMR reset brings
> it into AArch64 state. For this to work Allwinner provides a writable
> MMIO register that backs the architecturally read-only RVBAR, so you can
> program the AArch64 entry point.
> https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/rmr_switch.
> S Not sure if this works here, of course, but just FYI.
> In any case I feel this beast is better left in arm32 land ;-)

We tried to do something similar. We can actually change RVBAR and read back 
the changed value - and the value becomes 32 byte aligned. However, writing to 
RMR doesn't seem to do anything. The CPU just continues to execute the next 
instruction. I can even read it back later

What I'm doing in EL3:
mrc	15, 0, r0, cr12, cr0, 2	@ read RMR register
orr	r0, r0, #2			@ request reset in AArch32
mcr	15, 0, r0, cr12, cr0, 2 	@ write RMR register
isb	sy

and it merrily continues executing after that. It does that with or without 
the attempt to set RVBAR. If RMR worked I'd at least expect the hardware to 
crash in some way, not go back to the interactive uboot prompt (which 
continues to work fine). I also tried to set bits 0 and 1 (reset to aarch64) 
or set all 32 bits. There's no observable change.

We don't have any board schematics or datasheets, but I assume the 32/64 mode 
pin is wired to arm32. It may be controllable by one of the GPIOs, but I doubt 
that. So far we don't know of a way to reset the main CPU without resetting 
the entire board either.

The third way I read about was to attempt to return from 32 bit EL3 to 64 bit 
EL3, but I think I ran into some AI hallucination there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260130/754b598d/attachment.sig>