Interest in Add UEFI boot options project and some design questions

[Gautam Agrawal <gautamnagrawal%gmail.com@localhost>]

Hi tech-install,

I hope you’re doing well.

My name is Gautam Agrawal, and I’m interested in working on the “Add UEFI boot options” project:
https://wiki.netbsd.org/projects/project/Add_UEFI_boot_options/

I have recently started exploring NetBSD and have been able to:

• Build the NetBSD kernel from source
• Boot a compiled kernel in a QEMU setup using UEFI firmware
• Install NetBSD in a UEFI-based environment

I am interested in working on this project because of my strong interest in UEFI and kernel-level systems. Although the project does not involve direct firmware development, it involves interaction between the kernel and UEFI, which I find particularly interesting. I have prior experience working on firmware for embedded systems as well as Linux kernel drivers. While I am still getting started with NetBSD, I have long been interested in BSD systems.

I had a few questions regarding the expected scope and design direction of this project:

1. Boot entries and BootOrder
   While installing NetBSD using sysinst in a UEFI setup, I observed that the installer copies bootx64.efi to the fallback path (EFI/BOOT/BOOTX64.EFI), but does not create a Boot#### entry. As a result, the firmware lists it as a generic “MISC DEVICE” instead of something like “NetBSD 10.x”.

I also noticed that there exists functionality such as LibInsertToTailOfBootOrder which appears related to managing BootOrder entries. Is the goal of this project to create a proper Boot#### entry for NetBSD and insert it into BootOrder (possibly with a suitable priority)?

2. Multi-boot support approach
   To support multi-boot scenarios, I was considering two possible approaches:

a) Extending bootx64.efi (from sys/arch/i386/stand/efiboot) to provide a GRUB-like menu that scans disks/partitions and lists available NetBSD kernels.

b) Converting the NetBSD kernel image from ELF to PE/COFF format, allowing it to be directly loaded by UEFI via the LoadImage() interface, and creating separate Boot#### entries per kernel. In this case, bootx64.efi could optionally also support loading such images.

However, I understand that this may impact compatibility with existing setups where bootx64.efi expects ELF images.

Could you please clarify which approach (if any) aligns with the goals of this project, or if both are out of scope?

3. Kernel format and UEFI interaction
   As mentioned above, I wanted to confirm whether changes such as supporting PE/COFF kernel images fall within the scope of this project, or whether the expectation is to continue using the current ELF-based kernel with bootx64.efi acting as the loader.
4. Userland tool for EFI variable access
   The project description mentions a userland tool to interact with EFI variable storage. I wanted to better understand the expected scope of this tool.

Would it be a minimal interface allowing users to read and write EFI variables by specifying the variable name, GUID, attributes, and value (for example: efi_netbsd --read --guid and efi_netbsd --write --guid --attributes )?

Or is a higher-level interface expected, such as specifically managing Boot#### entries and abstracting EFI device paths?

I would appreciate any guidance on these points, as it will help me align my approach with the project’s expectations.

Thank you for your time, and I look forward to contributing.

Best regards,
Gautam Agrawal