Does someone tried the qemuarm64 w/ grub?

General Discussions
1

Hi,

I’m already using qemux86_64 with grub-efi and it’s working perfectly :slight_smile:

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

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

2

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)

3

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

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:

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.

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.

# 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 !

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

After cloned the meta-arm repo 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 correct, but still doesn’t boot :frowning: with the same message…

6

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.

7

I have sent a message to meta-arm will see if they can provide some support.

The console is configured like this:

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 :slight_smile:

8

Meta-arm maintainer replied I was missing one EFI patch . See Re: Help to boot QEMU ARM64 UEFI

Now it works perfectly :blush:

9

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

10

Hi,

All is explained in my previous post

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.

11

Hi @clementp,

just trying to replicate here now. Layers in use are

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

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


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

12

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

13

Indeed, seems to make it work that way. Additionally, I needed:

MENDER_STORAGE_DEVICE = "/dev/vda"
1 Like
14

This is very interesting! I’ll try this trick next time I run into a platform with similar issues!