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

[Stefan Dösinger]

Am Donnerstag, 29. Januar 2026, 01:00:08 Ostafrikanische Zeit schrieb Arnd 
Bergmann:
> On Wed, Jan 28, 2026, at 21:34, Stefan Dösinger wrote:

> I assume that you were in EL3 when you tried to write to NSACR?
> From EL2/EL1 it would still appear the same as not-implemented
> even if it is there but disabled in EL3.
Yes, and I just double checked, it does read 0 in all cases. Here's what I did 
- abusing the head.S error handling code a bit for printing:

cps	#MON_MODE
mrc	p15, 0, r9, c1, c1, 2
b	__error_p			@ abuse for print
Error: unrecognized/unsupported processor variant (0x00000000).

cps	#MON_MODE
ldr	r1, =0x63fff
mcr	p15, 0, r1, c1, c1, 2
mrc	p15, 0, r9, c1, c1, 2
b	__error_p
Error: unrecognized/unsupported processor variant (0x00000000).

And just to make sure I didn't get __error_p wrong:

cps	#MON_MODE
ldr	r9, =0xdeadbeef
b	__error_p
Error: unrecognized/unsupported processor variant (0xdeadbeef).

I am certain switching to EL3 is working here because I am using it in the 
same way to set up ICC_SRE_EL*. (And yes, I know this code doesn't belong in 
this place. It's just more comfortable for my development tree for now)

> I've never seen a Cortex-A53 without FPU and NEON, but since this
> is optional, it was a matter of time before we got one ;-)

The ZTE 3.4 kernel code suggests that there is/was a zx297520v2 that was 
Cortex A9 based, and then ZTE replaced the Cortex-A9 with a Cortex-A53 and 
left the rest of the system unchanged.

A later version of this SoC, zx298501 switched to 64 bit, including kernel + 
userland. But I don't have any hardware based on either of them.

> Support for 64-bit cores is actually quite rudimentary in 32-bit
> more, as we are missing a lot of the errata workarounds and ARMv8
> specific features in the kernel. If you can figure out how to
> use 64-bit kernel mode, that would be ideal.

One of my co-hackers is giving it another try. Pairing a 64 bit kernel with 32 
bit userspace seems reasonable. Of course the other question is what quirks 
are hiding in the hardware when we run them in a mode the vendor never tested.

> > 6) The old removed zx29 code used "zte," as the vendor for the
> > compatibles. Sanechips is a subsidiary of ZTE that designed these chips.
> > Are there any preferences for either "zte," or "sanechips,"?
> 
> I would stay with the previously used one

Check

Cheers,
Stefan
-------------- 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/20260129/af28dcdd/attachment.sig>