UEFI is not a big bloat of closed source. UEFI is a spec that defines a newer, more feature-rich and easily-extensible way to boot than legacy BIOS. There is a common core, used by just about every single UEFI-based firmware out there, that is completely open source available here https://github.com/tianocore/edk2 and it's completely possible to ship a fully open UEFI system.
It happens to be the case that most organizations using UEFI-based firmware don't, and they keep everything beyond that core closed-source. This is not the fault of UEFI - those companies were closed source beforehand, and that trend continued. UEFI neither caused nor enabled them to be that way.
Now you may not want any of the things UEFI brings to the table, like GPT and booting to partitions larger than 2.2TB, or filepath based booting rather than sector based booting (or sector-booting into a boot manager and file booting from there). That's fine, but there's a difference between "X provides Y which I don't need" and "X causes Z which is bad" - UEFI causes almost none of the things people blame it for.
If you must blame UEFI for one thing, you can blame it for Secure Boot, as that wasn't (easily) possible with legacy BIOS. But neither is it mandated what keys it does or doesn't include, or even that it be implemented/enabled! UEFI has nothing to do with whether you should use Secure Boot - only that you can. The blame lies mostly with Microsoft for pushing so hard on vendors to ship with it enabled/locked/whatever.
> If wanting to run Coreboot on a system today it basically means running a Google Chromebook, using an outdated server motherboard or old Lenovo ThinkPad that has seen a Coreboot port, or out of reach to most individuals are various server motherboards that are reference platforms or board designs from hyperscalers. But over the past several months the folks at the 3mdeb consulting firm have carried out a terrific feat: porting their "Dasharo" downstream of Coreboot to a modern and readily available Intel desktop motherboard. I've been trying this out and it has worked out surprisingly well.
Correct. coreboot support for MSI PRO Z690-A WiFi DDR4 (mentioned ADL dream), as well as PC Engines and Proteclti was provided by https://3mdeb.com. Full disclosure: I'm Founder and CEO of 3mdeb.
There are some other boards you may be interested in, which you can find at https://docs.dasharo.com/ Supported Hardware section.
This is a bit of nebulous area, IANAL but I am not sure I would want to develop _open_ source medical device firmware.
Medical devices have a lot of strict regulations from multiple certification bodies (most famous one being FDA). Under IEC 62304, any RTOS becomes a SOUP item (Software Of Unknown Provenance). In practice this means that you would have to provide beyond reasonable evidence that the RTOS will do what you say it does, consistently. This is a long and expensive regulatory endeavor.
If you are going through the certification process and selling a medical device and then choose to open source its firmware, then more power to you.
However if you are thinking of publishing _open_ source firmware that will work on either 3rd party or open hardware, in my opinion you are setting yourself up for a world of litigation that very few individual persons can afford.
It is fairly easy to backdoor or infect firmware, yet very few companies use components with open source firmware.
Infections can be dealt with frequent firmware verification but only solution for backdoors seems to be open source firmware.