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

Arnd Bergmann arnd at arndb.de
Fri Jan 30 00:58:40 PST 2026


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

>> 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.

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



More information about the linux-arm-kernel mailing list