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

[Arnd Bergmann]

On Wed, Jan 28, 2026, at 21:34, Stefan Dösinger wrote:

> 4) The CPU is a Cortex A53 running in arm32 mode (in the shipped firmware 
> too). It doesn't appear to have an FPU. Reading FPSID results in an 
> exception (so vfpmodule.c/vfp_init says VFP is not available). I tried 
> enabling p10 and p11 in NSACR, but without success. NSACR seems to always 
> read 0 too. Is this really a Cortex A53 without FPU or did I miss 
> something?

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

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.

> 5) Relatedly, are there any advantages to running in arm64 mode? The 
> devices are relatively memory constrained (64mb), so the larger binary 
> size from 64 bit pointers is probably a negative, while the larger 
> register set might be a positive. I doubt switching to arm64 mode is 
> possible at all, but I'm nevertheless curious.

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. There is a
noticeably higher memory usage even with 32-bit userspace though,
so you'd lose several megabytes of memory as you said, and 64-bit
userspace would be impossible since the aarch64 toolchain only
supports hardfloat.

You would also have to deal with a practical problem in OpenWRT,
which as far as I know does not support building kernel
and userland with different toolchains.

> 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

      Arnd