# Does someone tried the qemuarm64 w/ grub?
**URL:** https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323
**Category:** General Discussions
**Tags:** qemu
**Created:** [October 17, 2022, 5:12pm UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323 "2022-10-17T17:12:38Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@clementp](https://hub.mender.io/u/clementp)
#### Post date: [October 17, 2022, 5:12pm UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/1 "2022-10-17T17:12:38Z")
Hi,
I’m already using qemux86\_64 with grub-efi and it’s working perfectly 🙂
I would like to port this to have native virtualization on Apple M1/M2 silicon.
At the moment I simply change the machine to use the qemuarm64 machine but it stay stuck at grub
```auto
BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x4,0x0)
BdsDxe: starting Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x4,0x0)
Welcome to GRUB!
lock: OK
lock: OK
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
```
Does somebody already tried this ?
Any idea what i’m missing ?
Thanks for your help
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [October 19, 2022, 7:24am UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/2 "2022-10-19T07:24:29Z")
I have seen this on some ARM boards, and usually it means that the UEFI support is incomplete for that board. But in the ARM case, U-Boot is used as a UEFI provider, and it does have some shortcomings.
Is it ovmf which is used for qemuarm64? (Check the deploy folder for `ovmf` files)
---
### Author:  [@clementp](https://hub.mender.io/u/clementp)
#### Post date: [October 21, 2022, 9:03am UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/3 "2022-10-21T09:03:25Z")
Hi @kacf,
Indeed looking in the deploy folder there are no EFI nor OVMF.
OVMF for AARCH64 seems not supported in Yocto:
[http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/ovmf/ovmf\_git.bb?h=master#n47](http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/ovmf/ovmf_git.bb?h=master#n47)
But it’s not because OVMF is not build from Yocto that the Uefiimg should not boot no?
Launching the image manually with the following cmd:
```auto
qemu-system-aarch64 \
-machine virt \
-name "Virtual Machine" \
-m 4G \
-smp 6 \
-cpu cortex-a57 \
-drive file=./IMAGE.uefiimg,if=virtio,format=raw \
-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd \
-nographic
```
gives me both with QEMU on Linux x86 or MacOS Aarch64.
```auto
BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found
BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)
BdsDxe: starting Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)
Welcome to GRUB!
lock: OK
lock: OK
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
```
Which means grub is properly loaded
Mounting the .bootimg shows that grub.cfg is wrong.
```auto
# Start of ---------- 00_mender_grubenv_defines_grub.cfg ----------
mender_rootfsa_part=2
mender_rootfsb_part=3
mender_kernel_root_base=/dev/mmcblk0p
kernel_imagetype=Image
mender_rootfsa_uuid=537fe27c-72c0-4a5b-b612-3b909d51ef64
mender_rootfsb_uuid=2c2d0813-46bf-4c42-b4f1-80207d807876
```
I will investigate this thanks for your help !
---
### Author:  [@clementp](https://hub.mender.io/u/clementp)
#### Post date: [October 25, 2022, 2:57pm UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/4 "2022-10-25T14:57:41Z")
Ok, I have updated my meta-mender branch and found that the MENDER\_EFI\_LOADER was defaulted to u-boot because it’s aarch64 see [meta-mender/mender-setup-grub.inc at master · mendersoftware/meta-mender · GitHub](https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/classes/mender-setup-grub.inc#L29)
After cloned the [meta-arm repo](https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-bsp/uefi) and add the edk2-firmware recipe.
I changed the machine to get something like this
```auto
require conf/machine/qemuarm64.conf
# Boot the image via EFI
EFI_PROVIDER = "grub-efi"
MACHINE_FEATURES += "efi"
MENDER_EFI_LOADER = "edk2-firmware"
```
Now the grub.cfg is correct, but still doesn’t boot ☹ with the same message…
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [October 26, 2022, 7:32am UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/6 "2022-10-26T07:32:42Z")
Ok, all of that looks correct to me.
Could it be that you’re simply not seeing the output? Are you sure the `console` argument to the kernel is correct?
Besides that I think you’re at the point where you need to start debugging the boot process at a pretty low level, so asking in bootloader and/or board vendor forums may be a better route.
---
### Author:  [@clementp](https://hub.mender.io/u/clementp)
#### Post date: [October 28, 2022, 4:34pm UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/7 "2022-10-28T16:34:00Z")
I have sent a message to meta-arm will see if they can provide some support.
The console is configured like this:
```auto
set console_bootargs="console=tty0,115200n8 console=ttyS0,115200n8 console=ttyO0,115200n8 console=ttyAMA0,115200n8"
```
Will let you know if I’m able to fix it
Thanks for the help 🙂
---
### Author:  [@clementp](https://hub.mender.io/u/clementp)
#### Post date: [October 29, 2022, 10:32am UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/8 "2022-10-29T10:32:07Z")
Meta-arm maintainer replied I was missing one EFI patch . See [Re: Help to boot QEMU ARM64 UEFI](https://lists.yoctoproject.org/g/meta-arm/message/4058)
Now it works perfectly 😊
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [October 29, 2022, 12:42pm UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/9 "2022-10-29T12:42:48Z")
Hi @clementp ,
Thanks a lot for the heads up and glad you got it working. Do you think you can maybe assemble a short guide so others can use this too? If you need help, then you can also shoot me just a rough list of bullets and I can put it into a more polished form.
Greetz,
Josef
---
### Author:  [@clementp](https://hub.mender.io/u/clementp)
#### Post date: [October 29, 2022, 1:14pm UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/10 "2022-10-29T13:14:06Z")
Hi,
All is explained in my previous post
> [@Does someone tried the qemuarm64 w/ grub?](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/4):
>
> Ok, I have updated my meta-mender branch and found that the MENDER\_EFI\_LOADER was defaulted to u-boot because it’s aarch64 see [meta-mender/mender-setup-grub.inc at master · mendersoftware/meta-mender · GitHub](https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/classes/mender-setup-grub.inc#L29) After cloned the [meta-arm repo](https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-bsp/uefi) and add the edk2-firmware recipe. I changed the machine to get something like this require conf/machine/qemuarm64.conf # Boot the image via EFI EFI\_PROVIDER = "grub-efi" MACHINE\_FEATURES += "efi" MENDER\_EFI\_LOADER = "edk2-firmware" Now the grub.cfg is cor…
I was just missing the efi patch and didn’t do any other trick.
I’m on a downstream branch based on hardknott, it should be straightforward on kirkstone.
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [October 31, 2022, 6:49am UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/11 "2022-10-31T06:49:58Z")
Hi @clementp,
just trying to replicate here now. Layers in use are
```auto
BBLAYERS ?= " \
/home/jd/qemuarm64/poky/meta \
/home/jd/qemuarm64/poky/meta-poky \
/home/jd/qemuarm64/poky/meta-yocto-bsp \
/home/jd/qemuarm64/meta-arm/meta-arm-toolchain \
/home/jd/qemuarm64/meta-arm/meta-arm \
/home/jd/qemuarm64/meta-openembedded/meta-oe \
/home/jd/qemuarm64/meta-mender/meta-mender-core \
/home/jd/qemuarm64/meta-mender/meta-mender-demo \
/home/jd/qemuarm64/meta-mender/meta-mender-qemu \
"
```
local.conf is standard with added
```auto
MACHINE = "qemuarm64"
MENDER_ARTIFACT_NAME = "qemuarm64_1"
INHERIT += "mender-full"
# Boot the image via EFI
EFI_PROVIDER = "grub-efi"
MACHINE_FEATURES += "efi"
MENDER_EFI_LOADER = "edk2-firmware"
```
Then the build is blocked with
```auto
ERROR: Nothing PROVIDES 'edk2-firmware'
edk2-firmware was skipped: incompatible with machine qemuarm64 (not in COMPATIBLE_MACHINE)
```
So I guess I’m missing some part?
Greetz,
Josef
---
### Author:  [@clementp](https://hub.mender.io/u/clementp)
#### Post date: [October 31, 2022, 8:07am UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/12 "2022-10-31T08:07:00Z")
Hi @TheYoctoJester
I think you don’t need meta-mender-qemu as it’s only for testing purposes.
I think you’re missing one patch
>
>
> Add basic support for running edk2 on qemuarm and qemuarm64. This
> necessitated …the need to add ACPI and EFI to the default kernel configs
> for these machines.
>
> Signed-off-by: Jon Mason \
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [October 31, 2022, 3:59pm UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/13 "2022-10-31T15:59:16Z")
Indeed, seems to make it work that way. Additionally, I needed:
```auto
MENDER_STORAGE_DEVICE = "/dev/vda"
```
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [November 4, 2022, 8:14am UTC](https://hub.mender.io/t/does-someone-tried-the-qemuarm64-w-grub/5323/14 "2022-11-04T08:14:58Z")
> [@clementp](#):
>
> Meta-arm maintainer replied I was missing one EFI patch . See [Re: Help to boot QEMU ARM64 UEFI](https://lists.yoctoproject.org/g/meta-arm/message/4058)
>
> Now it works perfectly 😊
This is very interesting! I’ll try this trick next time I run into a platform with similar issues!