[RFC PATCH v2 1/7] ARM: zte: Add zx297520v3 platform support.

[Stefan Dösinger]

Hi Linus,

Thanks for the replies!

Am Freitag, 30. Januar 2026, 12:07:41 Ostafrikanische Zeit schrieb Linus 
Walleij:

> The practice to run 32bit kernels on 64bit capable hardware has been
> pushed back in the past. When you say "they run aarch32 mode only" this
> sounds like a choice, not a mandatory demand from the hardware, i.e.
> it *could* run in 64bit mode.

I think ZTE could certainly have built this board + software in a way that 
runs in 64 bit mode yes. I am pessimistic that we can do this ourselves with 
purely software means.

> We can see why the vendor does this because the board has only 64MB
> of memory, and 64bit code is known to take up more memory.
> 
> What we recommend is usually to run a 64bit kernel with a 32bit userspace,
> so the userspace still isn't too demanding in memory.
> 
> Have you been able to try this?
> 
> If it seems hard we might need to bring people in who can help with
> enabling 64bit mode for the kernel.

Andre Przywara suggested switching to 64 bit via the Reset Management 
Register. The RMR seems to do nothing on this hardware (https://
lists.infradead.org/pipermail/linux-arm-kernel/2026-January/1099787.html is my 
reply in the archives).

We don't have board schematics or datasheets, but I guess AA64nAA32 is 
hardwired to 32 bit. Maybe a GPIO pin can control it, but it doesn't look like 
it. We also know of no way to reset the CPU without resetting the rest of the 
board. (since RMR doesn't seem to work)

In my previous research I came across the suggestion to do an eret from EL3 to 
EL3 and set SCR_EL3.RW to 1. We'd obviously need to set ELR_EL3 to point to 64 
bit code. However, I haven't actually seen a working example of that and my 
own attempts just ended up locking up the CPU. I don't know where I came 
across the suggestion the first time. All I can find right now is this 
article, which is clearly AI slop: https://www.systemonchips.com/switching-from-aarch32-to-aarch64-on-cortex-a55-challenges-and-solutions/ .

Do you have any other ideas we could try?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260130/4ee749a6/attachment.sig>