On Thu, Jan 2, 2025, at 19:34, Jiaxun Yang wrote:
> Why am I upstreaming LoongArch32?
> ================================
> Although 32-bit systems are experiencing declining adoption in general
> computing, LoongArch32 remains highly relevant within specific niches.
> Beyond embedded applications, several vendors are actively developing
> application-level LoongArch32 processors. Loongson, for example, has
> released two open-source reference hardware implementations: openLA500
> and openLA1000 [6].
>
> The architecture also holds considerable educational value, having been
> integrated into China's national computer architecture curricula and
> embedded systems courses. Additionally, the National Student Computer
> System Capability Challenge (NSCSCC) [1] features LoongArch32 CPUs, where
> hundreds of students design Linux-capable hardware implementations and
> compete on performance. This initiative has resulted in several exciting
> high-performance LoongArch32 cores, including LainCore[2], Wired[3],
> NOP-Core[4], NagiCore[5]....
I'm surprised that so many resources get put into 32-bit hardware
implementations on loongarch, when this has mostly stopped on riscv
and arm, where new hardware is practically all either 64-bit Linux
or 32-bit NOMMU microcontrollers.
> From an upstream perspective, we will largely reuse the infrastructure
> already established for LoongArch64, ensuring that the maintenance burden
> remains minimal.
>
> Porting Status
> ==============
> The LoongArch32 port has been available downstream for some time, with
> various system components hosted on Loongson's Gitee[6]. However, these
> components utilise an older downstream ABI and fall short of upstream
> quality.
>
> On the upstream front, LLVM-19 now includes experimental support for
> LoongArch32 (ILP32 ABI) under the loongarch32* triple, and efforts are
> underway to enable GNU toolchain support. My upstream-ready kernel port
> and musl libc port can successfully boot into a minimal Buildroot
> environment and execute test cases on QEMU virt machine with clang
> toolchain.
I assume the MIPS legacy means that a 64-bit kernel is going to be
able to run the same ILP32 binaries as a 32-bit kernel running on
pure 32-bit hardware, similar to powerpc/s390/x86, but unlike
riscv/arm?
We need to be careful in defining the ABI to ensure that this covers
all the corner cases, such as defining a signal stack layout with
room to save 64-bit user register contents if there is a chance that
a 32-bit userspace will end up using the wide registers when
running on a 64-bit kernel, but also avoid any dependency on 64-bit
registers in the ABI itself.
Arnd
