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.
The thing is that the BIOS modding communities and Coreboot ones targets completely different types of people. BIOS modders are historically associated with Hardware enthusiasts, since most people that wanted to mod their BIOSes did so to unlock overclocking options (Who else flashed often their BIOSes 10-15 years ago?), whereas the Coreboot folks come from the open source Software side of things and is composed of people that carries a lot of ethical baggage that may or may not be interesed in bringing a functional improvement over propietary Firmware.
Because the workflow of BIOS modders and Coreboot developers is completely different, they don’t have to know about each other, either. One has to deal mostly with tools provided by the IBVs (Independent BIOS Vendor) in a hackish style to get what they want, using as base something that already exists, whereas the other is a programmer that can do far more since it can potentially implement things from scratch, at the cost of having to read ton of chips Data Sheets to learn how to do low level Hardware interfacing. Yet when you think about it, Coreboot is far more powerful than BIOS modding will ever be since even with the mandatory vendor provided binary blobs required for platform initialization, you get control of everything else, making it the obvious next step for Firmware customization. I find it rather dissapointing that I don’t see BIOS modders even thinking about the idea of whenever an open source Firmware framework would give them more freedom to do the stuff they want, like adding features, managing different Option ROM versions, payloads like TianoCore for UEFI and SeaBIOS for BIOS, all while being far less frustrating that modifying propietary black boxes. There are a multitude of things which should be easy to fix with better Firmware control.
Intel provides the binary blobs (The FSP) required to get their platform initialized even for the recently launched Ice Lake, so technically you can get Coreboot working on any modern Intel platform. However, it is extremely rare to see working Coreboot ports for modern retail, consumer Motherboards. The most recent one seems to be the LGA 1151 Supermicro X11SSH-TF for Kaby Lake.
Porting Coreboot is a challenge itself, because it requires tons of reverse engineering of the propietary Firmware to know how a specific Motherboard implemented things like the wiring of the Super I/O GPIO pins. After years lurking, it seems that most Coreboot ports never get to implement the full feature set available in a Motherboard default propietary Firmware, they are always missing some feature. At least those features are usually obscure, as baseline functionality seems to be under control.
Currently I think whenever it is viable to make a Motherboard entirely from scratch so that by having control of the design, you can more easily implement Coreboot. Given the fact that small sized business like Raptor Engineering could manage to pull out the Talos 2, and there is also the UDOO Bolt, and even some chinese guys that made a Kaby Lake Motherboard as a drop-in-replacement for Thinkpads X210, I think that making a modern Motherboard to implement Coreboot out-of-the-box is within the realm of the possible.
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.
I never used it either, but I spended a lot of time reading about it, so I have an idea about what it can do, what it can’t do, and where those things that it can do could be useful. Likewise with BIOS modding, so many years yet ended up doing nothing. Actually, the closest time that I was to flash a modded BIOS was when you were helping me with my X10SAT due to a missing graphics menu that was critical for me, but Supermicro beat you to it 
I think that the only modded Firmware I ever utilized was lordkag automatic tool to add an UEFI GOP to a Radeon 5770 Option ROM.
If you want to poke about Coreboot possibilities, check these links:
https://hackaday.com/2019/04/10/windows-…than-you-think/ (FreeDOS would have been far more useful)
https://www.coreboot.org/AVATT (This was a 2008 or so project, too many dead links, but you get the idea. It was a project for a Linux with builtin Hypervisor embedded in a 2 MiB Flash ROM)
https://docs.google.com/document/d/1NRXq…kKrgKjeDQ/edit# (Coreboot leadership meetings notes)
Reading the leadership notes I even learned this, which could be useful for people here that likes to makes mod that neuters the Intel 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.
There is a problem: Windows and all its preexisting Software ecosystem doesn’t work in RISC-V, at least not without emulation. It is a viable alternative for Linux users that can get away by recompiling source code or with some minor porting (Basically, the sort of people that would currently be using a POWER based Talos 2). There is no guarantees that it will scale down to a format viable for end users.
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
In theory, yes. I think that there are some registers that can be set to read-only after their initial configuration, thus only the Firmware has full control over them, blocking any later OS-side changes. Since with Coreboot you will have access to most of the Firmware code (Except the binary blobs provided by Intel for platform initialization), if there are MSRs that an OEM currently uses to control locking the CPU Multiplier, you can skip setting them. The thing is whenever the MSRs that you want are publicly documented or not.
Whenever it is useful for you or not, depends. It is a behemoth task to just THINK about porting Coreboot to a platform just for 400 MHz more on an Ivy Bridge.
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.
Any details about TianoCore supports creating a RAMDisk before OS boot.? Thx
@zir_blazer I think in light of recent achievements related to open-source firmware for MSI Z690-A DDR4 this thread could be revived. It looks there are clear evidence that Dasharo compatible with MSI Z690-A DDR4 enables new possibilities and show how open-sourc firmware can contribute to BIOS/UEFI modding community.
@Kocoman would you mind to be little more precise? It sounds like you talking about placing RAMdisk in firmware so something like Heads or LinuxBoot?