There is efi support already. I am running it on Honeycomb 
I am not sure any of the SBC kernels boot via UEFI, except for the RPi4 mainline, but I could be mistaken.
Nvidia Xavier AGX has experimental UEFI firmware support, with switchable ACPI/DT support.
But itās mostly BS, as although it can boot upstream kernel, itās far from stable.
And other server grade ARM boards are all supporting UEFI.
I suspect the lack of UEFI support in the kernels is an issue.
It has been a quite long time to have at least upstream kernel compiled with UEFI stub support.
In fact, ArchlinuxARM has that built in for a long long time, mostly for chromebook devices.
Thus itās never a problem for kernel.
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.
There is no out-of-box option for generic UEFI boot image.
All existing images are board specific.
Thatās exactly why I started this thread.
Although it shouldnāt be hard to use the rootfs, and chroot to install upstream kernel, setup UEFI bootloader of your taste, and start the VM.
Thatās exactly how I get my ARM VM setup upon CM4.
I suppose this use case may be as niche as the OPās
Firstly, your use case is exactly what I want. Have a simple out-of-box installer for UEFI systems, no matter if itās a VM or a bare metal.
Secondly, although itās niche now, it would be the generic way to boot for future ARM boards/servers.
Thus it not that niche in the long run.
Any update about this? I got myself a Jetson AGX Xavier and am interested in this too after checking this documentation regarding experimental UEFI support.
The documentation about the UEFI firmware says itās meant to run a mainline (not L4T) kernel, and it mentioned about some out-of-tree patches needed for PCIe stuffs to work (which is disabled by default).
I tried following the link it mentioned but couldnāt find anything. However, according to the kernel mailing list the patches in question have been merged into the latest kernel versions so itās probably not needed.
Looks like Archlinux-arm has a generic guide which seems to be related to UEFI use case, but Iām not entirely sure.
The developer kit came with a L4T-tailored Ubuntu 18.04 system image. I was able to somehow get it updated to 20.04 but it seems a lot of stuffs ended up broken in the process as system errors keep popping out everywhere. While the system itself still mostly works, itās clear to me that updating a distro thatās using L4T is not a straightforward task.
It would certainly be helpful if a generic UEFI flavor for ARM devices becomes available.
The final result is mixed.
The good:
- Working upstream kernel support in device tree mode
- Working EFI bootloader support for GRUB
The bad:
- Systemd-boot doesnāt work well, it doesnāt pass initramfs correctly
- Super poor KVM performance even itās already using the VHE mode
Mostly caused by missing PMU - Need extra Xorg patches to make Tegra driver to work
So no Xorg/Wayland hardware acceleration for now
If you really want to try upstream kernel, you need to follow that guide to flash the EFI firmware first.
Then craft a rootfs with proper EFI bootloader (in my case, I still use systemd-boot, with my custom kernel with extra tegra modules compiled into the kernel), then to boot the kernel directly, without initramfs.
But for now, the Xavier is just a paper weight for me, due to its super poor KVM performance, and not working upstream Tegra support.
So my current main ARM64 power horse is RPI CM4 (8G ram, OCed to 2.1G) with x1 lane NVME, and RK3399 with op1 opp override.
1 Like
BTW, next time just try to avoid Nvidia things.
Even their Tegra is mostly open-sourced, itās still a big pain in the ass to work with them.
In fact, their EDK2 port (the UEFI firmware) fails to properly let systemd-boot to pass kernel initramfs, their Tegra support in lacks in upstream graphic stack, and custom core design, are all blockages.
So even with their super competitive hardware on paper, in the real world itās better to stick with L4T (which I hate so much that I prefer to make it work as a paper weight)
1 Like
So still no support for this ? I am planning to try and install Manjaro ARM on an Oracle cloud ARM instance.
What is the use of manjaro arm on oracle arm cloud ?
Manjaro is mostly for desktop use and using it on oracle cloud would be for server use cases.
Currently we donāt have uefi images yet.
Manjaro is mostly for desktop use and using it on oracle cloud would be for server use cases.
Sorry, I donāt think there is any point binding a distro to certain use cases.
In fact, I use Manjaro ARM just because two points:
- Itās Arch based, thus its pacman (mostly) matches my other Arch machines
- It has more up-to-date kernel support than ALARM
In fact, I never bother to run any desktop on all my ARM boxes.
All my use cases for my ARM toys are for VM and NAS.
I am planning to try and install Manjaro ARM on an Oracle cloud ARM instance.
You can still use arch-install-script to setup the instance.
Interesting, Iāve been using most of my nas and firewall on arm also 
For uefi we need more time and we have some issues moving forward with grub.
I have looked into it but need more time to test and update the tools we use to build images.
Would that mean that running Manjaro on something like the Liva QC710 could become reality?
IDK if that one have UEFI, if it have UEFI then yes. you can load something while linux kernel will fail unless someone reverse engineer the drivers or qcom contribute the drivers.
For uefi we need more time and we have some issues moving forward with grub.
For my use case (and all my x86_64 based Arch systems), I strongly prefer systemd-boot.
Furthermore, recently one of the missing critical feature, loading device-tree, is added to sd-boot, thus I see no reason to bother GRUB.
And personally speaking, considering how slow GRUB community is to merge new patches, I would avoid GRUB at all cost.
well, are you sure or is it more that they want to make sure that grub works on most devices it is installed? See here for the current commit log: grub.git - GNU GRUB
well, are you sure or is it more that they want to make sure that grub works on most devices it is installed?
Nope.
I speak here because they donāt even merge a small fix for btrfs driver, which canāt even handle recent NO_HOLES features (and that feature is now default mkfs profile, this means, any btrfs created using btrfs-progs, and if there is any hole in the kernel/initrd, grub will refuse to read them)
Not to mention their btrfs driver lacks tons of essential features, like basic metadata sanity check, metadata/data checksum (thus no proper recovery from other copies).
The fix is from active btrfs developer, and they donāt even bother to merge after several weeks.
From the code style to the lack of knowledge of complex filesystems, nor will to ask for help from btrfs community (not to mention their almost insane GPLv3+ requirement), Iām surprised GRUB is still actively used by most distros.
Trust me, if youāre in the position to push any bug fix into upstream GRUB, youāll be as frustrated as me, if not more frustrated.
I need to have some powerful machine for compiling and I took advantage of Oracle offering some ARM64 instance for free.
Turns out I can just use Oracle Linux and chroot to a Manjaro rootfs. Seems to work well except some feature for space calculation in pacman.
1 Like
I tried to register but they only accept credit card and I donāt have one so I cannot do much.
I will check with someone from Manjaro Team to register it for us.
Thanks.
Found something that claims to be ARM based with UEFI and running Linux.
FTC663 cpu support is still not in linux kernel.
and it is 8core,
If you want desktop arm device with UEFI then Honeycomb is already there, I have it running with AMD R5 230
Honeycomb have mainline kernel support too.
I need to have some powerful machine for compiling
Well, if you already have powerful x86_64 desktop, distccd-alarm-armv8 will easily give a super boost to any compiling work.
In fact, my armv8 testing VM is mostly helped by such cross-distcc setup to build a 64K page size kernel.