[gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[WANG Xuerui]

Hi everyone,

I'm your average Gentoo user who obviously thought his sleeping time is more
than enough, and just decided to start porting Gentoo to LoongArch. As this
is such a niche architecture with no upstreamed support so far, I'm posting
this to announce my intent and gather advice on how to best push this.

I'll first give some background material to help people gain context, then
describe my porting plan. This is going to be a bit long; apologizes for 
that.


Note: I'm not affiliated with Loongson in any way; I'm just doing this in my
spare time (once meant for some quality sleep).


## A bit of introduction on the LoongArch

LoongArch, as its name implies, is the brand-new ISA developed by the
Loongson Corporation, incompatible with MIPS which was implemented by
all previous Loongson processors. Currently only the base ISA specification
is publicly available; it has fixed-length 32-bit instructions, vastly more
instruction formats (39 distinct formats in the base ISA alone!), and its
instruction semantics mostly resemble RISC-V, with a bit of MIPS R6 here and
there. It is capable of 64-bit operations, obviously.

ISA documentation: https://github.com/loongson/LoongArch-Documentation
ELF psABI draft: https://github.com/loongson/LoongArch-Documentation/pull/3

The draft ABI is undergoing fierce review, and is subject to change,
especially the relocation types. Other parts like the register 
convention and
data layout is unlikely to change much, though.

There is little code upstreamed for basic software (GNU toolchain, QEMU,
Linux and the like), but many are open-sourced already. Nevertheless, the
code quality is still very much inferior, and much of it is obviously based
on respective MIPS support. There is continuous debate inside and outside
Loongson on this matter, too.

Kernel ABI and glibc code seems to be inspired by RISC-V, but still some
parts show MIPS heritage. The kernel bits are being reviewed on the 
linux-arch
mailing list.

All of the projects above can be accessed at https://github.com/loongson.

Loongson 3A5000 is the first LoongArch CPU; the Lemote A2101 board with this
CPU can be bought in China for ~4000 CNY already.


## Gentoo porting plans

I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI
first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
priority.

The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun
semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to
suggestions.

Because much of the ABI and even some toolchain internals are going through
VERY fierce debate and rework, obviously the port will remain experimental
for a long time. Some minimal support should get in tree though; doing so
would ease a lot of pain for experimentation. I already hacked my way to
generate working crossdev toolchains, and is halfway towards a rootfs with
working Python (and Portage). I've already independently ported strace, and
plan to do the same to libffi in the coming days which would give me Python.

I'll do all work in my own loongson-overlay first, and upstream these when
appropriate. Eventually I hope to have working crossdev, qemu-user emulation
and proper catalyst support.


And that's about all; the message is getting long! Your opinions are 
welcome,
and thanks again for following along.


Regards,
WANG "xen0n" Xuerui

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Thu, Aug 12, 2021 at 12:39:33AM +0800, WANG Xuerui wrote:
> I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI
> first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
> priority.

> 
> The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun
> semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to
> suggestions.

FWIW, I like loong and ABI_LOONG better, or even better would be to use the
string `uname -m` returns for the hardware as ARCH and as the suffix for
ABI_.

William

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[WANG Xuerui]

On 8/12/21 02:13, William Hubbs wrote:

> On Thu, Aug 12, 2021 at 12:39:33AM +0800, WANG Xuerui wrote:
>> I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI
>> first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
>> priority.
>> The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun
>> semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to
>> suggestions.
> FWIW, I like loong and ABI_LOONG better, or even better would be to use the
> string `uname -m` returns for the hardware as ARCH and as the suffix for
> ABI_.

Ahh I forgot to mention that...

$ uname -m
loongarch64

And the triple is "loongarch64-unknown-linux-gnu"; kernel port sits at 
arch/loongarch; almost everything except Go uses the "loongarch" 
version. Go people didn't like duplicating "arch" for their GOARCH 
value, so it's "GOARCH=loong64" there, otherwise the Loongson people 
pushing their agenda would have used "loongarch64" too.

I would say this is mostly aesthetic matter, because we have equally 
long ARCH names like "microblaze" or "openrisc" too. From a user's 
perspective I'd personally prefer "loong" to save some typing, but 
"loongarch" wouldn't hurt that much either.

>
> William

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[Michał Górny]

On Thu, 2021-08-12 at 09:21 +0800, WANG Xuerui wrote:
> On 8/12/21 02:13, William Hubbs wrote:
> 
> > On Thu, Aug 12, 2021 at 12:39:33AM +0800, WANG Xuerui wrote:
> > > I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI
> > > first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
> > > priority.
> > > The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun
> > > semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to
> > > suggestions.
> > FWIW, I like loong and ABI_LOONG better, or even better would be to use the
> > string `uname -m` returns for the hardware as ARCH and as the suffix for
> > ABI_.
> 
> Ahh I forgot to mention that...
> 
> $ uname -m
> loongarch64
> 
> And the triple is "loongarch64-unknown-linux-gnu"; kernel port sits at 
> arch/loongarch; almost everything except Go uses the "loongarch" 
> version. Go people didn't like duplicating "arch" for their GOARCH 
> value, so it's "GOARCH=loong64" there, otherwise the Loongson people 
> pushing their agenda would have used "loongarch64" too.
> 
> I would say this is mostly aesthetic matter, because we have equally 
> long ARCH names like "microblaze" or "openrisc" too. From a user's 
> perspective I'd personally prefer "loong" to save some typing, but 
> "loongarch" wouldn't hurt that much either.
> 

I think following upstream (i.e. "loongarch" convention) is better.
We have already caused some mess with custom names like "arm64".

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

>>>>> On Thu, 12 Aug 2021, Michał Górny wrote:

> On Thu, 2021-08-12 at 09:21 +0800, WANG Xuerui wrote:
>> I would say this is mostly aesthetic matter, because we have equally 
>> long ARCH names like "microblaze" or "openrisc" too. From a user's 
>> perspective I'd personally prefer "loong" to save some typing, but 
>> "loongarch" wouldn't hurt that much either.

> I think following upstream (i.e. "loongarch" convention) is better.
> We have already caused some mess with custom names like "arm64".

Can we please keep these identifiers short? Currently all ARCH names are
5 characters at most (except prefix, of course). The total length of the
KEYWORDS line isn't the main issue here, but tools like eshowkw or
tables in the various web interfaces.

It is also in GLEP 53 if you need a formal reference:
"Note that no limit on the length of both fields in the keyword are
imposed. However, we cannot overemphasize our preference to keep
keywords small and sensible."

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[Yixun Lan]

HI Xuerui:

This must be a *HUGE* project and gonna put lots of effort in to it!
So, first, good luck to you with all my best wishes!~

On 00:39 Thu 12 Aug     , WANG Xuerui wrote:
> Hi everyone,
> 
> I'm your average Gentoo user who obviously thought his sleeping time is more
> than enough, and just decided to start porting Gentoo to LoongArch. As this
> is such a niche architecture with no upstreamed support so far, I'm posting
> this to announce my intent and gather advice on how to best push this.
> 
> I'll first give some background material to help people gain context, then
> describe my porting plan. This is going to be a bit long; apologizes for 
> that.
> 
> 
> Note: I'm not affiliated with Loongson in any way; I'm just doing this in my
> spare time (once meant for some quality sleep).
> 
> 
> ## A bit of introduction on the LoongArch
> 
> LoongArch, as its name implies, is the brand-new ISA developed by the
> Loongson Corporation, incompatible with MIPS which was implemented by
> all previous Loongson processors. Currently only the base ISA specification
> is publicly available; it has fixed-length 32-bit instructions, vastly more
> instruction formats (39 distinct formats in the base ISA alone!), and its
> instruction semantics mostly resemble RISC-V, with a bit of MIPS R6 here and
> there. It is capable of 64-bit operations, obviously.
> 
> ISA documentation: https://github.com/loongson/LoongArch-Documentation
> ELF psABI draft: https://github.com/loongson/LoongArch-Documentation/pull/3
> 
> The draft ABI is undergoing fierce review, and is subject to change,
> especially the relocation types. Other parts like the register 
> convention and
> data layout is unlikely to change much, though.
> 
> There is little code upstreamed for basic software (GNU toolchain, QEMU,
> Linux and the like), but many are open-sourced already. Nevertheless, the
> code quality is still very much inferior, and much of it is obviously based
> on respective MIPS support. There is continuous debate inside and outside
> Loongson on this matter, too.
> 
Didn't do any investigation, but if I read correctly, also see here [1]

The fundamental pieces of softwares are open-sourced but *NOT* yet upstreamed
So, I'd say, let's wait till it's actually accepted by upstream,
before pushing to downsteam (Gentoo here). Sure, you're free to send
a pull-request for review/comment, but collect peices under your own overlay
would be a good idea ( in my humble opition ).


> Kernel ABI and glibc code seems to be inspired by RISC-V, but still some
> parts show MIPS heritage. The kernel bits are being reviewed on the 
> linux-arch
> mailing list.
> 
> All of the projects above can be accessed at https://github.com/loongson.
> 
> Loongson 3A5000 is the first LoongArch CPU; the Lemote A2101 board with this
> CPU can be bought in China for ~4000 CNY already.
> 
> 
> ## Gentoo porting plans
> 
> I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI
> first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
> priority.
> 
start with LP64 would be good idea, so same as RISC-V here.

> The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long (pun
> semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to
> suggestions.
> 
> Because much of the ABI and even some toolchain internals are going through
> VERY fierce debate and rework, obviously the port will remain experimental
> for a long time. Some minimal support should get in tree though; doing so
> would ease a lot of pain for experimentation. I already hacked my way to
> generate working crossdev toolchains, and is halfway towards a rootfs with
> working Python (and Portage). I've already independently ported strace, and
> plan to do the same to libffi in the coming days which would give me Python.
> 
> I'll do all work in my own loongson-overlay first, and upstream these when
> appropriate. Eventually I hope to have working crossdev, qemu-user emulation
> and proper catalyst support.
> 
> 
sounds a good plan, first start with making cross compiling work, then try to 
populate a mini rootfs (kernel, glibc, base system), then python, portage


> And that's about all; the message is getting long! Your opinions are 
> welcome,
> and thanks again for following along.
> 
> 

[1] https://github.com/gentoo/portage/pull/740#issuecomment-895021854

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[WANG Xuerui]

Hi Yixun,

On 2021/8/12 17:55, Yixun Lan wrote:
> HI Xuerui:
>
> This must be a *HUGE* project and gonna put lots of effort in to it!
> So, first, good luck to you with all my best wishes!~
Thanks for your kindness!
>
> On 00:39 Thu 12 Aug     , WANG Xuerui wrote:
>> Hi everyone,
>>
>> I'm your average Gentoo user who obviously thought his sleeping time is more
>> than enough, and just decided to start porting Gentoo to LoongArch. As this
>> is such a niche architecture with no upstreamed support so far, I'm posting
>> this to announce my intent and gather advice on how to best push this.
>>
>> I'll first give some background material to help people gain context, then
>> describe my porting plan. This is going to be a bit long; apologizes for 
>> that.
>>
>>
>> Note: I'm not affiliated with Loongson in any way; I'm just doing this in my
>> spare time (once meant for some quality sleep).
>>
>>
>> ## A bit of introduction on the LoongArch
>>
>> LoongArch, as its name implies, is the brand-new ISA developed by the
>> Loongson Corporation, incompatible with MIPS which was implemented by
>> all previous Loongson processors. Currently only the base ISA specification
>> is publicly available; it has fixed-length 32-bit instructions, vastly more
>> instruction formats (39 distinct formats in the base ISA alone!), and its
>> instruction semantics mostly resemble RISC-V, with a bit of MIPS R6 here and
>> there. It is capable of 64-bit operations, obviously.
>>
>> ISA documentation: https://github.com/loongson/LoongArch-Documentation
>> ELF psABI draft: https://github.com/loongson/LoongArch-Documentation/pull/3
>>
>> The draft ABI is undergoing fierce review, and is subject to change,
>> especially the relocation types. Other parts like the register 
>> convention and
>> data layout is unlikely to change much, though.
>>
>> There is little code upstreamed for basic software (GNU toolchain, QEMU,
>> Linux and the like), but many are open-sourced already. Nevertheless, the
>> code quality is still very much inferior, and much of it is obviously based
>> on respective MIPS support. There is continuous debate inside and outside
>> Loongson on this matter, too.
>>
> Didn't do any investigation, but if I read correctly, also see here [1]
>
> The fundamental pieces of softwares are open-sourced but *NOT* yet upstreamed
> So, I'd say, let's wait till it's actually accepted by upstream,
> before pushing to downsteam (Gentoo here). Sure, you're free to send
> a pull-request for review/comment, but collect peices under your own overlay
> would be a good idea ( in my humble opition ).

Sure; that's basic etiquette. However there are some parts that
definitely need upstreaming, otherwise complexity could explode; for
example, the multilib_env function and tc-ninja_magic_to_arch function.
Without fixing multilib_env we could only use the "default" ABI, and
without adapting tc-ninja_magic_to_arch even linux-headers is unable to
build. If we don't touch the upstream repo, a full fork is needed, and
that's going to be painful.

Additionally, I've already seen adaptations for experimental arches in
repo; so I thought upstreaming these minimal bits would be acceptable.
If that's deemed too early (and I totally understand the reasoning
behind that), doing work in forks is okay from my side.

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[WANG Xuerui]

On 8/12/21 14:39, Ulrich Mueller wrote:

>>>>>> On Thu, 12 Aug 2021, Michał Górny wrote:
>> On Thu, 2021-08-12 at 09:21 +0800, WANG Xuerui wrote:
>>> I would say this is mostly aesthetic matter, because we have equally
>>> long ARCH names like "microblaze" or "openrisc" too. From a user's
>>> perspective I'd personally prefer "loong" to save some typing, but
>>> "loongarch" wouldn't hurt that much either.
>> I think following upstream (i.e. "loongarch" convention) is better.
>> We have already caused some mess with custom names like "arm64".
> Can we please keep these identifiers short? Currently all ARCH names are
> 5 characters at most (except prefix, of course). The total length of the
> KEYWORDS line isn't the main issue here, but tools like eshowkw or
> tables in the various web interfaces.
>
> It is also in GLEP 53 if you need a formal reference:
> "Note that no limit on the length of both fields in the keyword are
> imposed. However, we cannot overemphasize our preference to keep
> keywords small and sensible."

It seems the discussion has gone quiet for a while now, so I take that 
we choose ARCH=loong over ARCH=loongarch according to GLEP 53?

If that doesn't receive much objection, I'll prepare and send the first 
few eclass patches soon.

> Ulrich

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

>>>>> On Tue, 24 Aug 2021, WANG Xuerui wrote:

> It seems the discussion has gone quiet for a while now, so I take that
> we choose ARCH=loong over ARCH=loongarch according to GLEP 53?

LGTM

> If that doesn't receive much objection, I'll prepare and send the
> first few eclass patches soon.

We also need to update the conditional in eselect:
https://gitweb.gentoo.org/proj/eselect.git/tree/libs/package-manager.bash.in#n70

Does the GNU triplet (i.e. HOSTTYPE in bash) always use "loongarch"
literally, or can it have some suffix?

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[WANG Xuerui]

Hi Ulrich,


On 2021/8/24 16:46, Ulrich Mueller wrote:
>>>>>> On Tue, 24 Aug 2021, WANG Xuerui wrote:
>> It seems the discussion has gone quiet for a while now, so I take that
>> we choose ARCH=loong over ARCH=loongarch according to GLEP 53?
> LGTM
>
>> If that doesn't receive much objection, I'll prepare and send the
>> first few eclass patches soon.
> We also need to update the conditional in eselect:
> https://gitweb.gentoo.org/proj/eselect.git/tree/libs/package-manager.bash.in#n70
Thanks for the reminder!
> Does the GNU triplet (i.e. HOSTTYPE in bash) always use "loongarch"
> literally, or can it have some suffix?

According to their earlier reservation[1] and actual vendor system
behavior, there are 3 possible values:

- loongarch64
- loongarch32
- loongarchx32

Only the LP64 ABI is fully supported by the current upstream submission.
The "loongarch32" thing might NOT be compatible with the LP64 ABI,
instead it might be something embedded-oriented, even instruction
subsets supported might differ. The "loongarchx32" is for an
n32/x32-like ABI that doesn't exist yet, and probably will never get
implemented.

Accordingly, I think we only have to care about "loongarch64" for now.

[1]:
https://git.savannah.gnu.org/gitweb/?p=config.git;a=patch;h=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[Ulrich Mueller]

>>>>> On Tue, 24 Aug 2021, WANG Xuerui wrote:

> According to their earlier reservation[1] and actual vendor system
> behavior, there are 3 possible values:

> - loongarch64
> - loongarch32
> - loongarchx32

> Only the LP64 ABI is fully supported by the current upstream submission.
> The "loongarch32" thing might NOT be compatible with the LP64 ABI,
> instead it might be something embedded-oriented, even instruction
> subsets supported might differ. The "loongarchx32" is for an
> n32/x32-like ABI that doesn't exist yet, and probably will never get
> implemented.

> Accordingly, I think we only have to care about "loongarch64" for now.

> [1]:
> https://git.savannah.gnu.org/gitweb/?p=config.git;a=patch;h=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f

Patch for eselect included below.

From a49477f39d3f000cc2ca57f18aafbd66656aba05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Tue, 24 Aug 2021 14:13:08 +0200
Subject: [PATCH] Recognise loongarch*/loong in package-manager lib
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* libs/package-manager.bash.in (arch): Recognise loongarch*/loong.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>
---
 ChangeLog                    | 4 ++++
 libs/package-manager.bash.in | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index dfdfe47..f2ea0b6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2021-08-24  Ulrich Müller  <ulm@gentoo.org>
+
+	* libs/package-manager.bash.in (arch): Recognise loongarch*/loong.
+
 2021-02-17  Ulrich Müller  <ulm@gentoo.org>
 
 	* modules/news.eselect (do_list): Recognise "new" and "all"
diff --git a/libs/package-manager.bash.in b/libs/package-manager.bash.in
index 35a1e11..c32fcb4 100644
--- a/libs/package-manager.bash.in
+++ b/libs/package-manager.bash.in
@@ -1,5 +1,5 @@
 # -*-eselect-*-  vim: ft=eselect
-# Copyright (c) 2005-2020 Gentoo Authors
+# Copyright (c) 2005-2021 Gentoo Authors
 #
 # This file is part of the 'eselect' tools framework.
 #
@@ -76,6 +76,7 @@ arch() {
 			hppa*)  	ret=hppa	;;
 			i?86)   	ret=x86 	;;
 			ia64*)  	ret=ia64	;;
+			loongarch*)	ret=loong	;;
 			m68k*)  	ret=m68k	;;
 			mips*)  	ret=mips	;;
 			nios2)  	ret=nios2	;;
-- 
2.33.0

Re: [gentoo-dev] [RFC] Plans for a Gentoo/LoongArch port

[WANG Xuerui]

On 2021/8/12 00:39, WANG Xuerui wrote:
> Hi everyone,
>
> <snip>
>
> ## Gentoo porting plans
>
> I'm planning to take ARCH=loongarch for the port; and support the LP64
> ABI
> first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
> priority.
>
> The ABI flag might be named "ABI_LOONGARCH" but that's IMO a bit long
> (pun
> semi-intended); ARCH=loong and ABI_LOONG might be better, I'm open to
> suggestions.
>
> Because much of the ABI and even some toolchain internals are going
> through
> VERY fierce debate and rework, obviously the port will remain
> experimental
> for a long time. Some minimal support should get in tree though; doing so
> would ease a lot of pain for experimentation. I already hacked my way to
> generate working crossdev toolchains, and is halfway towards a rootfs
> with
> working Python (and Portage). I've already independently ported
> strace, and
> plan to do the same to libffi in the coming days which would give me
> Python.
>
> I'll do all work in my own loongson-overlay first, and upstream these
> when
> appropriate. Eventually I hope to have working crossdev, qemu-user
> emulation
> and proper catalyst support.
>
Some kind of "progress update": I've successfully built stage3 and
minimal installation CD for ARCH=loong; ABI_LOONG is not implemented due
to Loongson retracting 32-bit support themselves, this port is 64-bit
only for now, and may remain so forever (depends on Loongson's
intentions). All modifications are made in loongson-overlay[1]; no
ad-hoc patches to main Portage tree is needed after all. My used
catalyst specs are put at [2]; currently all hard-coded and no automation.

I'm going to send patches for review gradually in the following days, as
the holiday here is over; however I'd like to know whether we need to
wait for the upstream merge of toolchain/kernel support before we can
take patches for ARCH=loong, or if there's more prerequisites.


[1]: https://github.com/xen0n/loongson-overlay

[2]: https://github.com/xen0n/releng/tree/loong