I switched to archlinuxarm on my rpi4 cause I got sick of having to jump through hoops to do mundane things like needing a ppa to install ripgrep or downloading debs for less popular packages.
Apart from a little confusion about how to configure the bootloader(since rpi uses uboot as opposed to the usual suspects), my experience has been amazing. In typical arch fashion, I've had zero issues apart from on install day.
>I switched to archlinuxarm on my rpi4 cause I got sick of having to jump through hoops to do mundane things like needing a ppa to install ripgrep or downloading debs for less popular packages.
Been running it on the rpis for years for similar reasons. Besides having most stuff packaged, it follows Arch principles and thus doesn't make unnecessary/unreasonable changes to software, my main complaint with most software targeting raspberry pi.
Did you run into a boot loop because of some SDMMC controller problem? If yes: this is caused by hardware changes in newer rpi4 and old rootfs images from ALARM which don't support this yet but it's fixed if you update it. To do that, you have to play around with chroot + qemu-user to run a standard "pacman -Syu" on the rpi rootfs before the first boot on the real rpi4. Afterwards it should boot properly on the rpi4.
That being said, if you want to use e.g. the official RPi 7" touch display via DSI, you should also switch from the default upstream kernel to the rpi kernel unless you like to mess around with DTB and debug strange problems.
There's a few threads about it at rvspace forum[0].
The main point is to understand the boot process, and build or download a kernel with the VF2 patches, as while most of it is upstreamed already[1], it's still not 100%.
I wish this was a thing for ARM as well (ArchLinux ARM is a great effort, but underfunded). I was using Asahi and had to shift from ALARM to the Fedora remix.
Cool work. Hope we see more decent powered hobbyist stuff soon.
> so that riscv64 (riscv64gc) could be added to Arch Linux itself as an alternative architecture.
Seems unlikely since they only support one architecture. There's bound to be way more 32 bit x86 out there than riscv for the foreseeable future, and they purposely dropped support for that long ago.
There's a range of boards, including some laptops and tablets, based on TH1520 and JH7110 SoCs. These are RVA20 chips.
As of recently, there's also spacemiT K1, which is RVA22+V.
In the second half of this year. Milk-V Oasis is meant to show up, providing a serious jump in performance. This is 16x SiFive P670, similar to Cortex A77, faster than any ARM SBCs available.
The decent performance is on its way, all that with enough modern hardware features to be a "big implementation" (à la x86_64).
Then RISC-V assembly will be the new C.
It is going to be a long road and a difficult one: the market is already saturated with mature micro-architectures with ISAs completely locked down with Intellectual Property and that by very few vendors. This is really hard, can still fail
It's not reasonable to expect people who like programming in C or other high level languages to suddenly switch to RISC-V assembly.
But I do expect some programs written in assembly to show up, because it doesn't happen very often than a new, modern open ISA like RVA20/RV64GC shows up with a promise of very long term compatibility.
And because assembly is still fun, and will forever be.
Yep, and since C was mostly used as an ISA abstraction, then with a real, good enough, worldwide royalty free ISA and not vendor locked, we can expect much more assembly written libraries and programs.
A side effect is to kiss bye bye significantly to the planned obsolescence of much system software and some computer language syntaxes.
Works well (seems no worse than archlinuxarm), and has most Arch packages.
I am hopeful as the arch ports RFC[0] passes, RISC-V and other ports will be taken more seriously, and hopefully eventually become fully supported.
0. https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests...