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

[Robin Murphy]

On 2026-01-30 8:58 am, Arnd Bergmann wrote:
> On Thu, Jan 29, 2026, at 20:38, Stefan Dösinger wrote:
>> 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 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)
> 
> Ok

If you can do that, then:

a) You're starting in Secure SVC, which explains the GIC issues (since 
we usually expect to be dealing with the Non-Secure side of the GIC)

b) Monitor mode exists, which means EL3 is in AArch32 state (and I would 
imagine the SoC is wired to boot that way), which means you'd need to 
rewrite the entire firmware for AArch64 (most likely including an 
AArch32 stub to RMR itself into AArch64 state initially) before you 
could consider running lower ELs in AArch64.

>>> 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 ;-)

They certainly exist in various networking gear and other embedded 
applications, they've just never (directly) asked to run mainline Linux ;)

Cheers,
Robin.

>> 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.
> 
> Right, it's quite possible that v3 was a node shrink and Cortex-A9
> was not available for the new process.
> 
>>> 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.
> 
> Right, that is clearly a risk. I see that we do support FPU-less
> systems, e.g. 82e0191a1aa1 ("arm64: Support systems without
> FP/ASIMD"), but I doubt that this code path is well tested.
> 
> For the core itself, I would expect fewer problems with 64-bit
> kernels than 32-bit ones, but the problems are going to be different
> of course.
> 
> For 32-bit compat userspace, there is a chance that you have
> device drivers missing compat ioctl handlers, especially if you
> need non-upstream drivers. There are also a few differences in
> handling of deprecated instructions like ARMv6 style barriers
> or unaligned ldm/stm data accesses, which require you to enable
> the workarounds at boot time on 64-bit kernels.
> 
>       Arnd
>