Project Mu – A modular UEFI environment for building modern devices
microsoft.github.io
microsoft.github.io
The difficult part about firmware in general (hardware initialization) is still under lock and wrap though: you'll have to get it from the silicon vendors and link it with the open EDK2/Tianocore (which is the UEFI base) and Mu (which is a toolset to extend that base) components to a full firmware image. In particular, those components aren't distributed as part of EDK2 or Mu.
The jokes practically write themselves.
[ this page intentionally left blank ]
Linus' rants on this topic are always worth a read: https://yarchive.net/comp/linux/efi.html
or you can use https://www.linuxboot.org/ as a coreboot payload
Nothing can change the fact. HW vendors doesn't want to release the part of CPU bootcode directly. The most end-users wont care about the initialization detail but just want a working hardware product. Unfortunately, the hardware vendor never compromise and buyers won't have too much consideration about that as they are just selling products for the hardware vendor.
So they have to execute their plan B to bear another ecosystem. But it's hard to tell about how much difference between of them.
Coreboot is just an early stage bootloader that does basic bringup and jumps into a payload… like… TianoCore EDK2 :) Comparing Coreboot with something that can be its payload does not make much sense.
EDK2 does have some PEI code but it's not very interesting. The valuable part is the DXE phase and beyond.
Project Mu is an attempt to make something reasonable out of EDK2, and I commend them for it (EDK2 _really_ needs an effort like this).
But to get a useful (UEFI style) firmware image without signing NDAs (and not the ordinary NDA, the more secret ones) you'll need to combine Project Mu with... coreboot.
And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone.
It's UEFI code that's linked into a separate module. But it's the same code architecture (and largely the same code), just running in a different CPU mode.
> And SMM is way older that UEFI. We'll almost certainly still have SMM after UEFI is gone.
There are experiments at hardware vendors to get rid of SMM. While that will take approximately as long as the age-old attempts to retire legacy PC components (such as the RTC), it's not universally loved by vendors anymore.
And yeah I'm sure places like Google that control the whole stack have the ability and will to get rid of SMM for their own systems but that doesn't make sense for the vast majority of systems, particularly from white box vendors. As an example, new archs like AArch64 and RISC-V have equivalents in EL3/PSCI and Monitor Mode (mandated in all chips) respectively. The concept of a piece of code shipped by your board vendor running under the OS and hypervisor for system management tasks is just too useful of a concept.
Unlike the ME firmware, SMM code is usually built with, shipped with and loaded by the x86 firmware.