Bill's "LargeArch" 20250412 release, full QEMU integration, 6.15rc1

Here is the large Arch Image release for Orion O6 with full QEMU integration and 6.15rc1.
Can’t attach a torrent file to the post so here is the folder with the torrent, readme, and build log that shows what got installed.

https://mega.nz/folder/nZFWEYCZ#iiMPfd-C1_raEOjvRZTp5A
https://drive.google.com/drive/folders/1ii7dBfqoEfBazga1B9IXsw-eqA8cn2A8?usp=sharing

The kernel includes the GPU patch for Mali V12, MALI V11/V12/V13 missing firmware, many missing options added to the build, such as hugepages, AMD gpu, dmabuf, network drivers, etc.

This release still requires an AMD GPU to boot into the graphical section.

This first release comes with Cinnamon desktop and the full XAPPs package suit to go with it.
Please see the readme for the install procedure, along with some forgot-to-add packages.

Many apps that aren’t in arch repos that you have to build yourself are included such as OBS, webcord, teams, brave-bin, chromium 134 for the new ICU lib, etc.

Full avahi share drive (from nemo) and printer discovery is working.

The build script to be able to make a new image (with the included AUR packages) is included in this image, so you can use it to create a customized version with additional software with Plasma desktop instead of Cinnamon, for example.

When flashed to an NVME drive installed on the Orion O6 Primary M.2 slot, use the default grub menu entry labeled NVME0. If trying to boot the image in QEMU or USB use the grub entry labeled QEMU.

This ships with a customized mesa-tkg build (with AMD supported included), and as the Mali waits on mesa release support, you will want to rebuild this mesa after any major system update (anything where LLVM libs or python or rust gets a new major release). Maybe someday I will figure out a static mesa build but not today. Possible with the Mesa 25.2 release the new Mali GPU will be included, then you can use the standard arch packages for mesa. (that is a ways off from now)

I included the missing QEMU related packages (arch ARM doesn’t have them) and a full example XML setup to be able to create VMs with native performance and HW acceleration. So you can create VMs for booting stock Debian 12 or Debian 13 ISO image, and give them all 12 cores and say 40GB of RAM to be able to build the kernel inside of them in RAM. Note that Debian 12 ARM ISO first boot requires adjustment to the VM settings to boot from a USB drive, and maybe HW acceleration needs to be turned off.

This includes commented out BredOs and Danctnix repos, so you can uncomment those lines in pacman.conf and start using their packages. Some of the BredOS packages though I heard are 32-bit so make sure to avoid installing those packages on the A720.

The next release might include the fully working IGPU.

Waydroid is NOT working on Orion and is not included. But if you installed this image on a RK3588 board it should work.

RK3588 mainline support is still fully included, but there are no additional rockchip patches, so this will boot on many boards, and at least a few of them will have both HDMI ports working now, such as the Rock 5B. (although I don’t have that and didn’t test on that board)

4 Likes

Interesting work :slight_smile:

Is this uefi image to work with edk2?

So you included the mali gpu kernel patch and still cant produce video out?

I trought the mesa patch was just to get 3d accelerator working.

Nvidia gpus can be used?

As for Mesa G720 patch, this is the branch of the PR

I havent tested if it can be compiled, im guessing it needs to be used along with the kernel patch.

It does compile. Yet it won’t be usable on the system without something else, let it be kernel patch which I do not know where to find nor how to apply :smiley:

https://lore.kernel.org/dri-devel/20250320111741.1937892-1-karunika.choo@arm.com/

Thats the panthor patch.

Ok thanks.
So what I did is that I cloned the repo drm-misc then I downloaded latest stable kernel from kernel.org (6.14.2).
Here is what I did already :

  1. Decompress the kernel sources
  2. Created a patch file : diff -Naur linux-6.14.2/ drm-misc/ > panthor.patch
  3. cd linux-6.14.2
  4. patch -p1 -N < …/panthor.patch

Am I good to go for a compilation on the Ubuntu 25.04 distro using silentoldconfig and modules_install ? (yolo-ing from here)

I have included in my software image already the full makepkg build scripts for both kernel and mesa in
/home/Software/makepkgs/
Once you chown/chmod the directories you can build each of them using the command
makepkg -si

In the linux-aarch64-rc folder it is already setup to fully reproduce the same 6.15rc1 kernel version build that ships on the image.
This already has that DRM panthor patch included, BUT it is NOT enough to enable the IGPU.
FYI you can add more patches easily into the folder, and add a patch line per patch into the PKGBUILD file to customize your build. This is still basically the stock makepkg for arch for building an RC kernel, FYI. I just enabled significantly more options in the config file.

In the mesa-git folder, once the mesa merge requests go through (Edit: It was merged a few minutes ago), you can change the mesa-git.cfg file to remove the “mesa-25.0.3” version number near the top. Once you change it to be empty “” it will build the latest mesa git instead of the release version.
Like with the kernel build, you will use the same command “makepkg -si”
Until then you can switch the config file to use the contents from “mesa-git-avalon.cfg” which points to Guillemard’s branch that is tested on Orion.

To use the IGPU today you folks will still need to switch to a 6.1 version that actually has the GPU driver and device tree.
Guillemard has updated the vendor kernel to work with the latest mesa-avalon version. (and soon to be in mesa-git)

If you point that linux-aarch64 PKGBUILD to this URL you can try building it, but the networking on Orion won’t work once you boot into it since it isn’t 6.6 yet.

It might be possible to use some kind of device tree overlay to add just the IGPU on top of the ACPI kernel 6.15, but it looks like it make take a considerable amount of software work to cook up. Not just the changes shown here, but porting forward the vendor kernel bits for the chip that you don’t see in the change history.

To build released kernel 6.14 into an arch package and easily install it, you should be using this makepkg.

It will already do the steps of downloading the tar.xz base files, instead of grabbing from git.

Note that on the line shown here, you should remove the chromebook part as you don’t want to install that on the Orion (or RK3588, etc):


pkgname=("${pkgbase}" “${pkgbase}-headers” “${pkgbase}-chromebook”)
Should be changed to this:
pkgname=("${pkgbase}" “${pkgbase}-headers”)

Then you will get the standard kernel and header packages.

The kernel rc makepkg that I included in my image came from here FYI. Note that I added 6.15rc1 into it before it was released for 6.15rc1, so the version here on their git is newer/updated compared to what I shipped on the image.

Wait, why is not enoght? there is anything in dmesg pointing to panthor not getting initialized?
Panthor + Mesa should be the only thing needed from the OS side… unless we are missing something in the ACPI tables?

My image includes a 70MB EFI partition and a grub installation like you have on a desktop PC. (the boot selection menu will appear)
The goal of the image is to have it be usable like a typical arch x86 installation that you might have.

It is intended to boot from the Orion using the ACPI mode. If you install kernels as separate files into the boot folder, you can switch between them at boot time using the keyboard. You can use the included grub-customizer GUI application to add a new menu entry. If your external GPU has a proper UEFI GOP VBIOS, the grub menu will appear on the external GPU. RX460/470/480 should have proper UEFI GOP, or can be updated to have it. (my vega 64 shipped with a broken one, but also a partially working one on the second vbios) All RNDA and newer GPUs should have it.

There is a folder in the EFI partition already to be used to perform the BIOS update to 9.9, and I include the UEFI shell file also that you can boot into. You can just swap the bios files out or add a new folder to flash a different BIOS release. There is no need to prepare a USB flash drive for BIOS updates. You could also add refind into the partition, for example, and boot other OSes from the NVME that way.

The grub configuration already includes a menu option to go into the BIOS menu. Using grub customizer you can add a menu option to go into the UEFI shell to perform the BIOS update.

If you installed this arch image onto an RK3588 SBC you only need to add the appropriate board device tree boot line into the grub menu entry to get it to work with the mainline dts. Almost all Radxa rockchip boards are in there already.

Without some device tree to specify the address and presence of the mali GPU it will not attempt to initialize it. You can install my image (with the patched 6.15) and see for yourself in dmesg it won’t know it is there. It will be completely ignored.

You can see here from the panthor-updated vendor kernel the type of device tree that will be needed.


It will be similar to the device tree for the mali on RK3588. If you check, it depends on having CIX/SKY drivers in the kernel. Those drivers ARE NOT in mainline obviously so you can’t just throw the DTS onto mainline and expect it to work today without some modifications and minimal other patches to declare the device.

Unless someone knows how to run minimal device tree overlay on top of ACPI and it can be used to activate the IGPU we might be several months away from activating the IGPU on mainline, and when we do have that working, it will be device tree instead of ACPI per Radxa. But who knows maybe Radxa can put the gpu stuff into the ACPI bios and get it working, but then again there is no known example of this in existence. I believe that all ARM IGPUs in mainline require a DTS initialization, since the ACPI method wasn’t ever done before. This board will be first, and according to Radxa the ACPI spec is incomplete and isn’t ready for it to be the first yet.

Also you can manually modprobe the panthor driver from ACPI boot, and it still won’t find the IGPU or do anything unless you can somehow point it to the GPU and and register address.

I would expect that no DT, of any kind, is needed for ACPI mode. So besides the panthor patch and mesa patch, something is missing on the bios.

Did you tryied with the bios 9.0.0 right?

Either that, or pathor cant discover gpus in ACPI mode what would be a little more worrying.

But, as you said, i think it is the bios.

Eeeeh. Thanks ?

I want to learn so using an automated script that I cannot really understand at first glance won’ t help me a lot :confused:

PKGBUILD is how you build and install things on arch linux, if you don’t use it then you can’t even track what packages that you have installed (manage with package manager) and might break your system if you don’t know what you are doing since your system doesn’t know what you have installed. Every package that you install from the normal package manager someone else built it with makepkg.

The typical make package will have 3 basic steps. The prepare, the build, and the packaging step.
https://github.com/archlinuxarm/PKGBUILDs/blob/f3626fe8f0d5443556e2fc7011d9031276cd8b83/core/linux-aarch64/PKGBUILD#L39 <- prepare
For the kernel builds prepare will do a git pull, or download and extract the tar files. These go into the subfolder of the src folder (all pkgbuild will create the folder named src)
Then prepare will apply patches using the “git apply” commands, there are 3 in that one.
Next the kernel config is copied from the arch packaging folder into the kernel folder to the .config file. (this is a kernel specific thing)
In my modified makepkg, I added the make xconfig to show the configuration gui, so that you can select or deselect features/modules. For example you could add/remove additional GPU or network drivers.

Next in the build step right below in that file it does the build.

“make ${MAKEFLAGS} Image Image.gz modules” does the actual kernel build and creates the actual file that you boot in grub.
“make ${MAKEFLAGS} DTC_FLAGS=”-@" dtbs" creates the device tree files. We will be using device tree on Orion later. You could completely skip this step and Orion can boot in ACPI mode.

The package step then wraps everything up into a package file, including the information how you build the package, what versions of packages were installed on your system, flags, etc so that someone could examine it to try to reproduce the build exactly.

Once you build a package with the command “makepkg” and it spits out the files with “pkg” in the file name, then you use the following command to install it.
sudo pacman -U filename.pkg.tar

There is good documentation here and in other places for arch linux (man pages, etc)
https://wiki.archlinux.org/title/Makepkg
https://wiki.archlinux.org/title/PKGBUILD
https://wiki.archlinux.org/title/Pacman
https://wiki.archlinux.org/title/Arch_build_system
https://wiki.archlinux.org/title/Arch_User_Repository
https://wiki.archlinux.org/title/Frequently_asked_questions

1 Like