As well, below is Mullvad’s corresponding blog post:

https://mullvad.net/en/blog/2019/8/7/open-source-firmware-fu...

I'm not well versed on this; does the BMC code also get replaced, or is this the motherboard firmware only?

This is for the BIOS. However, excitingly, this is the same board that I'd spent some time porting various bmc efforts to, so we can now have both on the same platform. I need to get those patches rebased, but I've been running a board locally with both bios and bmc firmware open source.

Motherboard only. On the other hand, ASPEED 2400 is supported by OpenBMC.

Thanks, very interesting!

The 2016 OpenBMC presentation I'm watching now says that it's REST+D-Bus, and no IPMI, which actually seems like a good idea to me...

Unless you need to be compatible with some existing provisioning system.

True; though it does look like there's an ipmitool that uses the REST/D-Bus interface:

https://github.com/openbmc/ipmitool

so as long as your provisioning tool uses ipmitool, it could work.

The post does indicate IPMI support; are you referring to a more full-featured vendor specific system?

The elephant in the room: How many binary blobs are in use for the system firmware?

Still interesting work though

I mean you have to get coreboot functioning before getting to libreboot don't you?

libreboot is a fork of coreboot, so yes.

But if a system supported it through reverse engineering or otherwise I don't see why running coreboot without blobs would be possible (see very old hardware for example)

Don’t let perfect be the enemy of good

Of course not. Just wondering for transparencies sake and would could be possibly be improved in the future.