Article A Hardware enthusiast view on the usefulness of open source Firmwares like Coreboot

[zir_blazer]

I'm posting to blatantly self-advertise this: https://zirblazer.github.io/htmlfiles/coreboot.html?ver=123

I took my time to write the linked Wall of Text® with the purpose of educating/influencing Hardware enthusiasts communities about the need to push for open source Firmwares, and perhaps with even more luck, Motherboards with open Hardware designs. These are my personal thoughts and nearly all the input I have on this matter. If you read it, you will know almost as much as I do about it.

You will notice that there is a major difference regarding my approach and nearly everyone else that you have read talking about this matter previously. I'm not of the "INTEL ME/AMD PSP VIOLATES MY PRIVACY!1!1!1" and "THE NSA AND USA GOVERMENT ARE SPYING ON ME!" crowd. I have an actual agenda regarding functional issues where I think that an open source Firmware could kick propietary Firmware butt, and I cover it with enough detail as to drive that point.

 

[sdifox]

Given how varied the hardware setup is between boards, how are you going to handle that?

 

[zir_blazer]

Given how varied the hardware setup is between boards, how are you going to handle that?

It already handles that.

 

[zir_blazer]

*BUMP*

Seriously, no comments? Taking full control over the Firmware is perhaps the greatest thing left to do for Hardware enthusiasts, yet I'm surprised that the interest in doing so is, roughly, zero. There are so many Firmware-level issues that forces you to beg to ASUS/MSI/Gigabyte/ASRock/whoeverelse to fix them for you and can potentially wreck a perfectly fine Motherboard if they don't want to. I find dissapointing that no one cares about finding solutions for that matter that are superior to traditional BIOS modding.

 

[zir_blazer]

Second *BUMP*

Now that everyone is angry about the situation with AMD announcing that it will not support Zen 3 in older AM4 Motherboards, maybe there is more people interesed in the potential of this.

 

[DrMrLordX]

Microsoft wouldn't like that. Intel wouldn't either. Not sure about AMD but I'm guessing . . . no.

 

[zir_blazer]

Microsoft wouldn't like that. Intel wouldn't either. Not sure about AMD but I'm guessing . . . no.

Intel wouldn't? Then that means that you're unaware that Intel is currently supporting open source Firmware efforts quite well. Intel releases the required binary blobs usually on time for launchs. And open source Firmwares are getting quite popular for cloud providers:
https://www.phoronix.com/scan.php?page=news_item&px=Online-Scaleway-Coreboot-Server
https://osfc.io/uploads/talk/paper/43/Open_Source_Firmware_in_the_Bare-Metal_Cloud.pdf
https://www.opencompute.org/blog/li...er-powered-by-intelr-xeonr-scalable-processor

AMD used to be more supportive than Intel BEFORE Zen. With Zen, you're not getting anything without a NDA. Yet you have currently major documentation due to Google porting Picasso to Coreboot and making their notes public:

1. AMD Platform Security Processor (PSP) Firmware Integration Guide — coreboot 24.02-168-g1879b6a34a documentation

AMD Family 17h in coreboot — coreboot 24.02-168-g1879b6a34a documentation

The ones that are failing behind here is the DIY market, and AMD, yet it is absolutely implementable RIGHT NOW on Intel platforms. The problem here is that ASUS, AsRock, Gigabyte and MSI will never make schematics available, thus you would have to reverse engineer Motherboards unless you get someone to design one from the ground up (Which actually, is within the realm of the possible, as it seems that small-medium sized business have pulled out such things already).

 

[DrMrLordX]

Intel wouldn't? Then that means that you're unaware that Intel is currently supporting open source Firmware efforts quite well. Intel releases the required binary blobs usually on time for launchs. And open source Firmwares are getting quite popular for cloud providers:

On consumer devices? Color me skeptical.

 

[zir_blazer]

On consumer devices? Color me skeptical.

Last time I checked, the System76 Notebooks were considered such. Do Purism Librem ones qualify, too?

 

[DrMrLordX]

ehhhhh

I'm talking Dell, HP, Lenovo, etc.

So I'd say mostly, "no". They don't qualify. Those specific companies will support CoreBoot because it's part of their mission statement. CoreBoot threatens too many people's business models. The UEFI standard was created the way it was for a reason. And that was to take control away from the end user, not grant more control (ala CoreBoot).

 

[DrMrLordX]

Hmm, interesting. Wonder what MS has to say about all that.

 

[Shmee]

Could this support BCLK overclocking on skylake and kabylake systems? If so that would be really cool.

 

[zir_blazer]

Hmm, interesting. Wonder what MS has to say about all that.

What would Microsoft say? It has zero input on this matter since this only tangentially affects it. And its soft power is not what it used to be anyways, so I wouldn't even consider Microsoft the current open source boogeyman...
If anything, I would be more worried about what OEMs have to say. When they implement certain features like Intel Boot Guard or AMD Platform Secure Boot, they are being far more harmful for Coreboot or other open source Firmware efforts. Basically, the Hardware itself has an OTP (One Time Programmable) fused crypto key and checks whenever the Firmware image is signed by a specific vendor, so you're pretty much forced to use the original propietary Firmware because the Hardware would refuse passing POST with Firmware images not signed by that OEM.

Microsoft side, Secure Boot is well supported on both TianoCore (UEFI) and OVMF (TianoCore for VMs). You could make an open source Firmware that already comes with the two public Microsoft certificates (Microsoft Windows Production PCA 2011 and Microsoft Corporation UEFI CA 2011) embedded with Secure Boot enabled by default with no way to disable it, and get the expected vendor lock-in experience.

Could this support BCLK overclocking on skylake and kabylake systems? If so that would be really cool.

On paper, yes. Do note that BCLK overclocking on non-K Skylakes was supported only on very early Microcode before Intel removed such possibility, and I don't think that you can bypass that. The advantage would be that whereas with propietary Firmwares you had to either stick to a very old BIOS version since any newer version with newer Microcode removed the feature, with open source you may be able to mix and match old Microcode support with BCLK overclocking with fixed stuff from newer unrelated modules.

 

[DrMrLordX]

What would Microsoft say? It has zero input on this matter since this only tangentially affects it. And its soft power is not what it used to be anyways, so I wouldn't even consider Microsoft the current open source boogeyman...
If anything, I would be more worried about what OEMs have to say.

Intel and MS were instrumental in pushing the current closed UEFI standard on x86 PCs. I would see the two of them as being the greatest impediments to a movement away from close-sourced UEFI; that being said, AMD is probably no great friend of something like coreboot either.

 

[zir_blazer]

Intel and MS were instrumental in pushing the current closed UEFI standard on x86 PCs. I would see the two of them as being the greatest impediments to a movement away from close-sourced UEFI; that being said, AMD is probably no great friend of something like coreboot either.

Where are you getting that UEFI is closed? The UEFI specifications are freely downloadable since 2015 or so. Previously you needed to sign a minor online agreement and provide contact data to be allowed to download them (You needed a license if you were planning to actually implement UEFI, but the specs themselves were free. And I'm not sure if the license actually cost money or is just an agreement since they only mention the 2500 U$D annual membership to be an UEFI Forum member. Nor whenever such license is still needed).
Also, TianoCore is supposed to have been open source since 2004 or so, as the Intel reference UEFI implementation. Intel did the same thing with ACPICA, Intel own open source ACPI interpreter when it was pushing its adoption circa 2001 or so. So no, all the claims that UEFI is a closed standard are bogus. If anything, I'm curious about how much it charged to legally ship products based on it, which is the only valid argument. But currently it seems that you're able to do it for free.
And if you STILL don't like UEFI, you can use SeaBIOS and boot Windows 10 either 32 or 64 Bits in BIOS-MBR mode instead of UEFI-GPT. Is not that the BIOS is good to begin with, it is a de facto hodgepodge with no unifying specification whatovers with baggage carried since the days of the 1981 IBM PC 5150. Cross compatibility is achieved because during the 90's the IBVs noticed that they needed to support the same interfaces so there were a few baseline specifications (PCI BIOS, PnP BIOS and ACPI itself, but all those were extensions). UEFI was supposed to fix that.


AMD has been far more helpful to Coreboot pre-Zen. AGESA was open source at some point. You may even want to check this 2006 AMD presentation on a Coreboot meeting to show the effort was serious, I recall reading in Coreboot mailing list things coming from AMD developers. What happened is that AMD closed up everything with Zen, reasons unknow.


Seriously, if you do your homework you will notice that there is no real showstopper besides the lack of interest from the actual end users. With the exception of current AMD platforms, at least on the Intel side you have everything in place to get this running.

 

[DrMrLordX]

Where are you getting that UEFI is closed?

SecureBoot, for the most part. Also AMD has (as you indicated) become less-forthcoming about their AGESA implementations.

 

[zir_blazer]

One of the most interesing things that happened recently is the "Pure Open Source on an AMD Zen" talk done by the founder of LinuxBIOS/Coreboot during this year OSFC (Open Source Firmware Conference) saying how he managed to get an EPYC Rome running and loading a Linux Kernel with pure open source Firmware, no binary blobs.

Pure open source on an AMD Zen - Ronald G. Minnich

This talk will discuss project X, which is aimed at eXcising binary blobs from the x86 part of Zen CPUs. These parts start with fully functional memory, courtesy…

vimeo.com

oreboot booting on an AMD Rome CRB

This is oreboot booting on an AMD Rome CRB. The logging is copious, so be patient. You might want to start about 40 seconds in and run it at 10x ... We start in oreboot, then load and boot Linux, ...

asciinema.org

We need some major push to get this into mainstream. Things are ALMOST there.

 

[DrMrLordX]

Wonder how, or if, that affected performance?

 

[AnitaPeterson]

OK, I'll bite. I'd like to know more about the possibilities to modify the BIOS on an existing motherboard.

Case in point: The Cleveland-GL8 motherboard made for HP by Pegatron.
Apparently also known as 2AB6 H67 - see https://www.game-debate.com/motherboard/index.php?mot_id=4096

This motherboard doesn't have a normal BIOS setup screen, but a barebones/customized HP welcome page. You can't change anything except the order of boot disks. You can't overclock and can't even use any GPU newer than the Geforce 7xx series on it (unlike 99.9% of other Sandy Bridge-era motherboards).

As someone who likes to repair and repurpose older computers, Dell used to top my shit list for incompatible hardware. But these idiotic restrictions imposed by HP take the cake.

So, would it be possible to change the BIOS to something more flexible and manageable?

 

[zir_blazer]

OK, I'll bite. I'd like to know more about the possibilities to modify the BIOS on an existing motherboard.

Case in point: The Cleveland-GL8 motherboard made for HP by Pegatron.
Apparently also known as 2AB6 H67 - see https://www.game-debate.com/motherboard/index.php?mot_id=4096

This motherboard doesn't have a normal BIOS setup screen, but a barebones/customized HP welcome page. You can't change anything except the order of boot disks. You can't overclock and can't even use any GPU newer than the Geforce 7xx series on it (unlike 99.9% of other Sandy Bridge-era motherboards).

As someone who likes to repair and repurpose older computers, Dell used to top my shit list for incompatible hardware. But these idiotic restrictions imposed by HP take the cake.

So, would it be possible to change the BIOS to something more flexible and manageable?

If the Firmware is trash, sure, you would get a lot more mileage if you get a Firmware that allows you to configure more things and even add Ivy Bridge support for Processor upgrade. For that specific generation, things like NVMe Boot and Intel VT-d/IOMMU (Which even if supported by Hardware, Firmware support sucked hard) are also on the table.
Do note that Hardware limitations due to how the Motherboard chips are wired may not be workaroundeable, say, if there is a chip like a Microcontroller or the VRM controller that have a bootstrapping Pin hardwired that forces it to a certain value, like the 25W PCIe Slot limitation. You are totally out of luck if that were the case. And even if it was Software configurable, you would need to make sure that the Motherboard can actually reliably provide 75W and not that the Hardware components are subspecced for that unless you want to see Hardware damage, same with supporting higher TDP Processors and overclocking (Which Coreboot is not aimed to due to the fact that you have to be really knowledge about the Motherboard to know what it can and can't do, and support is mostly done by reverse engineering propietary designs. They usually stick to AMD/Intel guidelines as the lowest common denominator). Not that you will ever know either thing without competent Hardware reverse engineering skills.

Yet, porting a Motherboard is not a weekend project, it may be a year long project or more for someone that has to start from scratch. If the Motherboard is bad from a Hardware point of view, I wouldn't even bother even if I had the skills to do such port. If it is actually Firmware handicapped then sure, it would make a major difference.


Here is a blog post about porting Coreboot to a Dell OptiPlex of around that generation, which you may find reelevant. Conveniently, one guy from that firm posted in this Thread, but for some reason the Post was deleted and the user was banned. I suppose that he either violated a self-promotion rule or was thought to be a bot.

 

[zir_blazer]

FOSDEM 2021 has started and there is a currently live presentation named "Open Source Firmware status on AMD platforms 2021", directly related to current Coreboot woes on AMD platforms.

Live stream: https://live.fosdem.org/watch/dfirmware

More info: https://fosdem.org/2021/schedule/event/firmware_osfsoap2/ (Here you will see video after the presentation, if you don't catch it live)
Full FOSDEM 2021 Firmware schedule: https://fosdem.org/2021/schedule/track/open_source_firmware_bmc_and_bootloader/

 

[zir_blazer]

Phoronix article on the FOSDEM 2021 presentation I linked: https://www.phoronix.com/scan.php?page=news_item&px=Open-Source-AMD-FW-2021

We're still missing the actual video. But seems that this is gaining a bit of momentum.

 

[Fanatical Meat]

Other than possibly extending the life of old hardware I don’t see a benefit.
@zir_blazer can you give me an elevator pitch as to what benefit your proposed changes would bring. Use as few words as possible.

 

[zir_blazer]

Other than possibly extending the life of old hardware I don’t see a benefit.
@zir_blazer can you give me an elevator pitch as to what benefit your proposed changes would bring. Use as few words as possible.

Check the link at the first Post of this Thread and read the list of "use cases" on the Index, is written for people like you. You have all what you want to know there. And I'm not man of few words, I like to go full verbose.


It is not about "old" Hardware, is that CURRENT Hardware will eventually be old too. Things getting old is just a matter of time. A current generation Motherboard will be old in just 2 or 3 years, even if you purchase a high end 300 U$D one. They can still be perfectly fine from a Hardware perspective like first generation AM4 Motherboards, but if the Motherboard vendor decides to drop support by not providing Firmware updates with bugfixes or new features cause a non-current Motherboard doesn't generates any profits, it will become obsolete far quicker.
If you haven't been bitten by Firmwares lack of features or bugs than the Motherboard vendor doesn't care to fix because they're not current generation and thus not generating any profits, then maybe you still don't see the value of this. But all those that already had to go into BIOS modding communities to do what the Motherboard vendor didn't, will obviously understand the benefits of getting full control over the Firmware.

 

[Fanatical Meat]

With a brief skim of what is written, I do not see a benefit other than maybe older hardware *may* get newer cpu support or memory updates.
I simply do not see this as a significant benefit. Those machines have already been built, those machines were sold with the listed feature set. I only see problems with security or down right crappy software that could screw up an old machine beyond repair.
I understand maybe there would be a hypothetical use to possibly enabling pcie 4.0 on let’s say a limited number of B450 boards but that isn’t a huge benefit and those buyers bought those boards without 4.0 support.
I simply do not see a huge benefit to this. Just sounds like a lot of hopes something better is made, that it is free or affordable, that it works and finally that it doesn’t cause some other problem down the road.