Being a Hardware enthusiast for around 16 years already, a thing that always bothered me is that no matter how good a Motherboard quality is from a Hardware point of view, the quality of the Firmware can still make such board great or completely wreck it. Common examples include those Firmwares that were missing critical options for specific use cases (Most notorious those related to Intel VT-d and AMD-Vi for IOMMU, I'm not talking about overclocking), broken ACPI Tables (Usually Linux specific, all them are "good enough" for mainstream Windows), lack of options that actually are in the Firmware but the vendor decided to hide them for no apparent reason, unique factory programmed data that can't be easily rebuild without a full backup, etc. Now, when I purchase a Motherboard I'm also purchasing the Firmware, but as everyone that is here already knows, sometimes the Firmware quality is mediocre, and the community has to jump in to fix what the vendors didn't.
Modding BIOSes has several drawbacks. Some of the Firmware vendors tools are not publicly available, they may not work if the Motherboard vendor did heavy modifications (In another forum, The Stilt recently mentioned that he can't mod some AsRock and Biostar Firmwares because standard tools doesn't work with them), and while the BIOS modding community usually gets its way around, the effort involved seems to be rather high since you are dealing with deciphering propietary code and figuring out what consistenly works and what doesn't. Giving these drawbacks, has anyone considering whenever going the open source Firmware route like Coreboot would fix all those shortcomings by giving the community more tools to cleanly fix bugs or add new features? While I know that it is not easy to do a Coreboot port, and that you still need binary blobs provided by the Hardware vendors like Intel and AMD to do basic platform initialization, it seems to me that everything else could become far easier, as you would have a lot of freedom for experimentation, add features, tracking regressions, etc, instead of the black box approach that we have right now where the Motherboard manufacturer decides for you what the Firmware contains.

Any thoughts about this matter? For years I have been expecting Coreboot to become closer to mainstream, but it is now farther away. Would love to know if there is consumer demand.

No opinions? :(

From the first visit in win-raid forums I have wondered why nobody is not talking about coreboot. More like nobody knows that even exists.

At the HP 8200 thread I have confirmed that coreboot can release newer generation CPU support and with newer CPU increase PCIe 2.0 to 3.0.

Coreboot developement is very slow and fighting with basic fuctionalies. So that is not the case with OC options and RAID tools.

Zitat von raun0 im Beitrag #3

---

From the first visit in win-raid forums I have wondered why nobody is not talking about coreboot. More like nobody knows that even exists.

At the HP 8200 thread I have confirmed that coreboot can release newer generation CPU support and with newer CPU increase PCIe 2.0 to 3.0.

Coreboot developement is very slow and fighting with basic fuctionalies. So that is not the case with OC options and RAID tools.

---

Moving thread per user request (Sorry @ zir_blazer - I can't comment on your question, I've never used Coreboot)

I think RISC-V is taking over before there will be the full librem of the x86 bioses and motherboards.

But what would be most popular implementation of RISC-V booting that is the quostion. Also big companies and server host like Google, Facebook and Amazon is heading to RISC-V because that way they can make open custom cpu for the spesific load. That way they can save huge ammount of electricity and space.

Google has tried long get rid of propiertary low level firmwares, like modern bios has. Google is great contributor of the coreboot and using that on their chromebooks.

Zitat von Lost_N_BIOS im Beitrag #5

---

(Sorry @ zir_blazer - I can't comment on your question, I've never used Coreboot)

---

Zitat

---

Disable ME HECI
Matt has patches in gerrit now that implement a few HECI commands, one of which is to disable ME HECI
ME no longer respects HAP bit on platforms >= version 12 (of ME)

---

Coreboot + SeaBIOS would even be an extremely viable alternative for people that STILLS want to run Windows XP on bare metal, which I know that are present in this forum. Instead of having to mod things like ACPI support Windows side, they can do so it SeaBIOS side, so they provide an out-of-the-box compatible ACPI interface.
TianoCore supports creating a RAMDisk before OS boot. It could be extremely useful for stateless systems, albeit LiveCDs usually already take care of that. I think that it may be possible for such RAMDisk to survive a warm reboot with specialized Firmware that doesn't zeroes the RAM during POST if it has a magic bit set, like the 1984 IBM PC/AT did for the 286 CPU warm reset to return from Protected Mode to Real Mode.

Zitat von raun0 im Beitrag #6

---

I think RISC-V is taking over before there will be the full librem of the x86 bioses and motherboards.

But what would be most popular implementation of RISC-V booting that is the quostion. Also big companies and server host like Google, Facebook and Amazon is heading to RISC-V because that way they can make open custom cpu for the spesific load. That way they can save huge ammount of electricity and space.

Google has tried long get rid of propiertary low level firmwares, like modern bios has. Google is great contributor of the coreboot and using that on their chromebooks.

---

https://www.phoronix.com/scan.php?page=n...aptops-Coreboot

I'm going to give a try to influence Hardware enthusiast communities about the need to push for open source Firmwares. These are my personal thoughts and nearly all the input I have on this matter: https://zirblazer.github.io/htmlfiles/coreboot.html?ver=123

@Lost_N_BIOS

Being an accoplished BIOS modder, I value your input regarding the matter. Check the previous link, and tell me whenever you consider that you will have far more tools at your disposal with an open source Firmware, vs having to fix propietary Firmware and the shortcomings of IBVs/Motherboard manufacturers. Giving the fact that these days it is possible to kickstar open source Hardware projects and several big vendors are already using Coreboot, I see that a consumer push is very possible.

Hello @zir_blazer, I read your previous posts and it look interesting to me. I will be check your link soon, because it seems to be very informative and well organized.
if I understand it correctly - you can manage your firmware with coreboot more
Can I ask you, do You think with coreboot enabled I would gain control lets say over the MSRs written by OEM in Bios?
Example - if register is saying me I cant change multiplier (in scenario where cpu has hidden turbo bins), I would say that this register was wrote by factory it self and further, because its R/O than nothing to do here probably.
And now according my hypothesis, if I could debugg registers somehow and read them after reset and If they are set up well, you can see the BIOS is on the blame and then you can try coreboot?
Sorry for my english man, it is not my native language.
Thanks

Zitat von DaCou im Beitrag #11

---

Can I ask you, do You think with coreboot enabled I would gain control lets say over the MSRs written by OEM in Bios?
Example - if register is saying me I cant change multiplier (in scenario where cpu has hidden turbo bins), I would say that this register was wrote by factory it self and further, because its R/O than nothing to do here probably.
And now according my hypothesis, if I could debugg registers somehow and read them after reset and If they are set up well, you can see the BIOS is on the blame and then you can try coreboot?

---

thank you very much for showing me the problem more closely. I trully have not clue how to port Coreboot on platform yet, it look very complicated for standard windows user as me. Luckily I found one engineer from Coreboot develope team is living in my small country, so I will contact him soon probably. The thing is, if I would bye board than build PC and make overclocking by one click in bios, it doesnt look very exciting to me. Or perhaps if you know someone who know how to wrewrite R/O register in assembler, I would appreciate you help :-)

Hi zir_blazer, maybe I mentioned Coreboot here some years ago but generally see no interest of O'C comunity. It's just because 2 different attitudes and goals you have already described in post #4. I think that original idea of Coreboot was to build very simple (and fast) open firmware with limited capabilities that just load linux kernel as a payload which takes care of initializing the rest of HW. Later there was more payloads added like Seabios allowing to run also DOS/Windows OS on CB-based boards. AFAIK there's still no SETUP in CB and you configure it at build time or may store/load some params to CMOS via some tool...

The big obstacle of spreading and porting CB is that you need to have very detailed info about HW you want to run in. And commercial MBs are not openhardware, sometimes there leaks some schematic of some older boards but generally rare. It takes so big effort to reverse engineer all details by a small community. Much better would be start with some open HW boards. Also the CB community was strongly supported by some AMD engineers in the past but seems it decay starting with Ryzen era. AMD also changed their policy of providing HW documentation, I cannot find almost nothing thech. docs about Ryzens and their chipsers freely available. Intel still have a CPU and chipset datasheets free (of course some details still only under NDA and some hidden for anyone).

Some years ago I played with a tiny x86 board called 86Duino with Vortex86 CPU that is open HW and it runs Coreboot. I just did rebuilt it and some minor patching not going so deep yet. I think it's a good way to learn about HW and Coreboot, much better than starting with unknown obscured HW. One disadvantage is that basic 86Duino board has not VGA but I was able to reconfigure PCIE x1 from peripheral to host and via simple adapter could run a standard PCIE VGA then :)

I just have a look at System76 - I didn't know about them (I know Purism Librem), seems they have Coreboot laptops. It may be also good starting point. They are talking about some open HW at Github but I didn't find anything interesting there (mean MB schematics and PCB lyout).

About MSRs and Coreboot. CB still uses intel's binary blob that is out of CB's control and that can do anything with MSRs and other HW. So it also can lock down some MSRs so CB may not be enough to overcome this issue...

Going to bump this Thread because there are some interesing news to share.




Almost two weeks ago FOSDEM 2021 hosted a virtual conference room for Firmware-related talks. The one that I was most interesed in was "Open Source Firmware status on AMD platforms 2021", covering the topics mentioned here. There are PDF slides and video available. Phoronix also did an article about the subject.


Talk highlights:
- AMD AGESA v9 can be currently directly integrated with TianoCore (edk2) to produce a mostly open source UEFI implementation, albeit the AGESA part remains closed sourced. Implementing it this way is unrelated to Coreboot.
- AMD hired a few Coreboot engineers that are implementing support for Cezanne and Majolica (I don't know what this one is, maybe a Dali successor?) upstream. Probably for Chromebooks.
- He mentioned the previous talk from Coreboot founder Ronald Minnich (Now currently at Google) about pure open source support of EPYC Rome in oreboot (The talk "pure open source on an AMD Zen" from this video). The problem is that while he managed to boot a Rome with no binary blobs, it only has pretty much CPU, RAM, and low speed interfaces like Serial Port for console. The PCIe Root Complex and anything that depends on it aren't available yet, so it is far from production ready because a lot of major features still aren't supported, albeit it is still amazing that it can boot Linux on its current state.
- AMD also did some work on OpenBMC to support their reference EPYC platform. In a previous conference there was a talk by an AMD engineer about this.
- 3mdeb worked on an AGESA v9 + TianoCore port for the DFI GH960 (Ryzen Embedded V1000) in a DFI COM332-B COM Express Type 6 Carrierboard, which they plan to upstream on a few months and may be the first non-Chromebook Zen platform to get an open source Firmware (Albeit it is not Coreboot).
- They also mentioned their side project Dasharo (There is a Twitter where they mentioned my guide, heh), that is as of yet a bit hard to describe, but I interpret it as if they want to provide IBV (Independent BIOS Vendor)-level Firmware services based on Coreboot for continuous mainteinance and build testing of Motherboards using it.


I believe that the more BIOS modding matures, the more the likelyhood to consider hoping to an open source Firmware built from scratch instead of doing mainteinance of propietary ones.