Hi! Today arm64 with UEFI is coming as an arm64 servers standart. It would be nice to see arm64 UEFI build for Openwrt with virtio, pvscsi and vmxnet3 drivers to run it in KVM arm64 or new arm64 vmware ESXi. The new ESXI runs very well on rasberry Pi 4, but ESXi arm64 only support UEFI boot for VMs. Personally, I like to virtualize openwrt in home miniserver by combining it with other OSes. This provides a router + server bundle for any need. For example, Openwrt + Debian with ISPConfig or OpenMediaVault.
I've done this for years with an Intel NUC (Openwrt+Mikrotik CHR+Debian+Windows on ESXi) and it was great. It's the real freedom! But now I have rpi4b with 8gb RAM and ESXi runing well and NUC seems like an obsolete dinosaur. The debian runs well as a wm in ESXi on rpi4, so I need to run Openwrt.
So, I faced the fact that there is no way to boot Openwrt in arm64-UEFI environment. UEFI-enabled images only available for X86_64. Why?
Can anybody help? Thanks!
Device -and even less target- support doesn't materialize out of thin air, someone -you- has to develop and submit a corresponding patchset (and commit to its ongoing maintenance, at least to some extent).
[Disclaimer: I'm not an OpenWrt developer and can't speak for the project. Warning, purely personal opinion below]
That said, what is this mystical 'ARM server' you're talking about? The term has been flouted for well over 5 years by now (first referring to the utterly underspecified ARMv7, now ARMv8 with UEFI (or at least a shadow of itself running on u-boot, merely apt to run grub, a limited set of UEFI runtime services and ACPI), where is this army of cheap, ultra-powersaving server class devices? Actual hardware still isn't available to mere mortals or on a budget - and a purely virtual target would be a quite big hammer. Don't get me wrong, I want to believe^Wsee this mystical hardware, but it will probably ship with hurd as operating system.
Don't get me wrong, can't help - don't write. Too much water.
I look around: all modern arm64 OS images support UEFI boot.
I am ready to take this path myself - let only someone give a direction. There must be a lot of people here who are more experienced than me.
The google says:
On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
as a PE/COFF image, thereby convincing EFI firmware loaders to load
it as an EFI executable. The code that modifies the bzImage header,
along with the EFI-specific entry point that the firmware loader
jumps to are collectively known as the "EFI boot stub", and live in
arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
respectively. For ARM the EFI stub is implemented in
arch/arm/boot/compressed/efi-header.S and
arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
between architectures is in drivers/firmware/efi/libstub.
For arm64, there is no compressed kernel support, so the Image itself
masquerades as a PE/COFF image and the EFI stub is linked into the
kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S
and drivers/firmware/efi/libstub/arm64-stub.c.
By using the EFI boot stub it's possible to boot a Linux kernel
without the use of a conventional EFI boot loader, such as grub or
elilo. Since the EFI boot stub performs the jobs of a boot loader, in
a certain sense it IS the boot loader.
The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
So I need to compile kernel with the CONFIG_EFI_STUB option.
But it depends on X86_64 target! Why and how can this be changed?
And about the "standart": If you try to create an arm64 VM in KVM without UEFI it says "ACPI requires UEFI on this architecture".
echo 'CONFIG_EFI_STUB=y' >> target/linux/armvirt/config-5.4
no depends...
This should work? )
Added to target/linux/armvirt/64/config-5.4
try to build...
Compiled! very interesting...
4 588 398 openwrt-armvirt-64-default-rootfs.tar.gz
9 023 496 openwrt-armvirt-64-Image
20 492 296 openwrt-armvirt-64-Image-initramfs
sizes are well, but I don't see "MZ" header in start of kernel as EFI stub attribute...
00000000: 0040 1f14 0000 0000 0000 0800 0000 0000 .@..............
00000010: 00f0 3c01 0000 0000 0a00 0000 0000 0000 ..<.............
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 4152 4d64 0000 0000 ........ARMd....
here is start from UEFI-booting kernel from debian vm:
00000000: 4d5a 0091 ff7f 2e14 0000 0800 0000 0000 MZ..............
00000010: 0040 2701 0000 0000 0a00 0000 0000 0000 .@'.............
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 4152 4d64 4000 0000 ........ARMd@...
As stated in the kernel documentation... ;
find ./build_dir/targ*/linux-*/linux-*/ | grep uefi.rst | grep 'Documentation/arm'
You will need to provide all required options...
hexdump -C _ARMVIRT_EFISTUB/bin/2/openwrt-armvirt-64-Image | head -n23
00000000 4d 5a 00 91 ff ff 21 14 00 00 08 00 00 00 00 00 |MZ....!.........|
00000010 00 e0 9b 00 00 00 00 00 0a 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 41 52 4d 64 40 00 00 00 |........ARMd@...|
00000040 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00 |PE..d...........|
Can I edit the image manually or there is something like size or checksum it this... stub?
Could you please explain how you got this image?
Thanks! Reading uefi.rst...
I've got it!
Just added
CONFIG_EFI_STUB=y
CONFIG_EFI=y
CONFIG_EFI_VARS=y
and:
xxd openwrt-armvirt-64-Image-initramfs | head -n5
00000000: 4d5a 0091 ff3f 1f14 0000 0800 0000 0000 MZ...?..........
00000010: 0010 3e01 0000 0000 0a00 0000 0000 0000 ..>.............
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 4152 4d64 4000 0000 ........ARMd@...
00000040: 5045 0000 64aa 0200 0000 0000 0000 0000 PE..d...........
It looks fine! Thanks wulfy23 !
Now I'll try to boot this.
No luck. It does not boot. (
EFI stub: Booting Linux Kernel...
EFI stub: Generating empty DTB
EFI stub: Exiting boot services and installing virtual address map...
That's all.
edit: possibly? ( no )
CONFIG_EFI_ARMSTUB_DTB_LOADER=y
Thanks, but the same. No boot. =( The same 3 lines and freeze.
Trying in vm (ESXi) and on "hardware" rpi4 (UEFI pftf/RPi4 v1.21).
Does anybody ever boot armvirt64? Even in QEMU direct kernel boot?
I can't boot it!
armvirt32 is working in QEMU with cortex a15 cpu.
works fine for me...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
[ 0.000000] Linux version 5.4.83 (vert@zr) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r15250-0cf3c5dd72)) #0 SMP Sun Dec 20 09:36:51 2020
[ 0.000000] Machine model: linux,dummy-virt
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.60 by EDK II
[ 0.000000] efi: SMBIOS 3.0=0x7bfa0000 ACPI=0x7c030000 ACPI 2.0=0x7c030014 MEMATTR=0x7d9ce018 MEMRESERVE=0x7be4f018
Cool! Please!
Can you share or send me the kernel image (morzexxx_at_gmail)?
Where do you test it (Hardware or hypervisor)?
What did you summary to build it?
as it says in the title ( armvirt64 ) the hardware IS the hypervisor...
IMAGE="openwrt-initramfs.img"
qemu-system-aarch64 \
-smp 2 \
-m 1024 \
-M virt \
-cpu cortex-a57 \
-bios QEMU_EFI.fd \
-nographic \
-kernel $IMAGE \
-device virtio-net-device,netdev=user0 \
-netdev user,id=user0 \
-redir tcp:2222::22
exit 0
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
With this options
CONFIG_EFI_STUB=y
CONFIG_EFI=y
CONFIG_EFI_VARS=y
CONFIG_EFI_ARMSTUB_DTB_LOADER=y
I have
EFI stub: Generating empty DTB
not
EFI stub: Using DTB from configuration table
And freeze. Even in QEMU.
So, I don't understand. 
What am i missing?
Please help!
try removing this...
Removed. the same result...
But miracles do not happen! You somehow got the result!
What am I do wrong?
git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
Then select target QUEMU ARM, subtarget ARMv8, exit with save. Then
cat <<EOF >> target/linux/armvirt/64/config-5.4
CONFIG_EFI_STUB=y
CONFIG_EFI=y
CONFIG_EFI_VARS=y
EOF
make
And I get no-booting images.
if you do what you have always done, you'll get what you've always gotten...
no information you have given validates that statement... read back over this whole thread... and count how many times you make an assumption that 'xyz does not work' and how many times you are correct...
please provide details on how exactly you are performing the testing including qemu version, hostos etc. etc.