ArchLinuxARM

[glenno]

Just wondering if anyone is still running ArchLinuxARM on their XU4? And have you had a crack at moving from the default 4.14.180-3 (or the AUR 4.14-312-1) to 6.1?

[AnotherLinuxUser]

Depending on your use case, may or may not be a bad idea. For instance, ALARM has some changes that obsoletes Mali Wayland blobs severely and many things under Wayland do not work at all. With Panfrost, it runs just fine. Prior to getting my XU4, I figured that problem one out using an ARM ChromeBook with almost identical specs to that of the XU4 (yes, including a Mali T628 MP6 GPU) using HardKernel's 6.1 LTS kernel. Downstream Linux distributions don't usually exhibit such issues from what I've experienced.

Now that I do have an XU4 in my possession, I plan on getting ALARM better running on it as well as other armv7h devices as the current state of ALARM on armv7h is not great (e.g. they ship a severely oudated Chromium build that is also broken; it hasn't seen an update in a little over a year). Though, as I use Wayland (most of the time) will I be using Panfrost instead with a bleeding edge mainline, rebased with postmarketOS patches (at least, during the times when their kernel is behind on maintenance, as sometimes it is like that).

I still haven't mastered the art of PKGBUILD files neither package files yet (hopefully I will soon though), but I can try making a package for you with the official Odroid XU4 6.1 LTS kernel if you'd like. It doesn't sound all too difficult to do.

[AnotherLinuxUser]

I'll use MastaG's approach at this and simply modify a preexisting PKGBUILD file:

https://github.com/MastaG/alarm/blob/ma ... 7/PKGBUILD

[glenno]

I'll use MastaG's approach at this and simply modify a preexisting PKGBUILD file:

https://github.com/MastaG/alarm/blob/ma ... 7/PKGBUILD

Awesome. Thanks. I was going to try and modify the master one in the repo, but its was really out of date and I was on a sure thing to stuff it up. Thanks for the pointer to a newer one!

[AnotherLinuxUser]

Update: I haven't gotten my XU4 setup to run ALARM quite yet. I'll get to that in a moment once I can get a kernel package built with the HardKernel 6.1 LTS kernel first. Right now I'm trying to figure out this PKGBUILD stuff. So far, I have modified the PKGBUILD and it appears to be building modules from what I can see I ran into an error a couple of moments ago that I quickly had to be resolved when building; it seems like it needed the 'cpio' dependency. It's building on my ARM ChromeBook at the moment right next to me right now. Going to find out if this works or not. It should, because I didn't really change a whole lot. It's using the Odroid XU4 defconfig at the moment. I'll send it here once I get something up and running. Once I get the XU4 running the regular ALARM install, I should be able to just simply install the new kernel package and not face any issues (I hope).

[AnotherLinuxUser]

Apologies for the long wait. Rather unfortunately, it appears that my XU4 no longer works. I've focused most of my time on getting the latest bleeding edge Linux mainline running on here. I did work on getting the HardKernel Mali blobby kernel for a second but I set that aside for a moment. I shouldn't need to do much with what I had done earlier with that. I'm not quite sure if the Odroid C1 stuff still be ran in the PKGBUILD is necessary important for the XU3/XU4, I highly doubt it, but I just kept it in there just in case.

If you so choose to build the mainline kernel for the XU3/4, both the PKGBUILD file as well as the necessary patch file are both in the attached ZIP file. Currently, the PKGBUILD file builds Linux kernel version 6.6-rc7. Also, please note that I've been unable to test it on an actual XU3/4 device of any kind as my XU4 doesn't work anymore (unfortunately). You'll need this large patch file 'postmarketOS-patches.patch' as the PKGBUILD requires it. You'll find that in the ZIP file. It'll need to be in the same directory as the PKGBUILD file. Surrounding the PKGBUILD file sources, everything apart from the 'postmarketOS-patches.patch' file will download automatically as I wanted to simplify it quite a bit. For slightly better Linux performance, it also builds with LLVM Clang.

Info surrounding the 'postmarketOS-patches.patch'--this file contains a ton of mainline patches for Exynos 5 platforms, including the Odroid XU3/4 (yes, this also means that you will also get GPU acceleration via the Panfrost driver). I did modify the patch file to remove '-postmarketos-exynos5' from the kernel's local version from the defconfig (in favor of '-archlinuxarm-mainline'--I also made the default hostname 'archlinuxarm') that it patches in (which also gets merged with the regular Arch Linux--not Arch Linux ARM kernel config).

Getting those patches wasn't an entirely complicated process. HexDump0815 documented his method of gathering postmarketOS patches twice in a GitHub repo of his: https://github.com/hexdump0815/linux-ma ... bp/patches--I will attempt this and see if I can get Mali blobs running on latest mainline as well.

I would like to think that my PKGBUILLD file (and the relevant patch) renders a bootable kernel, based on my knowledge and the results I've seen when working on it, but if it doesn't result in a working kernel, please let me know. I plan to replace the non-working XU4 in a bit.

I'll be back in a bit with a PKGBUILD for the blobby kernel.

[rooted]

Have you diagnosed the power supply? This is most often the cause of what seems like a failed device.

[AnotherLinuxUser]

I did swap the power supply for a new one that was of same specification and I got an entirely different result. A bit of troubleshooting later, the entire unit quit showing signs of life. Now neither power supplies seems to want to work correctly and the device will not display a light of any kind when plugged into power.

[rooted]

5v 4A power supply?

[AnotherLinuxUser]

Yes, that is correct.

[rooted]

Just making sure, easy to forget and plug a 12v supply in if you have other more modern odroids.

That's a shame, I've only had the networking die on an XU4 so I use a USB hub with LAN on that one. The cause was lightning.

There are at least a couple of threads about dead devices that could help with further diagnosis.

From one such thread that you can try as a last resort:

Ok. one last-ditch effort would be to try to power your xu4 via its gpio pins (pin 1, 2), thus bypassing its internal pmic. Use 5V, 4A PSU. If this doesn't work, then the soc itself must be damaged...

[AnotherLinuxUser]

Hello again, everyone!

Linux 6.6 is now no longer an RC release. I figured that for the bleeding edge mainline PKGBUILD file would cloning it from the Linux GitHub mirror be a better solution as URL switching wouldn't be needed when the mainline kernel is or isn't an RC release. This new change will make it easier to maintain it. When mainline is an RC release, it can be specified in 'rc_rel' but as mainline isn't an RC release, that field is empty at the moment and of course, 'pkgver' of course reflects the kernel version. In the future, maintaining this package should be as easy as adjusting 'pkgver' and 'rc_rel' as needed (unless something breaks for instance with a newer kernel). The ZIP file with the mainline patches and the PKGBUILD file are below.

I've also redone the HardKernel Linux 6.1 LTS kernel PKGBUILD file and it is also attached in a ZIP file below. I would've sent it in directly rather than having it compressed into a zip file (as it doesn't depend on that large file containing mainline patches as HardKernel the needed patches included in the source) but the uploader won't let me do such so it's in a ZIP file as well. With both packages, I've done some very basic testing with building it (in an armv7h chroot) I haven't tested it completely.

Both should work though, however, please do note, I don't have access to a working Odroid XU4 for full proper testing at the moment.

The bleeding edge mainline kernel is built with LLVM Clang by default, the HardKernel Linux 6.1 LTS kernel is built with GCC by default.

If anyone has any issues with PKGBUILD file, please let me know so I can work on them. Have a great day everyone!

[AnotherLinuxUser]

I plan to host an Arch Linux ARM repo for the Odroid XU3/4 boards. I recently purchased a relatively inexpensive ARM64 cloud server (though with limited specs). It runs Debian 12 currently and though uncommon, I was able to build the bleeding edge mainline kernel on said server with the PKGBUILD I provided, though I had to adjust a few things (to cross compile) and I had to ignore the dependency check for 'makepkg' as obviously it won't pickup Debian packages. Interestingly, 'depmod' it wasn't in '/usr/bin' but in '/usr/sbin' and so it wasn't universally recognized across the whole system. A symblink fixed that issue though however.

Upon successfully building the package however, I noticed an error (that didn't stop the build from failing) surrounding a nonexistent Pacman Linux hook. It turns out that I was providing Arch Linux ARM's '90-linux.hook' when it was renamed to '99-linux.hook' in MastaG's repo and the PKGBUILD that my work is based on also relies on '99-linux.hook'--upon noticing this, I've went ahead and corrected this. I figured it was better to just use MastaG's Pacman hooks anyways. Apparently there's a 'dirty' tag that appears at the end with the mainline kernel, there's a fix in there that should work, but I'm unsure if it does. I apologize for the Pacman Linux hook issues with both PKGBUILDs. That has been corrected.

All original PKGBUILDs prior to this release have been removed. The corrected PKGBUILDs are below. Have a great day, everyone!