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
On Mon Dec 23, 2019 at 5:06 PM, Ruinland ChuanTzu Tsai wrote:
> Hi Drew and everyone,> sorry for the late reply.> I had a badly full plate back then.
Sorry myself, I've been travelling for the holidays since receiving your
email.
> 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.
Cool. I would be interested in picking one up for working on the Alpine
port with. If you get the boot story in good shape, then we could
potentially support rv32 upstream even before we support rv64.
> 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.
So long as we can pull a kernel and initrd out of the filesystem, rather
than baked into something weird (for example, the BMC approach of
sticking it on a magic partition with an initrd baked in), then we'll be
in good shape. The rest is just implementation details, we can sort this
out. Let's focus on the "boot from filesystem" part and worry about the
other details separately.
> 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.)
Too early to discuss the mirroring concerns, but there is some info
here:
https://wiki.alpinelinux.org/wiki/How_to_setup_a_Alpine_Linux_mirror
You can write to ~alpine/mirrors@lists.alpinelinux.org once you have
yours set up.
> 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.
Looking forward to it!
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/ECP55GVersaDevKit
[2] https://www.openwall.com/lists/musl/2020/03/12/2
Ruinland ChuanTzu Tsai <ruinland@andestech.com> 於 2019年12月23日 週一 下午5:06寫道：
> 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>
--
ChuanTzu Tsai
I forgot to turn on plain-text mode so the mail got rejected.
Forwarding the following message - -
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/ECP55GVersaDevKit
[2] https://www.openwall.com/lists/musl/2020/03/12/2