MIME-Version: 1.0
References: <20191223090638.GA5220@APC301.andestech.com>
In-Reply-To: <20191223090638.GA5220@APC301.andestech.com>
From: =?UTF-8?B?6JSh5YKz6LOH?= <imruinland.cs00@g2.nctu.edu.tw>
Date: Tue, 31 Mar 2020 20:16:58 +0800
Message-ID: <CA+E1uJprQUpHaAuSDCa9xbU5iY7R1CQ+HK+KFp=rZdXf7pkGTw@mail.gmail.com>
Subject: Re: [alpine-devel] Alpine Linux on RISC-V
To: ~alpine/devel@lists.alpinelinux.org
Cc: alankao@andestech.com, sir@cmpwn.com, ruinland@andestech.com
Content-Type: multipart/alternative; boundary="000000000000feb81c05a2258b08"

--000000000000feb81c05a2258b08
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,
sorry again for bumping such an ancient mail thread.

It's been a while since my last e-mail.
(This is my private email for my pastime and hobby projects.)
During these days, I've upgraded Drew and others' work on musl riscv32 port
from 1.1.21 to 1.2.0.
And I've successfully ported and booted Alpine 3.9 on an open-sourced RV32
platform - - Litex/VexRiscv. [1]
The FPGA board I used is a Lattice ECP5-5G Versa stock evaluation board,
which can be purchased on Mouser/DigiKey. [2]

Here's the recorded footage  - -
https://asciinema.org/a/315205

Currently, the whole alpine-base is bootstrapped.
Like I myself, I believe most of people here will be more keen to a
publicly accessible platform

Somehow, I've already acknowledged that Rich Felker declined to merge RV32
port of musl long time ago.
The reason is stated as "the main blocker for riscv32 has been that the
kernel has not declared it a stable ABI yet." [3]

I'm not quite sure about what exactly is "declaring a stable ABI."
I will ask about this issue on musl's mailing list maybe a couple of days
later.

Yet I'm pretty sure that there's a tons of work needed to be done for
verifying an Alpine port.
I would like to know that if there's a list of requirements for
testing/accepting a new architecture port?

Best regards,
Ruinland ChuanTzu Tsai

[1] https://github.com/litex-hub/linux-on-litex-vexriscv
[3]
https://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/ECP55GVers=
aDevKit
[2] https://www.openwall.com/lists/musl/2020/03/12/2

Ruinland ChuanTzu Tsai <ruinland@andestech.com> =E6=96=BC 2019=E5=B9=B412=
=E6=9C=8823=E6=97=A5 =E9=80=B1=E4=B8=80 =E4=B8=8B=E5=8D=885:06=E5=AF=AB=E9=
=81=93=EF=BC=9A

> Hi Drew and everyone,
> sorry for the late reply.
> I had a badly full plate back then.
>
> Though with limited accessibility, our dev boards are available for
> borrowing or purchasement. Yet I cannot disclose too many details
> regarding legal concerns. My supervisor has discussed with our
> corresponding division and they will response to the thread in the
> near future.
>
> For the boot story :
> Thanks for Drew's brilliant work, it only requires minor modifications
> on scripts/bootstrap.sh and some packages' APKBUILDS to build the cross
> compiler and sysroot-riscv32.
>
> That said, due to some driver issues and the lack of ability to self-
> host RV32 Alpine, I cooked up a RV32 initramfs out of the one for ARM
> Alpine - - replace ARM binaries to RV32 ones, reconstruct symlinks and
> tweak the bootargs in Device Tree.
> For now, it could boot from OpenSBI to an alpine-base rootfs flawlessly.
>
> Better still, I build the mkinitfs from aports so we would eventually
> have it done in a better manner some other days.
>
> We might host the mirror sites for Alpine RV64/RV32 package on academic
> sites in Taiwan in the foreseeable future. We'd like to know that is
> there any explicit/implicit policies should be applied ? (For instance,
> FreeBSD strongly urges mirror sites to be IPv6 accessible.)
>
> By the way, there are many things we can share for brining up stuffs on
> our RV64 platform as well.
>
> Andes provides RISC-V IP, and we have our own FPGA-based platform to
> test against. We have been implmenting HW/SW features on the platform
> since the RISC-V port went upstream Linux two years ago.  To this day,
> our 32-/64-bit, UP/SMP and other customized configurations work fine.
>
> Before the FPGA and hardware design were ready, we had been playing
> QEMU for quite a while, so the transition wasn't really a concern. If
> any, the concern would be the gray area not covered by official
> specification.
>
> After such a long journey, we are here now. We would like to be involved
> more in distribution community.  We tried the RISC-V port of OpenWRT/
> buildroot/Yocto, and now looking into Alpine.
>
> Many many thanks,
> Ruinland
>


--=20
ChuanTzu Tsai

--000000000000feb81c05a2258b08
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi all,<div>sorry again for bumping such =
an ancient mail thread.</div><div><br></div><div>It&#39;s been a while sinc=
e my last e-mail. </div><div>(This is my private email for my=C2=A0pastime =
and hobby projects.)<br></div><div>During these days, I&#39;ve upgraded Dre=
w and others&#39; work on musl riscv32 port from 1.1.21 to 1.2.0.</div><div=
>And I&#39;ve successfully ported and booted Alpine 3.9 on an open-sourced =
RV32 platform - - Litex/VexRiscv. [1]</div><div>The FPGA board I used is a =
Lattice ECP5-5G Versa stock evaluation board, which can be purchased=C2=A0o=
n Mouser/DigiKey. [2]</div><div><br></div><div>Here&#39;s the=C2=A0recorded=
 footage=C2=A0 - -</div><div><a href=3D"https://asciinema.org/a/315205" tar=
get=3D"_blank">https://asciinema.org/a/315205</a><br></div><div><br></div><=
div>Currently, the whole alpine-base is bootstrapped.</div><div>Like I myse=
lf, I believe most of people here will be more keen to a publicly accessibl=
e platform </div><div><br></div><div>Somehow, I&#39;ve already acknowledged=
 that Rich Felker declined to merge RV32 port of musl long time ago.</div><=
div>The reason is stated as &quot;t<span style=3D"color:rgb(0,0,0);white-sp=
ace:pre-wrap">he main blocker for riscv32 has been that the kernel has not =
declared </span><span style=3D"color:rgb(0,0,0);white-space:pre-wrap">it a =
stable ABI yet.</span>&quot; [3]</div><div><br></div><div>I&#39;m not quite=
 sure about what exactly is &quot;declaring a stable ABI.&quot;</div><div>I=
 will ask about this issue on musl&#39;s mailing list maybe a couple of day=
s later.</div><div><br></div><div>Yet I&#39;m pretty sure that there&#39;s =
a tons of work needed to be done for verifying an Alpine port.</div><div>I =
would like to know that if there&#39;s a list of requirements for testing/a=
ccepting a new architecture port?</div><div><br></div><div>Best regards,</d=
iv><div>Ruinland ChuanTzu Tsai</div><div><br></div><div>[1]=C2=A0<a href=3D=
"https://github.com/litex-hub/linux-on-litex-vexriscv" target=3D"_blank">ht=
tps://github.com/litex-hub/linux-on-litex-vexriscv</a></div><div>[3]=C2=A0<=
a href=3D"https://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/=
ECP55GVersaDevKit" target=3D"_blank">https://www.latticesemi.com/en/Product=
s/DevelopmentBoardsAndKits/ECP55GVersaDevKit</a></div><div>[2]=C2=A0<a href=
=3D"https://www.openwall.com/lists/musl/2020/03/12/2" target=3D"_blank">htt=
ps://www.openwall.com/lists/musl/2020/03/12/2</a></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Ruinland ChuanTzu Ts=
ai &lt;<a href=3D"mailto:ruinland@andestech.com" target=3D"_blank">ruinland=
@andestech.com</a>&gt; =E6=96=BC 2019=E5=B9=B412=E6=9C=8823=E6=97=A5 =E9=80=
=B1=E4=B8=80 =E4=B8=8B=E5=8D=885:06=E5=AF=AB=E9=81=93=EF=BC=9A<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">Hi Drew and everyone,<br>
sorry for the late reply.<br>
I had a badly full plate back then.<br>
<br>
Though with limited accessibility, our dev boards are available for<br>
borrowing or purchasement. Yet I cannot disclose too many details<br>
regarding legal concerns. My supervisor has discussed with our<br>
corresponding division and they will response to the thread in the<br>
near future.<br>
<br>
For the boot story :<br>
Thanks for Drew&#39;s brilliant work, it only requires minor modifications<=
br>
on scripts/bootstrap.sh and some packages&#39; APKBUILDS to build the cross=
<br>
compiler and sysroot-riscv32.<br>
<br>
That said, due to some driver issues and the lack of ability to self-<br>
host RV32 Alpine, I cooked up a RV32 initramfs out of the one for ARM<br>
Alpine - - replace ARM binaries to RV32 ones, reconstruct symlinks and<br>
tweak the bootargs in Device Tree.<br>
For now, it could boot from OpenSBI to an alpine-base rootfs flawlessly.<br=
>
<br>
Better still, I build the mkinitfs from aports so we would eventually<br>
have it done in a better manner some other days.<br>
<br>
We might host the mirror sites for Alpine RV64/RV32 package on academic<br>
sites in Taiwan in the foreseeable future. We&#39;d like to know that is<br=
>
there any explicit/implicit policies should be applied ? (For instance,<br>
FreeBSD strongly urges mirror sites to be IPv6 accessible.)<br>
<br>
By the way, there are many things we can share for brining up stuffs on<br>
our RV64 platform as well. <br>
<br>
Andes provides RISC-V IP, and we have our own FPGA-based platform to<br>
test against. We have been implmenting HW/SW features on the platform<br>
since the RISC-V port went upstream Linux two years ago.=C2=A0 To this day,=
<br>
our 32-/64-bit, UP/SMP and other customized configurations work fine.<br>
<br>
Before the FPGA and hardware design were ready, we had been playing<br>
QEMU for quite a while, so the transition wasn&#39;t really a concern. If<b=
r>
any, the concern would be the gray area not covered by official<br>
specification.<br>
<br>
After such a long journey, we are here now. We would like to be involved<br=
>
more in distribution community.=C2=A0 We tried the RISC-V port of OpenWRT/<=
br>
buildroot/Yocto, and now looking into Alpine.<br>
<br>
Many many thanks,<br>
Ruinland<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
><div dir=3D"ltr">ChuanTzu Tsai</div></div></div>

--000000000000feb81c05a2258b08--