I added a builder to the flake, to build the image without entering the devshell. I also added a builder to automatically create a release archive containing BootISO, an ISO9660 driver and the UEFI Shell. There is also now a README with instructions on how to run bootiso, and a file with license notices for my dependencies.

HEUREKA, it lives!

The ramdisk is now mounted using another SimpleFileSystem. However, this comes with an external dependency on an ISO9660 driver, which must be loaded before bootiso.efi is launched. Maybe I can automate that too.
But yes, the ISO correctly loads its bootloader, and I get to the GRUB menu. Sadly, once Linux is loaded, there are errors about a missing fd0 device, which is probably one of the harder parts of this project (if it wasn’t hard enough up until now).

This is a small fix with a big effect: I forgot to initialize the DevicePath-pointer-pointer when registering the ramdisk. I now instead create a mutable reference of a pointer, which is initialized by Rust and automatically converted to a pointer by the FFI. And, lo and behold: The image loads (slowly…), and the RAM disk is mounted.
I also got QEMU to work again, the default behavior did not give the VM enough RAM. It now gets 2G, which should be enough for both the RamDisk and Arch. Just, don’t select copytoram.

I can now successfully read the file from disk into RAM!

Instead of uefi::fs, I again use the SimpleFileSystem protocol directly.
This is so I can allocate the buffer myself using allocate_pages, bypassing the heap. This unfortunately introduces another unsafe block, but that’s a small price to pay.
After that, the file also successfully reads into RAM. read contains logic to read in 1KiB blocks, to bypass bugs in some firmwares.
Next stop: Mounting the RAM Disk, using my self-made FFI wrapper.
Currently, it returns EFI_INVALID_PARAMETER, meaning that one of the parameters is NULL, for some reason.

In the last two and a half hours, I wrote my own wrapoer for the Ram Disk protocol.
The uefi crate doesn’t support this protocol yet, so I had to hack together my own support.
Now, it for some reason can’t find the LoadedImage handles… but that is something I will fix after lunch.

I started building BootISO, an EFI application to boot ISO images from GRUB/rEFInd, the EFI shell, or (on some systems and probably not really viable), the Boot Options menu.
Currently, it opens a file handle to an ISO file, which in further development will be copied to a ramdisk, which can then hopefully be used for booting. Unfortunately, neither OVMF nor my laptop seem to support Simple File System, so I’ll need to check how to load the file instead.
Up to there, there aren’t any errors, so I feel quite confident, although a debugger might end up coming in handy …
I’ve gotten used to the architecture of the UEFI crate by now, which should probably speed up development and reduce AI usage further along.
(edit: it turns out I accidentally used the LoadedImage handle to initialize SimpleFileSystem 🤦)