From: "Stefan Dösinger" <stefandoesinger@gmail.com>
To: Linus Walleij <linusw@kernel.org>, Jun Nie <jun.nie@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org, soc@lists.linux.dev,
Arnd Bergmann <arnd@arndb.de>, Drew Fustini <fustini@kernel.org>
Subject: Re: [RFC PATCH v2 1/7] ARM: zte: Add zx297520v3 platform support.
Date: Fri, 30 Jan 2026 19:37:53 +0300 [thread overview]
Message-ID: <1848649.VLH7GnMWUR@strix> (raw)
In-Reply-To: <CAD++jLn+ipz62Miki7VZNa_QestDNMtzmFK_zdLcY4deCweG8w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
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?
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
next prev parent reply other threads:[~2026-01-30 16:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 20:34 [RFC PATCH v2 0/7] Add support for ZTE zx297520v3 Stefan Dösinger
2026-01-28 20:34 ` [RFC PATCH v2 1/7] ARM: zte: Add zx297520v3 platform support Stefan Dösinger
2026-01-30 9:07 ` Linus Walleij
2026-01-30 16:37 ` Stefan Dösinger [this message]
2026-02-02 9:09 ` Linus Walleij
2026-02-02 17:38 ` Stefan Dösinger
2026-01-28 20:34 ` [RFC PATCH v2 2/7] dt-bindings: arm: Add zx297520v3 board binding Stefan Dösinger
2026-01-28 20:34 ` [RFC PATCH v2 3/7] ARM: dts: Add D-Link DWR-932M support Stefan Dösinger
2026-01-28 20:34 ` [RFC PATCH v2 4/7] ARM: zte: Add support for zx29 low level debug Stefan Dösinger
2026-01-28 20:34 ` [RFC PATCH v2 5/7] ARM: dts: Add an armv7 timer for zx297520v3 Stefan Dösinger
2026-01-28 20:34 ` [RFC PATCH v2 6/7] ARM: zte: Bring back ZX29 UART support Stefan Dösinger
2026-01-28 20:34 ` [RFC PATCH v2 7/7] ARM: dts: Declare UART1 on zx297520v3 boards Stefan Dösinger
2026-01-28 22:00 ` [RFC PATCH v2 0/7] Add support for ZTE zx297520v3 Arnd Bergmann
2026-01-29 19:38 ` Stefan Dösinger
2026-01-30 8:58 ` Arnd Bergmann
2026-01-30 10:17 ` Linus Walleij
2026-01-30 14:08 ` Robin Murphy
2026-01-30 14:02 ` Andre Przywara
2026-01-30 15:02 ` Stefan Dösinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1848649.VLH7GnMWUR@strix \
--to=stefandoesinger@gmail.com \
--cc=arnd@arndb.de \
--cc=fustini@kernel.org \
--cc=jun.nie@linaro.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=soc@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox