https://wiki.osdev.org/UEFI_Bare_Bones
Until recently, almost every UEFI app had to be written in C/C++.
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.
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.
And yes, I'm aware of most of that, it has always bugged me that my mobo's UEFI is typically larger than the kernel it runs.
It will require some storage (local EFI filesystem) or network location to load them from, but that's it.