There's huge potential for this 'unbrickable' open source BIOS now it's running on modern Intel PCs

kac77

2[H]4U
Joined
Dec 13, 2008
Messages
3,314
Last edited:
I'm still waiting. I'm not holding my breath, either. About the only way Intel/AMD can help is by providing help with setting up the CPU itself, and maybe communicating with the on board chipset. Aside from that, it's entirely the MB manufacturer's wheelhouse, and they seem pretty dead set on sticking with AMI/Award/etc, regardless if it's BIOS, efi, or something else.

They may be better off trying to convince them instead, but I'm pretty sure they want their firmware as closed as they can get it.
 
Unbrickable huh? Give it to my niece. It will be bricked in an hour.
Yeah, that term was definitely too exagerrated. It was picked by Xeno Kovah on Twitter. I tried to explain that, but to be honest even if we try we cannot untangle all misconceptions in articles related to coreboot port for Alder Lake. Next time we simply will try to deliver higher quality materials to journalists.
 
I'm still waiting. I'm not holding my breath, either. About the only way Intel/AMD can help is by providing help with setting up the CPU itself, and maybe communicating with the on board chipset. Aside from that, it's entirely the MB manufacturer's wheelhouse, and they seem pretty dead set on sticking with AMI/Award/etc, regardless if it's BIOS, efi, or something else.

They may be better off trying to convince them instead, but I'm pretty sure they want their firmware as closed as they can get it.
Agree. We tried to reach MSI, but they said they doing BIOS themselve and they are not intrested in other products. Of course it is not full story nobody doing BIOS without help of silicon vendor and in most cases independent bios vendors.
 
Yeah, that term was definitely too exagerrated. It was picked by Xeno Kovah on Twitter. I tried to explain that, but to be honest even if we try we cannot untangle all misconceptions in articles related to coreboot port for Alder Lake. Next time we simply will try to deliver higher quality materials to journalists.

Could you elaborate on what coreboot actually does offer that's better than the competition here?

My skepticism is mostly centered around a bad flash that corrupts the part of the firmware needed to minimally boot the system enough to run the re-flash tool is going to be game over not just for the mass market but for 99% of enthusiasts who lack the tools and ability to use an external flashing device.
 
Unbrickable huh? Give it to my niece. It will be bricked in an hour.
The technology to blind flash a bricked BIOS has been around since 1993. You only brick your BIOS on boards that are cheap and offer no redundancy for reflashing or in the way of dual ROMs. The latter is almost unheard of now while the former has gotten so good that ASRock once dared us to pull the power during a flash on a single BIOS ROM motherboard. (Which I did, and it resumed the flash once it had power again.)
 
Could you elaborate on what coreboot actually does offer that's better than the competition here?

My skepticism is mostly centered around a bad flash that corrupts the part of the firmware needed to minimally boot the system enough to run the re-flash tool is going to be game over not just for the mass market but for 99% of enthusiasts who lack the tools and ability to use an external flashing device.
It is open source, so you can view and modify the source to your liking. It allows you to make your own modules, which have direct access to the hardware (similar to efi), for two. In the case of boards where the original firmware was closed, it may allow access to sensors and devices which were disabled or not exposed by the OE firmware.
 
It is open source, so you can view and modify the source to your liking. It allows you to make your own modules, which have direct access to the hardware (similar to efi), for two. In the case of boards where the original firmware was closed, it may allow access to sensors and devices which were disabled or not exposed by the OE firmware.

Way to lose track of the chain of replies and the relevant contest. My question was in regards to the claim, as apparently mangled via the press, of being unbrickable.
 
Way to lose track of the chain of replies and the relevant contest. My question was in regards to the claim, as apparently mangled via the press, of being unbrickable.
Ah, sorry. Unfortunately I'm not familiar enough with it to answer that, or what the OEMs do to prevent bricking for that matter. It'd be hard to beat flash from USB that some allow, for instance, without even a CPU installed. Would be nice if they all had a similar feature.
 
Could you elaborate on what coreboot actually does offer that's better than the competition here?

My skepticism is mostly centered around a bad flash that corrupts the part of the firmware needed to minimally boot the system enough to run the re-flash tool is going to be game over not just for the mass market but for 99% of enthusiasts who lack the tools and ability to use an external flashing device.
I registered just to say that I wrote THIS for people like you, that wants to know how Coreboot can be useful for Hardware enthusiasts and other type of power users.

If your Firmware ever missed a critical option for your use case and you had to do BIOS modding because the Motherboard vendor ignored you (Some options that are already in Firmware image but flagged as hidden, and can be easily unhidden with certain tools from the BIOS vendors) or that are impossible to implement without source code access (Anyone tried to do PCI Passthrough for virtualized gaming back when Intel VT-d / AMD-Vi / IOMMU was supported by Hardware but no one implemented it in Firmware?), you should think like me that getting a viable open source alternative is extremely important. This is wrestling control of a critical piece of functionality so that a community could potentially take over mainteinance of the code and even adding new features when the Motherboard vendor doesn't care about it any more. I got into pushing Coreboot precisely, because I was let down a few times too many, and I was always surprised/dissapointed that there is not a lot of people in this market segment who thinks like me.


The whole "unbrickeable" thing from the PCgamer article must probably come from Coreboot own description, where they use that word. I recall having hear about certain platforms that claims thing like that, but they have some form of redundancy on Hardware (Two Flash EEPROM chips and some Embedded Controller with a watchdog that can reflash the image on the main EEPROM from the secondary backup if it detects that the system doesn't POST or such). In this case don't expect to count with that, albeit it may be possible to tame the Super IO to make the Flashback Button work for our purposes as to make recovery as easy as possible.


PD: I'm involved in this project.
 
Last edited:
Express slot bifurcation comes to mind as it's been hardware supported for nearly a decade yet only exposed on the enterprise priced boards and a few random consumer boards along the way.
 
My niece has destroyed every electronic we have given her without physically breaking it. IDK, some sort of idiot savant of f***ing s*** up.

so she''ll be neo when the machines take over

#humblebrag
 
I registered just to say that I wrote THIS for people like you, that wants to know how Coreboot can be useful for Hardware enthusiasts and other type of power users.
Welcome to [H]ardForum. You weren't responding to me, but that's an excellent write-up that offers plenty of reasons for everyone to give more consideration to firmware when choosing a motherboard, whether or not they have an interest in the Coreboot project.
If your Firmware ever missed a critical option for your use case and you had to do BIOS modding because the Motherboard vendor ignored you (Some options that are already in Firmware image but flagged as hidden, and can be easily unhidden with certain tools from the BIOS vendors) or that are impossible to implement without source code access (Anyone tried to do PCI Passthrough for virtualized gaming back when Intel VT-d / AMD-Vi / IOMMU was supported by Hardware but no one implemented it in Firmware?),
Your article gave an accurate account of the mess surrounding Intel VT-d on Sandy Bridge, and matched my experience exactly. Despite having gone out of my way to buy an inferior chip — a regular (non-k) i7-2600 — just for VT-d, motherboard firmware was left frozen in its beta state, where support meant little more than a feature toggle in the UI. The ACPI DMA remapping (DMAR) was broken IIRC, and I had wasted enough time futzing around with ACPI tables on earlier hardware to work around other issues to bother. <grumble>

Intel's upcoming ARC discrete graphics cards look like they may be the best option for GPU virtualization on "consumer" hardware under Linux provided they support SR-IOV, and I believe they will. I'm rather fond of the idea of pairing one with a next-generation Ryzen/AM5 (Zen 4) system.
you should think like me that getting a viable open source alternative is extremely important. This is wrestling control of a critical piece of functionality so that a community could potentially take over mainteinance of the code and even adding new features when the Motherboard vendor doesn't care about it any more. I got into pushing Coreboot precisely, because I was let down a few times too many, and I was always surprised/dissapointed that there is not a lot of people in this market segment who thinks like me.
I also find it disappointing. I wish I could also say that I'm surprised.

Unfortunately, this seems to be the direction were headed: Go Meta with ASRock's NFT Collection
The whole "unbrickeable" thing from the PCgamer article must probably come from Coreboot own description, where they use that word.
The "unbrickable" focus is unfortunate. It was probably chosen to generate more clicks. Based on the title, I actually thought the mystery open source OS was going to be Minix, which runs Intel's Management Engine. ;) Though of course the derivative in the ME is anything but open source. 🧱

Do you have a link to an accurate source describing what we were supposed to read? This doesn't sound like another Purism or System76 (nothing against them).
 
Express slot bifurcation comes to mind as it's been hardware supported for nearly a decade yet only exposed on the enterprise priced boards and a few random consumer boards along the way.
Alder Lake main 16x PCIe Port can be bifurcated to 8x/8x only (Not counting the new 4 extra lanes). Previous generations could do 8x/4x/4x, so this is a step backwards.
I'm expecting than in-slot bifurcation support will be picked at some point, making 8x/8x risers usable. I'm aware than there is an user in this forum, C_Payne, that does handcrafted risers, which I would expect to work.


Unbrickable eh? Challenge accepted! :jimlad:
Good. I always love to see more guinea pigs. I mean, non-paid QA labour. I mean, testers. I mean... users :D


Your article gave an accurate account of the mess surrounding Intel VT-d on Sandy Bridge, and matched my experience exactly. Despite having gone out of my way to buy an inferior chip — a regular (non-k) i7-2600 — just for VT-d, motherboard firmware was left frozen in its beta state, where support meant little more than a feature toggle in the UI. The ACPI DMA remapping (DMAR) was broken IIRC, and I had wasted enough time futzing around with ACPI tables on earlier hardware to work around other issues to bother. <grumble>
This was literally THE reason that got me interesed in Coreboot on the first place. Back in 2013, after Haswell launched, I wanted to make a build specifically to use Xen with PCI Passthrough to make a gaming VM before such a thing became popular (And I suppose than that also makes you one of the earliest adopters). I knew about VT-d hit-or-miss support and that it was impossible to know if the ACPI Tables were good or not without ACTUALLY testing it on the field, so the idea of spending money for a Motherboard that I didn't knew that was going to work or not was scary (I ended up getting a Supermicro, which did the job). This eventually made me get into arguments with an ASUS representative on XtremeSystems Forums about other vendors getting PCI Passthrough to work whereas it seemed to be consistently broken on ASUS Motherboards. The reply was pretty much "Intel says that Z87 Chipset doesn't support VT-d, so we don't either", contrary to the results of other vendors. At that point I figured out that spending 200-300 U$D on a Motherboard with absolutely no guarantees about BIOS support is rather pointless, and that is when I found attractive the idea of open source making viable long term mainteinance by community, like they do for so many other things.


Intel's upcoming ARC discrete graphics cards look like they may be the best option for GPU virtualization on "consumer" hardware under Linux provided they support SR-IOV, and I believe they will. I'm rather fond of the idea of pairing one with a next-generation Ryzen/AM5 (Zen 4) system.
Don't count on it. Intel promised than the Xe IGPs were going to support SR-IOV and they actually do in Hardware, but the problem is that you have no Driver to actually use it at all. Meanwhile, Intel discontinued GVT-g, which only supports older generations (I think 9th or 10th tops?), so you currently have no working replacement.
Your best bet is checking which consumer GeForces/Radeons can be modded/hacked to support vGPU via whatever means they use. I'm aware than some users were successful and the hacks are decently documented last time I checked, but I don't remember them out of memory.

Oh, Alder Lake is the first Intel consumer generation than supports PCIe ACS on the Processor PCIe Root Ports and APICv. You may find that info interesing.


The "unbrickable" focus is unfortunate. It was probably chosen to generate more clicks. Based on the title, I actually thought the mystery open source OS was going to be Minix, which runs Intel's Management Engine. ;) Though of course the derivative in the ME is anything but open source. 🧱

Do you have a link to an accurate source describing what we were supposed to read? This doesn't sound like another Purism or System76 (nothing against them).
Not really. We were expecting Linux focused news sites like Phoronix to pick the announcement, and readers of those most likely already know what Coreboot is, so it was pretty much a "we are working on this and Linux is already booting" announcement (And now Windows 11, too). We were surprised than non-Linux news outlets picked it, so there was no explanation for mere mortals ready for them.

Both System76, Purism and 3mdeb are doing roughly the same, which is making Coreboot ports, but the goals are completely different. The first two sell Notebooks and make Coreboot ports as value add to what they sell. 3mdeb is instead trying to provide a Coreboot port for third party Hardware that already has a working and rather fully featured propietary Firmware, so the port has to shine completely on its own as to differentiate from it. And it is actually a far harder task.
If anything, the main difference is the target user. If you have read other texts/articles about Coreboot, their proponents aims at users that cares about things like privacy and security, which is where just being open source and auditable is the selling point. Those are most likely main Linux users, if not only Linux. My take, which you read, was completely different since I'm a disgruntled DIY builder that got fed up about horrendous consumer support from Motherboard vendors, with Coreboot being potentially able to provide more features, less bugs and better support even for your average Hardware enthusiast and Windows gamer. So basically, my target was people like you.

Heck, it is possible than even raw performance becomes a selling point. Benchmarking was never a focus of Coreboot developers (The focus is pretty much just to reimplement as much as you can as open source), but recently another Notebook vendor, Starlabs, is providing a Notebook with both AMI and Coreboot versions, and they claim that the latter is around 8% faster.
 
Recently a Linux consulting company loaded an open source BIOS called Coreboot. It is done to get greater control over fundamental PC software. How wide its benefits are yet to be seen in future.
 
Hi all, I'm Piotr Król CEO of 3mdeb. Feel free to AMA.
Sounds interesting.

Does each bios still need tailored to the mobo it will be used on?

Would the custom bios still support all varied embedded components like nics, sound cards, storage?

What is meant by 'unbrickable' ? Most systems are dual bios as well as offer bios flash recovery.

What is the benefit of this bios over the stock bios? Is it simply security? Are there performance benefits?
 
Sounds interesting.

Does each bios still need tailored to the mobo it will be used on?

It really depends on how big difference is between PCB designs of given mobo. PCB design typically rely on some silicon vendor reference design (for Intel it would be Customer Reference Board or Reference Validation Platform) on which reference firmware (aka BIOS/UEFI) is tested.
Then OEM modifies that design and IBV potentially customize reference code (typically shipped as Intel Firmware Support Package) and add their features to the rest of firmware. If we consider set of mainboards made by given OEM which base on the same reference design, then it is up to IBV to design firmware, which can boot on those various boards. Of course creating more universal firmware means more complexity in code and potentially more bugs. I assume that major IBVs have enough resources to create firmware widely compatible with multiple designs, but that firmware quickly become bloated and slow because it has to handle all that variety of hardware.

Would the custom bios still support all varied embedded components like nics, sound cards, storage?

I'm not sure what you mean here as "custom bios". What we're doing is open-source firmware called Dasharo, which tries to replace typically IBV-made UEFI. Dasharo in most cases is based on coreboot (open-source firmware framework) and EDKII (open-source UEFI specification implementation. EDKII does not support controllers since UEFI design rely on buses, so PCI/PCIe/USB/LPC/SPI etc. are supported. Support for specific controller from specific chipset is not the goal of UEFI, ergo it is not the goal of its implementation EDKII. coreboot on the other hand support multiple devices, but also to the limit of what was contributed to the code.

What is good about open-source firmware is that it is extensible by anyone, and there is professional ecosystem around it.

What is meant by 'unbrickable' ? Most systems are dual bios as well as offer bios flash recovery.

It was already explained here
What is the benefit of this bios over the stock bios? Is it simply security? Are there performance benefits?
zir_blazer approached that question from various angles, did you manage to read his explanation? Other values that open-source firmware can provide is explained on coreboot website. Value depends on who you are in the ecosystem, but here is explanation for end users, hardware vendors and developers.

We would also be glad to discuss those topics further. We're already working on our 5th edition of Dasharo open-source firmware vPub, which means talking about UEFI/BIOS/coreboot/EDKII and many other things in casual atmosphere 🍻
 
It really depends on how big difference is between PCB designs of given mobo. PCB design typically rely on some silicon vendor reference design (for Intel it would be Customer Reference Board or Reference Validation Platform) on which reference firmware (aka BIOS/UEFI) is tested.
Then OEM modifies that design and IBV potentially customize reference code (typically shipped as Intel Firmware Support Package) and add their features to the rest of firmware. If we consider set of mainboards made by given OEM which base on the same reference design, then it is up to IBV to design firmware, which can boot on those various boards. Of course creating more universal firmware means more complexity in code and potentially more bugs. I assume that major IBVs have enough resources to create firmware widely compatible with multiple designs, but that firmware quickly become bloated and slow because it has to handle all that variety of hardware.



I'm not sure what you mean here as "custom bios". What we're doing is open-source firmware called Dasharo, which tries to replace typically IBV-made UEFI. Dasharo in most cases is based on coreboot (open-source firmware framework) and EDKII (open-source UEFI specification implementation. EDKII does not support controllers since UEFI design rely on buses, so PCI/PCIe/USB/LPC/SPI etc. are supported. Support for specific controller from specific chipset is not the goal of UEFI, ergo it is not the goal of its implementation EDKII. coreboot on the other hand support multiple devices, but also to the limit of what was contributed to the code.

What is good about open-source firmware is that it is extensible by anyone, and there is professional ecosystem around it.



It was already explained here

zir_blazer approached that question from various angles, did you manage to read his explanation? Other values that open-source firmware can provide is explained on coreboot website. Value depends on who you are in the ecosystem, but here is explanation for end users, hardware vendors and developers.

We would also be glad to discuss those topics further. We're already working on our 5th edition of Dasharo open-source firmware vPub, which means talking about UEFI/BIOS/coreboot/EDKII and many other things in casual atmosphere 🍻
When you're done with coreboot can you do the same thing to make alternatives to qualcomm blobs for androids?
 
It really depends on how big difference is between PCB designs of given mobo. PCB design typically rely on some silicon vendor reference design (for Intel it would be Customer Reference Board or Reference Validation Platform) on which reference firmware (aka BIOS/UEFI) is tested.
Then OEM modifies that design and IBV potentially customize reference code (typically shipped as Intel Firmware Support Package) and add their features to the rest of firmware. If we consider set of mainboards made by given OEM which base on the same reference design, then it is up to IBV to design firmware, which can boot on those various boards. Of course creating more universal firmware means more complexity in code and potentially more bugs. I assume that major IBVs have enough resources to create firmware widely compatible with multiple designs, but that firmware quickly become bloated and slow because it has to handle all that variety of hardware.



I'm not sure what you mean here as "custom bios". What we're doing is open-source firmware called Dasharo, which tries to replace typically IBV-made UEFI. Dasharo in most cases is based on coreboot (open-source firmware framework) and EDKII (open-source UEFI specification implementation. EDKII does not support controllers since UEFI design rely on buses, so PCI/PCIe/USB/LPC/SPI etc. are supported. Support for specific controller from specific chipset is not the goal of UEFI, ergo it is not the goal of its implementation EDKII. coreboot on the other hand support multiple devices, but also to the limit of what was contributed to the code.

What is good about open-source firmware is that it is extensible by anyone, and there is professional ecosystem around it.



It was already explained here

zir_blazer approached that question from various angles, did you manage to read his explanation? Other values that open-source firmware can provide is explained on coreboot website. Value depends on who you are in the ecosystem, but here is explanation for end users, hardware vendors and developers.

We would also be glad to discuss those topics further. We're already working on our 5th edition of Dasharo open-source firmware vPub, which means talking about UEFI/BIOS/coreboot/EDKII and many other things in casual atmosphere 🍻
Thanks!

I'm excited to see where this goes. I hope you are successful in getting more traction with this.

For costs to develop this for a particular platform, I take it end users will not be a direct market for this? We will have to rely on our mobo vendor to make this an option? What do you foresee as pathways for this to get to end users?
 
Wasn't there someone that asked...

But these performance claims need some data. 8% faster at what? Versus a UEFI implementation which didn't set clocks correctly - or what are we talking about here?

It was on a post after my second one and before Agraffe, I even saved a link to the post because I intended to reply at it later. Seems like whoever it was deleted that post. Oh well...


There was some internal chat about that claim, since it doesn't specify whenever it is 8% faster boot time or 8% faster overall performance as in benchmarks. We can't answer that one because we're not the ones that made the claim. However, faster overall performance is theorically possible (Read this paper), assuming same clock speeds, memory timmings and everything.
The Firmware provides SMI (System Management Interrupt) Handlers to use functions or features that runs in SMM (System Management Mode), also known for its informal name Ring -2. A SMI can transparently interrupt whatever the Processor is doing to enter SMM to do something without a running OS even being aware of it. The OS has absolutely no idea of what is going on in SMM mode since it is executed in a completely transparent way, so is like if clock cycles spend there are lost or simply unaccounted for, besides than the context switches of entering and exiting SMM are rather expensive. So, if you have unoptimized code that relies on SMM, your performance would be of course lower than if you didn't had that burden. There are certain things that can rely on SMM, like ACPI functions that calls a SMI Handler. The only specific feature that I'm aware that uses SMM consistently is emulating a PS/2 Keyboard and Mouse, which is what many may have used to install Windows 7 on platforms with only XHCI USB Controllers (In Intel consumer platforms, anything Skylake+).

The problem is, the Coreboot developer community has pretty much never bothered with benchmarking (If they ever did at all, cause I don't recall even a single Coreboot vs stock propietary performance comparison as what you expect from a Hardware review site. Only boot times were compared, and these tend to predate UEFI Fast Boot) because there is a lack of both knowledge and resources (Manpower, and money to pay for it) to actually do that, so they spend their time making things work instead of comparing them. We have no idea of how good/bad a typical propietary Firmware SMI Handlers are to know what to expect until we're ready to compare. Coreboot has rather low reliance on those, so is possible than if there is something really broken on propietary, we perform better. Keep in mind that anything mobile (Like Star labs claim) would have far more SMM work going on than a desktop due to heavier reliance on power management, so it may be possible than the difference could be far lower here.
For reference, I was personally expecting to trail a few percent points in performance because the target was a by-the-book implementation which means that we would not be cheating on clocks. There are other things that may be forced like memory training/timmings. If SMM is abused by propietary Firmware, it may actually be possible than we are slighty on top instead.
 
It was on a post after my second one and before Agraffe, I even saved a link to the post because I intended to reply at it later. Seems like whoever it was deleted that post. Oh well...
Sorry, that was me, and I felt my question derailed a bit - because as you say - it wasn't your claim, directly. I deleted it to keep it on the "open source" angle, with which I deeply resonate.

I actually agree with what you said, which again, is why I deleted it. Benchmarks aren't the primary goal.
But ... a number was provided.

We're nerds here. If someone cites a performance improvement, we want to know what exactly, and in what conditions, versus what. I understand some improvements are theoretically possible. I want to see what end-user workloads changed, or else, let's skip the performance discussion and focus on the benefits of open source.
 
Phoronix is going to get a Motherboard to test the 0.3 release next week.

The binary is public (So did the 0.1 and 0.2, but these didn't received attention) and pretty much anyone could suicide test it right now if someone desires to do so, but there are still many things that can go wrong so is ABSOLUTELY NOT READY for public consumption, unless you can recover from a brick (See below).

1 - While it has been well tested that you can go from stock propietary Firmware to coreboot-based Dasharo using Software means (A Linux LiveCD with a custom Flashrom tool. Also: BACKUP THE STOCK IMAGE ELSEWHERE, the LiveCD is volatile!) then flash back the propietary one, if for some reason your Hardware is not compatible, the Motherboard will do nothing, as if it was dead. There are no PC Speaker beep codes or any other life signals to know what went wrong, unless you somehow can wire up the internal Serial Port, which is what is being used to get logs for development. Also, the BIOS Flashback does not work after flashing the Dasharo image. In other words: YOU ARE BRICKED WITH NO MEANS TO RECOVERY, unless you have an external SPI reprogrammer and associated tools to wire it to the chip on the Motherboard. So I guess than the guy that said that "fully brickeable" should be a marketing checkpoint won the Internet, heh.

2 - The main PCIe 16x Slot does NOT work because the PCIe 5.0 Controller initializes in a different way and is still not implemented. Discrete Video Cards weren't tested in the other two slots. This means that you NEED an Alder Lake with IGP. Otherwise, even if it works, you will not be able to get video out at all, or any other life signal.

3 - We only tested with a single DDR4 module type. While most likely it works with a far larger variety, you most likely want to have multiple modules to test just in case.

4 - DDR4 clock speed and Timmings defaults to JEDEC standard SPD values. In the module we are testing with, it is 2400 MHz, albeit it is possible to manually force the XMP profiles if toying with the code. This will be important when we get to benchmarks, cause the easiest way would be to set the propietary Firmware to use the same values than manually setting ours. I would expect that some reference module that has 3200 MHz as a standard SPD profile should work out-of-the-box, but is not what we have.

5 - Windows 11 installs out-of-the-box (Not sure if in v0.3 but on latest WIP it was tested). However, because the Firmware image may contain unique things like Serial Number, UUID and MAC Address, whereas the public generic image has placeholders, it may wreck the Windows activation if you flash Dasharo then attempt to boot a preexisting Windows installation. Also, if using encryption with fTPM remember than BitLocker keys should be stored in Firmware, so you're wrecking that, too. So DO NOT TRY THIS WITH ENCRYPTION ENABLED! At some point it should be possible to automate the transfer of the unique data, but we're not there yet, so play safe.

6 - No benchmarks were performed. This could be either a good or bad surprise. For one, you will need to match DDR4 clock speed and Timmings if comparing between both propietary and coreboot. Processor clock speed, Turbo limits and such are default Intel values.

7 - There was a mention on overclock.net that there is a new PCB revision for the MSI PRO Z690-A WIFI DDR4 from around March. Our unit is from late December, PCB is revision 1.01 I think, would have to confirm this. No idea if there is any functional difference yet. Also, the non-WiFi version (PRO Z690-A DDR4) should be expected to work, but not tested cause we don't have it.
 
Last edited:
Dear HardForum Community,
we would like to invite you to our fifth quarterly virtual party, which we call Dasharo open-source firmware vPub, in this case it is Spring 2022 edition and will happen 26th May 4PM UTC.

Event website is: https://vpub.dasharo.com

We would be glad to discuss ideas and plans for Dasharo compatible with MSI PRO Z690-A DDR4 evolution. We will present some demos and talk about open instruction set architecture, open-source hardware and open-source firmware. We definitely would like to make this quarterly events attractive to HardForum community members since we have a lot of in common and I believe we can learn a lot from each other.

We believe in community and that's why in this weird times we started vPub to just have a chat, dring some 🍻 or other beverage of your choice and talk what we care about hardware and firmware required to initialize it.

We hope to see you there.
 
Phoronix finally reviewed the port. I have been waiting for this moment for the last month, heh. Do note that performance across the board is lower, but there is a good excuse for that (See below).

I'm currently testing with a 12600K with no dGPU. It can install Windows 11 with no issues (Secure Boot + fTPM). Photo.

The performance difference is most likely because Dasharo is using Intel specified power limits. PL1 and PL2 are 125W/150W on my 12600K, respectively. When using MSI stock Firmware, loading default options put it in Water Cooling mode (I don't know if with non-K CPUs like Phoronix 12400 it works the same way). MSI defaults on BIOS 1.43 are these:

Boxed Cooler PL1 241W PL2 241W Current Limit 280A
Tower Air Cooler PL1 288W PL2 288W Current Limit 512A
Water Cooler PL1 4096W PL2 4096W Current Limit 512A

So merely by restoring BIOS defaults, your Power Limits are essencially unlimited. And even the lowest Boxed Cooler option would put it at 241W/241W - you would need to manually input 125W/150W to make the comparison fair. That is part of the set of tricks that is used to cheat in Motherboard performance differences, whereas Dasharo is plain, dull, stock.
For reference, TechPowerUp reviewed a 12900K with different Power Limits and the difference between 125W/241W vs 241W/241W was around 8%, which would be around the performance deficit I see in the 12600K.

There are certain features which after confirming with 3mdeb I know that are or aren't enabled:

Intel XTU on Windows reports than the platform doesn't support overclocking, so Software overclock is currently impossible.
Resizeable Bar is theorically supported but not enabled because they don't have any compatible card in the lab to actually test it.
HPET is supposedly disabled by default, but I didn't checked this one myself.
There seems to be a featured called TME (Total Memory Encryption) that is partially enabled, but seems misconfigured. It is supposed to carry a performance penalty if actually used, and for comparison, it is disabled on MSI stock Firmware. This is dmesg | grep tme on Arch Linux:

x86/tme: enabled by BIOS
x86/tme: Unknown policy is active: 0x2
x86/mktme: No known encryption algorithm is supported: 0x4
x86/mktme: enabled by BIOS
x86/mktme: 15 KeyIDs available

I tested DPC Latency on Dasharo with Latencymon but didn't compared it to stock Firmware. And it is rather hard to test consistently. On idle, it seems to hovers from 10-30 Microseconds.
A few days ago there was an user that reported on chat support channel that his GeForce 3050 Ti made his computer to not POST if Secure Boot was enabled (Which it is by default, so you can get yourself bricked if you're using a F processor and don't have another dGPU to get video output). No idea why this happens since for other users dGPU worked with no need to add custom certificates. I'm going to test a Radeon 5600XT next.

There is something really off about certain POST/boot times. I used an USB Flash Drive made with Ventoy to have multiple ISOs on it, and there is a strange 10-15 seconds delay from loading Ventoy Boot Loader before getting Arch Linux or Ubuntu one. This is instant on MSI stock Firmware. Phoronix also reports a Systemd Total Boot Time (Test: Kernel) that is more than two times slower than MSI stock. That is literally THE only obscene bug I found, the other one is where the POST slowed down to a 5x slower crawl after a warm reset while booting W11 install ISO which I didn't tried to reproduce, but fixed after a power cycle.

Also, a fair warning: While a clean W11 install works, I didn't tested anything related to migrating activation status. I used the Dasharo generic binary which uses a placeholder Serial Number. There are instructions to migrate the MSI Firmware Serial Number and UUID to Dasharo, but they are too complex since you have to set up a compiling environment to sign the binary yourself and decided to omit doing all that.
Anything involving Keys stored in the fTPM is also not migrated, so if you use, say, BitLocker, you must likely going to lock yourself out of that disk. Due to the fact that most interesed users and the developers are Linux users, and I have no first hand experience with some Windows features, there is a lack of experience dealing with possible issues. So if you're NOT doing a clean install, I suggest to wait for someone that test this.
 
The performance difference is most likely because Dasharo is using Intel specified power limits. PL1 and PL2 are 125W/150W on my 12600K, respectively. When using MSI stock Firmware, loading default options put it in Water Cooling mode (I don't know if with non-K CPUs like Phoronix 12400 it works the same way). MSI defaults on BIOS 1.43 are these:

Boxed Cooler PL1 241W PL2 241W Current Limit 280A
Tower Air Cooler PL1 288W PL2 288W Current Limit 512A
Water Cooler PL1 4096W PL2 4096W Current Limit 512A

4 kilawatts seems excessive even if it was the limit for extreme OC using a liquid helium pot.

(Yes I know that 4096W is almost certainly the maximum value and standing in for the lack of an explicit way to set "unlimited".)
 
If there is still people interesed, I posted some benchmarks here: https://github.com/Dasharo/dasharo-issues/issues/173
I will need to find a better way to post those screenshots and log reports because it is just some assorted data dump (There are 2 comments for 2 benchmark rounds), so here is the TL;DR version:

For the 12600K, MSI Firmware by default uses AC/DC Loadline values of 80 mOhm vs 170 in Dasharo, which follows Intel specifications (I have close by a similar computer with a 12400 like the one that Phoronix used in its review, where MSI was using 110 mOhm instead). This sole setting directly translates in a measurably lower power consumption, which eventually gives MSI a higher Turbo headroom.
Without Turbo, which means max 6 P-Core @ 3.7 GHz and 4 E-Core @ 2.8 GHz, at Full Load there is a 8W difference between 80 and 170. With Turbo, the difference is near 20W, which is far more significant because it means that it hits PL1. If I set 170 on MSI Firmware, I get same power consumption levels than Dasharo, +/- 1W.
On the MSI Firmware, with 80 AC/DC and Turbo, 12600K consumes max around 113W and maintains maximum Turbo speeds consistently. The problem lies @ 170 AC/DC Loadlines, since it hits 133W or so. This is beyond PL1 125W, and after some time, it throttles back to 125W with slighty lower clocks.
Here is the main difference than Dasharo has: It is evenly matched in clocks with MSI @ 170 AC/DC for the PL2 Tau duration (It is 28s by default and set as such in MSI, but last a whole minute or so), but MSI throttles to 125W, whereas Dasharo goes to 111W or so with corresponding lower clocks. No idea why it throttles further, given than PL1 still has headroom.
I have these benchmarks but didn't published them since I had issues figuring out a proper benchmarking methodology as these were the first I did, so they aren't on the link. Most likely I would redo it before publishing. Or better yet, I'l publish them when I find out a way to make a data dump readable.

The rest of benchmarks involves tracking down a very particular issue: Dasharo without Turbo (Cause due to the mentioned PL1 behavior above I can't benchmark at same clock speeds with Turbo enabled) on Cinebench R23 scored just slighty lower (1-2%) than MSI @ 170 AC/DC Loadline on Multicore, but Single Core could be anywhere from 100 to 200 points behind. After checking Intel XTU logs, I figured out that with MSI Firmware, Cinebench was loading only P-Cores whereas with Dasharo it ended up on E-Cores quite often. After spending some time playing with CPU Affinity, I used Process Lasso since it has an option to reapply CPU Affinity settings automatically as Cinebench likes to reset that everytime you run a benchmark, and voila, Dasharo is near MSI, albeit always 1-2% slower.
Dasharo still needs a lot of work in Firmware hints for CPU Scheduler since ST performance suffers due to Windows putting stuff in E-Cores (I didn't benchmark on Linux so I have no idea how it behaves there). I know that Intel provides massive optimization guides, so there is a lot of room to cover.
 
  • Like
Reactions: Nobu
like this
Back
Top