It seems that there has been a few attempts to run Arch Linux ARM on a uConsole with RPi, but mostly back in CM3/CM4 days and haven’t been updated in a while. I got a CM5 with my uConsole, and rather than a Debian image, I really wanted an Arch Linux ARM machine.
It was actually surprisingly easy – thanks to everyone, especially @Rex’s work, pretty much all I had to do was to package Rex’s kernel tree for Arch Linux ARM. I also ran into a known bug with wpa_supplicant that broke Wi-Fi connectivity on RaspberryPi devices. Fortunately, that is pretty much just one revert away (I would LOVE to post links to this but I can’t due to new user limitations – so you’d have to see my package repo below for exactly what was reverted).
For convenience of anyone else who wants to run Arch Linux ARM on the uConsole with a CM5 (and actually, this probably applies just as well to CM4 and CM3), I’ve published all the packages I had to use for my CM5 set up. Prebuilt binary packages are available in my unsigned personal repository:
[petercxy]
SigLevel = Optional
Server = https://s3-cdn.angry.im/alarm-repo/$arch
I’ve also added a brief guide to setting up Arch Linux ARM on the uConsole with these binary packages.
(My setup is a custom Sway configuration with the power button remapped to a kind of lock screen / display on/off, and also with right-click-for-scrolling-emulation which makes the scrolling experience WAY better.)
This is an older version of wpa_supplicant. My version is a mainline build with the broken commit reverted only.
I’d say the only thing you really need to do is to swap out the kernel image and edit config.txt to boot from it. All the other packages are really optional.
Hahah, nice answer.
I’ve been using Arch on my laptop for a couple of years so I expect the usual standard-Arch-painful configuration but I was talking more about the daily usage and practicality of it over other OS.
I’ve successfully installed arch on my rpi4 with a Pimoroni display and even though I eventually made it work it needed far more troubleshooting that my laptop for example, this is what I mean
Oh, in that regard no, the uConsole w/ my CM5 is pretty much “install the kernel + wpa_supplicant, install a DE and good to go”. Firefox etc. all seem to work out of the box with hw acceleration.
Didn’t really have to do any extensive debugging other than the wpa_supplicant situation (but iwd kinda works too, although still buggy on WPA2).
I have just tried and retried to boot your kernel using my existing install on the CM4. (I still have the previous kernel installed so I can still use it in my device.) But I get no response from the display even after a minute of power up. I might be doing my config.txt wrong.
Are there any tools I need to test for responses from the system?
If it’s just a display problem you should be able to access the device via UART or even just SSH over WiFi. Although it seems to me like the kernel just haven’t booted, but I can’t see anything immediately wrong with your config.
If it turns out to be just a display/backlight problem, you might be able to bounce it using pinctrl set 9 op dh if you can ssh into the device.
In that case, I’ll wait until you can test with a CM4. I’m rather ill equipped to be of any help.
I must also ask. I installed it alongside @PotatoMania’s kernel. Can that be a reason why your kernel isn’t booting? Further, I rechecked my cmdline.txt and I can say I have set my rootfs parameters properly. I’ll post my file in the same page soon if you want to have a look.
I’m not sure, it looks like that kernel package uses a post-install pacman hook to copy dtbs into /boot. I don’t think that would have triggered unless you also updated that kernel after installing my kernel package, but if that did happen, then I’d think all the dtbs in /boot will be wrong if you tried to boot mine.
So the OP responded to me that I could pacman -S/U --overwrite "*" the DTB’s and overlays to proceed with installing your kernel. (Which I did.) As my install stands right now, the DTB’s should most probably come from your kernel instead of the previous version. And surprisingly those files still work with the old kernel.
Or am I interpreting the situation wrong? Is there any way for me to know what version of the DTB’s/overlays I’m using?
As far as I know, the kernel package had only one version. A package with an older kernel exists from the same person, but I don’t think that counts because a different name is used.
You can probably compare by sha256sum’ing all of those in your /boot partition versus those extracted from the package tarball (you can find the raw package tarball in your local pacman cache /var/cache/pacman)
I’m really not sure what’s going on, then. The kernel package literally uses the same config as the Debian package. Unless it’s something else going wrong in both cases, e.g. I missed something in the guide, but if that’s the case then it (as in, installed using the same procedure) wouldn’t boot on CM5 either.
I’m having issues with the screen too. I aimed potato’s pkgbuild at rek’s kernel. The screen also doesn’t work but otherwise it runs fine. With the pkgbuild I posted on his thread, the screens backlight comes on but doesn’t display anything. With yours the backlight doesn’t come on at all.
