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.
1 Like
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.
Sorry for wasting your time... And sorry for my poor English.
All I do in Ubuntu 20.04 TLS @ intel PC.
qemu-aarch64 version 4.2.1 (Debian 1:4.2-3ubuntu6.10)
I need to run Openwrt as ESXi-arm64 guest VM.
I trying to boot at: QEMU, ESXi, rpi4-UEFI.
And all this three times I get the same.
EFI stub: Booting Linux Kernel...
EFI stub: Generating empty DTB
EFI stub: Exiting boot services and installing virtual address map...
So, I think there no difference where to test (as I see yet).
If you send me a working initramfs image, I test it and tell you where it boots in my 3 cases.
This will clear the "bad-testing" thinking.
1 Like
this is totally vague and not an openwrt issue...
no information provided about all of the fundamental properties required at boot time... ( drives, filesystems, blobs, dts location etc. etc. )
i've provided a functional example on QEMU... if you are having issues with specific VENDOR hypervisor stacks ( and are not able to articulate or troubleshoot at the necessary levels ) then I suggest you take it up with their support channels...
Can you send me your working initramfs-image please, please, please? And if it boots it's an Openwrt issue. May be it will boots all three hosts. I believe ) Ii it boot even ones, I am going forward, if not - it's a stuck.
Added
CONFIG_ARCH_SUPPORTS_ACPI=y
CONFIG_ACPI=y
And now it boots fine and working in KVM !
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
[ 0.000000] Linux version 5.4.83 (ubuntu@fit) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r15241-3ab695368a)) #0 SMP Fri Dec 18 22:05:50 2020
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.70 by EDK II
[ 0.000000] efi: SMBIOS 3.0=0x7bef0000 MEMATTR=0x7aa05518 ACPI 2.0=0x78520000 MEMRESERVE=0x7850f018
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x0000000078520000 000024 (v02 BOCHS )
[ 0.000000] ACPI: XSDT 0x0000000078510000 00004C (v01 BOCHS BXPCFACP 00000001 01000013)
[ 0.000000] ACPI: FACP 0x00000000784D0000 00010C (v05 BOCHS BXPCFACP 00000001 BXPC 00000001)
[ 0.000000] ACPI: DSDT 0x00000000784E0000 004842 (v02 BOCHS BXPCDSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: APIC 0x00000000784C0000 0000F4 (v03 BOCHS BXPCAPIC 00000001 BXPC 00000001)
[ 0.000000] ACPI: GTDT 0x00000000784B0000 000060 (v02 BOCHS BXPCGTDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: MCFG 0x00000000784A0000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001)
[ 0.000000] ACPI: SPCR 0x0000000078490000 000050 (v02 BOCHS BXPCSPCR 00000001 BXPC 00000001)
[ 0.000000] ACPI: SPCR: console: pl011,mmio,0x9000000,9600
[ 0.000000] psci: probing for conduit method from ACPI.
[ 0.000000] psci: PSCIv0.2 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: Trusted OS migration not required
[ 0.000000] percpu: Embedded 20 pages/cpu s44696 r8192 d29032 u81920
[ 0.000000] Detected PIPT I-cache on CPU0
[ 0.000000] CPU features: detected: ARM erratum 832075
[ 0.000000] CPU features: detected: EL2 vector hardening
[ 0.000000] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
...
but it NOT boots on ESXi or rpi4.
Is it possible and a good idea to run Debian as a vm on RasberryPi4 Openwrt host? Is qemu in Openwrt working?
I've put this together and it's working on Pi 4 8GB (ESXi-Arm Fling), Includes EFI stub/GrubEFI
https://www.mediafire.com/file/7eg3ac2d30wd74u/OpenWrt.zip/file. Welcome to try it
2 Likes
It works!!! It's works so fine and fast so I am happy. Installed luci - It's flying! Kernel modules installs also fine! Network ping <1ms! It's a really working OpenWrt 19.07.5 release for arm64 ESXi ! Thanks statto99!
So, it would be nice to see a release like this in the download list (make it publicly available now and forever). It's very cool that some problems are being solved in real life!
It seems, it works faster than native on this rpi!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.