Boot Custom Kernel with UEFI in QEMU

Very surface-level answer since I don’t really have sufficiently deep knowledge:

When I run file myKernel.img in Ubuntu, I get this output:

That’s what you usually get when the file isn’t in any specific format other than “raw blob of machine code”, i.e. it has no recognizable header and the file command ends up showing its closest guess. (It makes most of its decisions based on a few leading bytes, and the ARM machine code probably happens to coincide with a valid OpenPGP header.)

the kernel option says this: kernel= - Linux kernel image file

Then it most likely expects the image to have a Linux-like header that indicates which base address the image should be loaded at, where the entry point is, etc. Your -O binary output does not have any such information.

(It’s similar in concept to the ELF header which you are currently removing, although highly Linux-specific and platform-dependent; e.g. Linux on x86 would use a more complex handshake than it does on AArch64.)

Although when it’s used in combination with UEFI, I’d almost expect this option to require an EFI-format image file rather than a Linux-kernel file.

I’ve read about UEFI stubs online, but I think that’s for Linux kernels only.

Only the stub part (i.e. the concept of gluing a bootloader directly onto the kernel image) is Linux-specific, but the overall problem it solves is UEFI-specific.

UEFI cannot directly accept raw “load at X and jump to Y” images like what your objcopy -O binary produces, as it doesn’t know where to load it and where the entry point is. Instead, it expects to be provided an .efi file in the PE/COFF format (aka literally an .exe file by another name) which has this information.

Traditionally this would have been a dedicated bootloader (e.g. grubx64.efi or elilo.efi) which then knows how to launch a Linux kernel, and that applies equally to any OS that boots through UEFI – e.g. Windows starts via winload.efi – and the only Linux-specific part is the combining of the two functions into one dual-faced “vmlinuz but with PE/COFF makeup” .efi file.

So either your build output itself is wrapped into a PE/COFF header so that it becomes a valid .efi file for UEFI to run (possibly using elf2efi), or you need to use an intermediary such as GRUB or U-Boot (i.e. which already is a valid .efi program in itself) to load it.