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

[Linus Walleij]

[Sorry for missing this discussion on 0/7 and posting on 1/7 instead]

On Fri, Jan 30, 2026 at 9:59 AM Arnd Bergmann <arnd at arndb.de> wrote:
> On Thu, Jan 29, 2026, at 20:38, Stefan Dösinger wrote:

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

Would it be possible that the DRAM IP on the next version could not
even deal with such a small memory (64MB) making the in-between
SoC a desireable choice?

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

I'm checking with Suzuki to see if he has tested that recently.

Yours,
Linus Walleij