| 1 |
Hi Yixun, |
| 2 |
|
| 3 |
On 2021/8/12 17:55, Yixun Lan wrote: |
| 4 |
> HI Xuerui: |
| 5 |
> |
| 6 |
> This must be a *HUGE* project and gonna put lots of effort in to it! |
| 7 |
> So, first, good luck to you with all my best wishes!~ |
| 8 |
Thanks for your kindness! |
| 9 |
> |
| 10 |
> On 00:39 Thu 12 Aug , WANG Xuerui wrote: |
| 11 |
>> Hi everyone, |
| 12 |
>> |
| 13 |
>> I'm your average Gentoo user who obviously thought his sleeping time is more |
| 14 |
>> than enough, and just decided to start porting Gentoo to LoongArch. As this |
| 15 |
>> is such a niche architecture with no upstreamed support so far, I'm posting |
| 16 |
>> this to announce my intent and gather advice on how to best push this. |
| 17 |
>> |
| 18 |
>> I'll first give some background material to help people gain context, then |
| 19 |
>> describe my porting plan. This is going to be a bit long; apologizes for |
| 20 |
>> that. |
| 21 |
>> |
| 22 |
>> |
| 23 |
>> Note: I'm not affiliated with Loongson in any way; I'm just doing this in my |
| 24 |
>> spare time (once meant for some quality sleep). |
| 25 |
>> |
| 26 |
>> |
| 27 |
>> ## A bit of introduction on the LoongArch |
| 28 |
>> |
| 29 |
>> LoongArch, as its name implies, is the brand-new ISA developed by the |
| 30 |
>> Loongson Corporation, incompatible with MIPS which was implemented by |
| 31 |
>> all previous Loongson processors. Currently only the base ISA specification |
| 32 |
>> is publicly available; it has fixed-length 32-bit instructions, vastly more |
| 33 |
>> instruction formats (39 distinct formats in the base ISA alone!), and its |
| 34 |
>> instruction semantics mostly resemble RISC-V, with a bit of MIPS R6 here and |
| 35 |
>> there. It is capable of 64-bit operations, obviously. |
| 36 |
>> |
| 37 |
>> ISA documentation: https://github.com/loongson/LoongArch-Documentation |
| 38 |
>> ELF psABI draft: https://github.com/loongson/LoongArch-Documentation/pull/3 |
| 39 |
>> |
| 40 |
>> The draft ABI is undergoing fierce review, and is subject to change, |
| 41 |
>> especially the relocation types. Other parts like the register |
| 42 |
>> convention and |
| 43 |
>> data layout is unlikely to change much, though. |
| 44 |
>> |
| 45 |
>> There is little code upstreamed for basic software (GNU toolchain, QEMU, |
| 46 |
>> Linux and the like), but many are open-sourced already. Nevertheless, the |
| 47 |
>> code quality is still very much inferior, and much of it is obviously based |
| 48 |
>> on respective MIPS support. There is continuous debate inside and outside |
| 49 |
>> Loongson on this matter, too. |
| 50 |
>> |
| 51 |
> Didn't do any investigation, but if I read correctly, also see here [1] |
| 52 |
> |
| 53 |
> The fundamental pieces of softwares are open-sourced but *NOT* yet upstreamed |
| 54 |
> So, I'd say, let's wait till it's actually accepted by upstream, |
| 55 |
> before pushing to downsteam (Gentoo here). Sure, you're free to send |
| 56 |
> a pull-request for review/comment, but collect peices under your own overlay |
| 57 |
> would be a good idea ( in my humble opition ). |
| 58 |
|
| 59 |
Sure; that's basic etiquette. However there are some parts that |
| 60 |
definitely need upstreaming, otherwise complexity could explode; for |
| 61 |
example, the multilib_env function and tc-ninja_magic_to_arch function. |
| 62 |
Without fixing multilib_env we could only use the "default" ABI, and |
| 63 |
without adapting tc-ninja_magic_to_arch even linux-headers is unable to |
| 64 |
build. If we don't touch the upstream repo, a full fork is needed, and |
| 65 |
that's going to be painful. |
| 66 |
|
| 67 |
Additionally, I've already seen adaptations for experimental arches in |
| 68 |
repo; so I thought upstreaming these minimal bits would be acceptable. |
| 69 |
If that's deemed too early (and I totally understand the reasoning |
| 70 |
behind that), doing work in forks is okay from my side. |
Archives