Interest in Add UEFI boot options project and some design questions

--00000000000036eb9c064ff8d656
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi tech-install,

I hope you=E2=80=99re doing well.

My name is Gautam Agrawal, and I=E2=80=99m interested in working on the =E2=
=80=9CAdd UEFI
boot options=E2=80=9D 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 resul=
t,
   the firmware lists it as a generic =E2=80=9CMISC DEVICE=E2=80=9D instead=
 of something like
   =E2=80=9CNetBSD 10.x=E2=80=9D.

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 kerne=
l
   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 th=
is
   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=E2=80=99s expectations.

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

Best regards,
Gautam Agrawal

--00000000000036eb9c064ff8d656
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p class=3D"gmail-isSelectedEnd">Hi tech-install,</p><p cl=
ass=3D"gmail-isSelectedEnd">I hope you=E2=80=99re doing well.</p><p class=
=3D"gmail-isSelectedEnd">My name is Gautam Agrawal, and I=E2=80=99m interes=
ted in working on the =E2=80=9CAdd UEFI boot options=E2=80=9D project:<br><=
a href=3D"https://wiki.netbsd.org/projects/project/Add_UEFI_boot_options/">=
https://wiki.netbsd.org/projects/project/Add_UEFI_boot_options/</a></p><p c=
lass=3D"gmail-isSelectedEnd">I have recently started exploring NetBSD and h=
ave been able to:</p><ul><li>Build the NetBSD kernel from source</li><li>Bo=
ot a compiled kernel in a QEMU setup using UEFI firmware</li><li>Install Ne=
tBSD in a UEFI-based environment</li></ul><p class=3D"gmail-isSelectedEnd">=
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 direc=
t 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 syste=
ms.</p><p class=3D"gmail-isSelectedEnd">I had a few questions regarding the=
 expected scope and design direction of this project:</p><ol start=3D"1"><l=
i>Boot entries and BootOrder<br>While installing NetBSD using sysinst in a =
UEFI setup, I observed that the installer copies bootx64.efi to the fallbac=
k path (EFI/BOOT/BOOTX64.EFI), but does not create a Boot#### entry. As a r=
esult, the firmware lists it as a generic =E2=80=9CMISC DEVICE=E2=80=9D ins=
tead of something like =E2=80=9CNetBSD 10.x=E2=80=9D.</li></ol><p class=3D"=
gmail-isSelectedEnd">I also noticed that there exists functionality such as=
 LibInsertToTailOfBootOrder which appears related to managing BootOrder ent=
ries. Is the goal of this project to create a proper Boot#### entry for Net=
BSD and insert it into BootOrder (possibly with a suitable priority)?</p><o=
l start=3D"2"><li>Multi-boot support approach<br>To support multi-boot scen=
arios, I was considering two possible approaches:</li></ol><p class=3D"gmai=
l-isSelectedEnd">a) Extending bootx64.efi (from sys/arch/i386/stand/efiboot=
) to provide a GRUB-like menu that scans disks/partitions and lists availab=
le NetBSD kernels.</p><p class=3D"gmail-isSelectedEnd">b) Converting the Ne=
tBSD kernel image from ELF to PE/COFF format, allowing it to be directly lo=
aded 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.</p><p class=3D"gmail-isSelectedEnd">However, I unders=
tand that this may impact compatibility with existing setups where bootx64.=
efi expects ELF images.</p><p class=3D"gmail-isSelectedEnd">Could you pleas=
e clarify which approach (if any) aligns with the goals of this project, or=
 if both are out of scope?</p><ol start=3D"3"><li>Kernel format and UEFI in=
teraction<br>As mentioned above, I wanted to confirm whether changes such a=
s supporting PE/COFF kernel images fall within the scope of this project, o=
r whether the expectation is to continue using the current ELF-based kernel=
 with bootx64.efi acting as the loader.</li><li>Userland tool for EFI varia=
ble access<br>The project description mentions a userland tool to interact =
with EFI variable storage. I wanted to better understand the expected scope=
 of this tool.</li></ol><p class=3D"gmail-isSelectedEnd">Would it be a mini=
mal interface allowing users to read and write EFI variables by specifying =
the variable name, GUID, attributes, and value (for example: efi_netbsd --r=
ead  --guid  and efi_netbsd --write  --guid  --attributes  )?</p><p class=
=3D"gmail-isSelectedEnd">Or is a higher-level interface expected, such as s=
pecifically managing Boot#### entries and abstracting EFI device paths?</p>=
<p class=3D"gmail-isSelectedEnd">I would appreciate any guidance on these p=
oints, as it will help me align my approach with the project=E2=80=99s expe=
ctations.</p><p class=3D"gmail-isSelectedEnd">Thank you for your time, and =
I look forward to contributing.</p><p>Best regards,<br>Gautam Agrawal</p></=
div>

--00000000000036eb9c064ff8d656--