Add ARM UEFI boot ISO?

ARM General ARM Discussion
1

Recently got one CM4 with 8G ram, thus doing some pretty insane setup.

One is running CM4 as a VM host, with one NVME disk for root/home and libvirt.

Then running edk2-avmf as UEFI firmware for VM, and booting a manjaro arm directly using libvirt with KVM support.

It can easily boot Manjaro ARM upstream kernel using systemd!

This in fact works pretty well.

Just one thing to improve, to install populate the VM fs, I have to use arch-install-script, itself is not a big deal just as regular Archlinux installation part.
But this means, we have to populate the fs with RAW image. Then convert it to qcow2.
This means slow zero detection.

While if we have Manjaro ARM install ISO, we can install the distro directly to a VM with qcow2 disk.
This could save the slow zero detection part of qemu-image convert.

I know this is a super niche feature, but I guess it shouldn’t be that complex?
Especially we already have edk2-avmf to test ARM UEFI install ISO?

2

Yes I have been looking into this as I have Honeycomb.

I have sorted out the things needed but the issue is we use calamares which needs an display and with arm devices this can be complicated.
I have to see if we should continue to use the arm oem installer while just adding efi and grub.

Another issue i have faced is the grub default template and every device have different kernel naming.

Rpi uses its own method, allwinner, amlogic and rockchip, nxp is the same names.
So if I pkg it for the latter than it wont work with rpi until user manually changes the grub default template where it fetches the files with a certain name to build the grub menu list.

I will try to get things sorted soon as I have to realise a working iso for honeycomb owners.

3

I have sorted out the things needed but the issue is we use calamares which needs an display and with arm devices this can be complicated.

That’s indeed the biggest blockage. TTL can be board specific and we can’t rely all users to setup TTL.

Another issue i have faced is the grub default template and every device have different kernel naming.

That’s not a problem in fact. For UEFI booting, we’d better assuming they are using ACPI other than device tree, thus we don’t need to bother board specific kernel, but just the upstream kernel, and no device tree.

Rpi uses its own method, allwinner, amlogic and rockchip, nxp is the same names.

'Cause they are still using legacy device tree way.
I hope in the future ARM UEFI+ACPI would be a standard, but from what I have heard, at least for most ARM servers, they are going that direction, thus we’re more and more like x86_64 UEFI, and can forget those device tree mess.

So IMHO, you can just ignore those Manjaro supported boards, and moves towards more serve oriented boards.
And now ARM server distro space will have a new competor :stuck_out_tongue:

4

Its is not about device tree or acpi. It is about the naming convention used for the kernel file and initramfs file.

I am hoping for this.

Yes will look into this soon.

5

With UEFI booting, grub creates /boot/efi/EFI/BOOT/BOOTAA64.EFI and reads from /boot/grub/grub.cfg where the kernel and initramfs names can be standardized in /boot, similar to x86_64.

The UEFI files (/boot/efi) could be installed from the repo, or supplied during installation. The installer should not care what files are in /boot/efi or where they came from… they could even pre-exist. So long as the /boot/efi files are configured correctly, UEFI should load the BOOTAA64.EFI file installed by grub, the only file the installer generates and writes to /boot/efi.

I think… :slight_smile:

Edit: Using a broadly configured mainline kernel. Testing of hardware will be a thing… as people test what hardware works in their multi-board systems.

7

Thanks.

I am aware of all the already but you are not understanding the situation I am stuck at.

Maybe will explain in detail once I am on my home desk.

8

I hope you can find the time, this is a topic I have interest in.

9

I should apologize, of course you are well aware of process. I was describing my understanding and thoughts… sort of my thinking out loud on what might work. It does read as though I am attempting to inform you, and that is my bad.

1 Like
10

Its is not about device tree or acpi. It is about the naming convention used for the kernel file and initramfs file.

Currently I’m using systemd-boot, with upstream kernel, named as “Image”, with default initramfs naming.
No device tree at all.

The systemd-boot config would look like this for Manjaro kernel, in my ARM VM:

title   Archlinux ARM
linux   /Image
initrd  /initramfs-linux.img
options root=LABEL=ROOT rw

Maybe I’m missing something, but I see nothing board naming related at all.

(For RPI/Amlogic/Rockchip boards, they don’t have UEFI firmware anyway, thus we don’t need to bother)

11

It is all good, I like that you have explained how you have multi-boot running on ur RPI.

The concern at hand is the naming of the files used in the kernel pkgs
Upstream pkgs which have been just a rebuild of x86 PKGBUILD have been using initramfs-${KernelVer}-${arch}.img and vmlinuz-${KernelVer}-${arch}

While arm kernels are using Image and initramfs-linux.img while rpi kernel is using something else like kernel9.img.
Can we add symlink to rpi kernel so we follow the same naming for all our kernel pkgs @Darksky @Strit ?

The only solution I can think of right now is to make grub-rpi which will follow rpi-kernel file naming, grub-other for the rest of the devices using Image and initramfs-linux.img

I will just a working grub pkg for now for the device I have which is SolidRun HC for which I have used Image and initramfs-linux.img

My whole point is to make pkgs which does not need user to make manually changes to make it work but as from the above explanation you can see that Arm devices packaging is fragmented atm.

I hope it is much clear to understand from a pkg maintainers point of view.

12

Symlinks are not possible on fat32/vfat partitions.

1 Like
13

While arm kernels are using Image and initramfs-linux.img while rpi kernel is using something else like kernel9.img.

This is not a problem at all. RPI board doesn’t boot using UEFI, and we won’t care those boards. Case solved.

And arm boards are fragmented because they don’t use UEFI + ACPI booting, but doing their own boot scheme.
RPI is one of the worst case, that’s why I prefer to use uboot-rpi, then upstream kernel to have a consistent kernel/initramfs naming.
Although in uboot case, fdt file still needs to vary for different boards.

My point for UEFI ISO is to only support boards using UEFI + ACPI booting, like those ARM servers, not all these existing “toy” boards.
ACPI tables replaces the need for explicit fdt, while UEFI mostly replaces Uboot.

For x86_64, there are tons of hardware combinations, but why they don’t need any specific fdt/kernel?
Because ACPI provides all the hardware table description. And later UEFI to make firwamre->bootloader even simpler.

So I’m afraid you didn’t get my point, for ACPI + UEFI boards, there only needs one upstream kernel and one upstream initramfs. No board specific kernel/bootloader/fdt at all.

And since there is only one supported kernel (upstream one), the filename is fixed, just Image and initramfs-linux.img.
If you prefer, you can also rename upstream kernel to vmlinuz, although I prefer to keep it Image to distinguish them from x86_64 kernels.

2 Likes
14

Furthermore, even Manjaro ARM supports other kernels like zen/atm/-rc kernels, for UEFI boot iso, we only wants a boot medium so we can do traditional arch install method.

Thus one kernel is enough, no need to bother other kernels for the UEFI ISO.

Or did I get the concept wrong?
Maybe Manjaro ISO is supposed to act as an LiveCD, not just a boot medium to do manual archlinux installation?

15

Yes, this is where I was thinking too. While my “toy” RPI4 does indeed use UEFI+ACPI to boot, I can also use device tree. So this may not need to exclude DT booting machines, as grub can pass the DT.

I was thinking this would be a new kernel build, one that uses the Manjaro x86_64 naming conventions, so the grub and various scripts work and that is inclusively configured so it will boot most ARM with unknown hardware, similar to the x86_64 kernel configs.

I believe all of the ARM kernels install to /boot. If /boot is moved to the root file system, not the FAT partition which is /boot/efi, /boot then can support symbolic links (think vmlinuz->kernel-linux-5.12.30 and vmlinuz-> /boot/kernel8.img and initramfs-linux.img → initramfs-linux-5.12-30.img or whatever). /boot/grub/grub.cfg can then be configured via the symbolic links.

If this ISO installs its own kernel with standard naming, it can ignore the SBC kernels and perform a “normal” installation.

Then, if someone subsequently wants to install a SBC kernel, they can, as those are installed to /boot and use non standard names, so no file conflicts. They then just move the symlinks (vmlinux → kernel8.img) and grub boots the SBC kernel specific kernel. I assume anyone choosing this install option is capable of doing it.

The only thing in /boot/efi are the hardware (vendor supplied) and UEFI files… no kernels or initramfs files. So with grub.cfg and /boot symlinks, I think it possible to “normalize” the ARM boot setup. The ISO installs a standard setup and naming… but one that can be easily modified to accept specific SBC kernels, if desired.

The board specific kernel names are due to the firmware booting, ignore the firmware booting for this ISO… I think all UEFI will look for the grub installed EFI file, the one file the install creates and installs to the FAT partition… for the most part, totally ignore /boot/efi. Start with the grub efi and go forward in the conventional way.

And yes, /boot/overlays must be handled manually too if DT is used, but it all works… tested.

16

So this may not need to exclude DT booting machines, as grub can pass the DT.

IMHO DT still needs to be excluded, or we’re fragmented again, to prepare different DT for different boards, exactly the opposite what we want to archieve.

BTW, until now I didn’t know there are projects to make RPI4 UEFI + ACPI compatible at all.
That would provide an interesting real world testing bed, other than edk2 firmware inside an ARM VM.
But not sure how supported my CM4 is.

so the grub and various scripts work

Personally speaking, I just can’t hate grub any more after it upgrades to GRUB2.
Too many automatic detection.
Thus I prefer simple systemd-boot, no automatic detection at all.

For the kernel naming part, until you mentioned I forgot the possibility to have both upstream and board specific kernels.
Then it looks like going back to x86 naming scheme makes sense.

As for Uboot boards, just a simple extlinux/extlinux.conf change, they don’t need any specific filename.
For board specific kernel, we can just use the weird name as is.

17

I do not believe systemd-boot supports nfsroot, at least not with mkinitcpio, nor can it handle DT… and all new motherboards will likely require DT, as they or their devices (and/or daughter boards) are likely not yet fully supported via the kernel. grub is the best option as it provides the most complete booting options.

Yes, this generic install should ignore DT, but the design does not need to exclude it, which is very important for new boards and hardware.

18

I do not believe systemd-boot supports nfsroot, at least not with mkinitcpio,

Not sure about this, but from my understanding, as long as we can provide a kernel, initramfs and possible DT, then boot from nfsroot should only be a problem of kernel/initramfs config.

Or did you mean the kernel/initramfs also need to be loaded from nfs?

nor can it handle DT

It can, Boot Loader Specification
It supports devicetree to load DT.

19

How does Fedora do it with their images?
They are using grub and generic image if I recall correctly

1 Like
20

Related question, hopefully not (too) off-topic since if the installers were built for generic aarm64 and UEFI on an ISO/Live Image I don’t think I would be having problems.

I’m wishing to run Manjaro on my M1 device in QEMU native/full-speed. I’ve been having difficulty trying to figure out if I can use any of the existing community images to install, and I can’t seem to find the right incantation.

Is there a way to use the efforts by the Manjaro ARM team to bootstrap a full Manjaro ARM image? I suppose this use case may be as niche as the OP’s. But I’d prefer the Manjaro experience over others that do work (Debian/Kali/Ubuntu, etc.)

21

I suspect the lack of UEFI support in the kernels is an issue. I am not sure any of the SBC kernels boot via UEFI, except for the RPi4 mainline, but I could be mistaken.

I managed to boot Manjaro ARM on a X86_64 KVM host, so I would expect it to be possible. You will likely need to assemble the disk image and build a modified kernel.