[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