I've seen a lot of interesting UEFI articles recently, but even before they made it on to HN it was always something you could only play with in QEMU. Is there any open hardware yet?
If I'm reading this correctly, at least this repository is about writing applications that run on top of UEFI rather than building the platform itself, in which case the resulting applications should probably work on any normal computer provided secure boot doesn't get in your way.
You make a bootup disc (or USB) like your typical dual booting procedure. Then go into BIOS (I am using the legacy name for the modern UEFI menu) and boot up from there. It is the same as any OS development except that UEFI provides you with a number of APIs including a mini filesystem, a primitive shell, a graphics API, and some other stuff. To make it easier, you can think of your computer running pure UEFI apps as a giant, overpowered Arduino.
Quite a number of the arm boards have open UEFI ports. Tianocore edk-platforms
https://github.com/tianocore/edk2-platforms/tree/master/Plat...
has a number that are maintained together. Others can be found in various places on github and/or a vendors site.
Of note, the rpi3/4 are both supported. The hardware isn't particularly open, but they have been reverse engineered to the point where even the videocore firmware has a open source project ongoing to replace it.
There are also various tutorials for getting inexpensive jtag probes working with openocd on the rpi3/4 so its possible to have a fully opensource firmware development stack.
Edit: There are a couple intel ports as well, if that is one's preferred platform.
You can still port EDK2 to the hardware of your choice. Most people can have a quick play on it on Raspberry Pi >= 3.
Also yes, EDK2 is a faithful implementation of UEFI standard and so if you do target EDK2 it should run on your typical amd64-based computer without issue.
By the way the UEFI platform is actually a partial OS itself! Memory allocation and paging is handled and there are even partial event system support, making it possible to run asynchronous code in Rust-based UEFI firmware. However one caveat is that UEFI itself is split into Runtime services and Boot services and their memory is not shared after the transition. uefi-rs exploited the borrow checker to cleverly mitigate this issue.
Sadly uefi-rs doesn’t have most of the UEFI API wrappers. I tried porting some of it but it’s just too complicated and I don’t really have the time to churn on it.
You can load your own modules on your own hardware, so certain level of play is still available for you. Worst case you will have to put a custom bootloader setup that can be as simple as shell with autostart script, that for example loads your modules as drivers.
It will require some storage (local EFI filesystem) or network location to load them from, but that's it.
Very cool.. curious how many of the major cloud providers support a self-made VM image, and UEFI based images to boot from. Could be an effective means of app-as-os for virtualized environments (or raw environment, iot etc).
"This device can cook an apple into a perfect plasma." (feature)! Yeah but who needs it (use case)? Beings from the 5th dimension who eat plasma for breakfast.
But even then you would still owe to show the relevance of the use case.