I've been working on porting Alpine Linux to riscv64, and I've finished
the bootstrapping process and thought I'd stop by and announce my plans,
status of the port, and seek help from anyone interested. I hope to
upstream the port, if you good folks are interested.
Current status of the port: the bootstrapping process is complete, and I
have a mostly fleshed out, self-hosting Alpine Linux base system running
on a HiFive Unleashed[0] which I'm using to do supervised builds of
various packages. I'm writing this email on RISC-V Alpine :) I've ported
just under 500 packages so far, and have pushed them to my repositories
here[1] and here[2].
[0] https://www.sifive.com/boards/hifive-unleashed
[1] https://mirror.sr.ht/alpine/main/
[2] https://mirror.sr.ht/alpine/community/
I've made small changes to abuild[3] and apk-tools[4], and I've been
pushing my aports work here[5], though it's incomplete and requires a
lot of cleaning up. I also had to do some musl patches[6], but most
software came along with minimal fanfare after integrating any
unreleased upstream work or incorporating third-party RISC-V patches,
which you can see details of in the commits of my aports tree. I think
this is the first attempt to build a distro for RISC-V based on musl, so
I'm hoping that this will serve as a good testbed for upstreaming musl's
RISC-V port as well.
[3] https://git.sr.ht/~sircmpwn/abuild
[4] https://git.sr.ht/~sircmpwn/apk-tools
[5] https://git.sr.ht/~sircmpwn/aports
[6] https://github.com/riscv/riscv-musl/pulls/ddevault
Note that my aports tree is in need of some cleanup. I intend to
frequently rebase this as I work on making a nice upstreamable history.
I have a long todo list, but some of the more important tasks include:
- Addressing all of the issues I had bootstrapping as clean,
upstreamable improvements to bootstrap.sh
- Making a useful kernel package, which is non-trivial because of how
the boot process works on RISC-V. Some things which will be difficult:
user-editable kernel cmdline, loadable modules, installing the kernel
directly to the boot partition (rather than the filesystem), no
initramfs. Might have to do some development work on the bootloader
first
- Designing and writing up a nice installation procedure, and figuring
out the best way to distribute the port to end-users
Once I get this stuff out of the way, I'm going to move on to building
world, which I intend to automate through my builds.sr.ht[7] platform.
I already use this today for building x86_64 packages in a third-party
Alpine repository, for automating deployment of sr.ht itself (which for
the most part runs on Alpine).
[7] https://meta.sr.ht
Some open questions:
- I've had to do some annoying work to update config.guess & config.sub
in various packages which use libtool. I tried various ways of doing
this but settled on updating the versions used in abuild and copying
it into the $builddir of packages which have an outdated version. This
is going to get annoying to automate, but should be feasible. Any
thoughts? I imagine that this might have been a problem in previous
ports as well.
- How would you guys like to handle upstreaming the port, assuming you
want to? I would be happy to handle maintenance indefinitely. I would
be happy to offer my binary packages if you want them, and I would
also be happy to help some Alpine devs work through the bootstrapping
process themselves. Once I have build automation set up it would also
be my pleasure to to offer RISC-V cycles on my HiFive to Alpine devs.
I'm likely to get more hardware in the future as well, and offer it to
other Linux distros and downstream software that want to work on a
port (though I'm only interested in personally porting Alpine)
- I could use some help with Boost if anyone groks it and is available
to have their brain picked.
- Is there interest in a riscv32 port? I don't have any 32-bit hardware,
but I'm trying to be as generic as I can in my approach to minimize
this work later.
--
Drew DeVault
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Mon, 17 Dec 2018 at 03:36, Drew DeVault <sir@cmpwn.com> wrote:
> - Is there interest in a riscv32 port? I don't have any 32-bit hardware,
> but I'm trying to be as generic as I can in my approach to minimize
> this work later.
Probably not at present, all the 32 bit hardware is microcontrollers, while
only 64 bit hardware runs Linux. There is no 32 bit support on 64 bit hardware
and this seems unlikely to change, so it seems unlikely to be worth supporting
32 bit in the foreseeable future.
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---