Open-Source Coreboot Port Working On A Retail Intel Alder Lake MSI Motherboard

[NM64]

what are the most important features that coreboot missing, that you would include if you would have requried resources?

How about re-enabling AVX-512? :P (though apparently Intel is now fusing that off at the hardware level...)

Anyway, as more of a hardware enthusiast than a software enthusiast, I'm nowhere near as active on Phoronix as I have been in other, more hardware-related places recently (e.g. framework laptop community, as well as having some ancient user accounts on both hardocp/hardforum and overclock.net)

So speaking of which, are you focusing exclusively on desktop motherboards at this time? Because, as much as I the flexibility of desktops, a lot of the non-desktop stuff are the platforms that tend to have REALLY locked-down or limited BIOS options - for modern non-desktop devices, a lack of fan curve options tends to be particularly annoying, not to mention wifi card whitelists, very uncommon XMP support, and virtually non-existant ECC support. (though it's sounding like the desktop Ryzen 5800X3D's lack of even underclocking and/or undervolting may be another particularly annoying thing)

Though even on desktops, my own MSI z97 motherboard annoyingly has a minimum fan speed percentage of... I don't remember exactly, but it's something like 10 to 30% whereby it doesn't let you set a 0% fan speed at all, even at low temperature in the way that modern GPUs and PSUs will do.

And don't get me started on the infamous Microsoft Pluton currently on the Ryzen 6000 chips, let alone Intel's Management Engine (ME) and AMD's Platform Security Processor (PSP).

Nevertheless, I imagine a big reason for focusing on desktop is because embedded systems/laptops/tablets are much less standardized and proprietary and so the amount of benefit to porting coreboot to one of them would be minor (though I would imagine that porting coreboot to something like the Steam Deck could be particularly interesting). That being said, ECC support is always more welcome even on desktop since so many chips have the hardware but it is simply not enabled in firmware, even on AMD (non-pro APUs are the same silicon as pro APUs but, for APUs, only the pro models have ECC enabled in AGESA firmware).

Speaking of laptops, I know that the Framework Laptop folks were looking into coreboot and have already open sourced their embedded controller firmware; I don't suppose there's some "synergy" that could happen between your team and Framework since Framework are really big into the sort of ideas that makes coreboot, well, coreboot and their audience definitely skews towards the right-to-repair and/or libre PC-enthusiast type. Furthermore, this would also be more "standardized" hardware than you get on your usual embedded systems/laptops/tablets.

[miczyg]

would it be possible to support ecc ram (with supported intel cpu's)?

Unfortunately not on PRO Z690-A board. ECC is supposedly supported only with W680 chipset

[pietrushnic]

Termy I added issue quoting your post here. Just to make sure we will get back to that at some point.

[pietrushnic]

How about re-enabling AVX-512? :P (though apparently Intel is now fusing that off at the hardware level...)

I'm not sure if we are good company for that.

Anyway, as more of a hardware enthusiast than a software enthusiast, I'm nowhere near as active on Phoronix as I have been in other, more hardware-related places recently (e.g. framework laptop community, as well as having some ancient user accounts on both hardocp/hardforum and overclock.net)

We are also active in framework forum [1], [2], [3]. Feel free to ping me in threads which need our expertise.

So speaking of which, are you focusing exclusively on desktop motherboards at this time? Because, as much as I the flexibility of desktops, a lot of the non-desktop stuff are the platforms that tend to have REALLY locked-down or limited BIOS options - for modern non-desktop devices, a lack of fan curve options tends to be particularly annoying, not to mention wifi card whitelists, very uncommon XMP support, and virtually non-existant ECC support. (though it's sounding like the desktop Ryzen 5800X3D's lack of even underclocking and/or undervolting may be another particularly annoying thing)

We're focusing on open-source firmware for platform demanded by our customers. Please note our history is very close to embedded world. We maintain PC Engines firmware since 2016, so embedded environment is something we are really interested. Server market is also something we can deliver value to.

If we can classify mainboards per family and put that in github issue, then if somoene would like to sponsor given AMD family we can get back here to let you know there is hope/potential to address those issues.

Though even on desktops, my own MSI z97 motherboard annoyingly has a minimum fan speed percentage of... I don't remember exactly, but it's something like 10 to 30% whereby it doesn't let you set a 0% fan speed at all, even at low temperature in the way that modern GPUs and PSUs will do.

And don't get me started on the infamous Microsoft Pluton currently on the Ryzen 6000 chips, let alone Intel's Management Engine (ME) and AMD's Platform Security Processor (PSP).

I tried to explain our position about current state of closed source microcontrollers multiple times at various conferences and vPubs. There is not much we can do. All those companies want to have their own value-added, technology supply chain control in hardware. Every serious company have to have that. Arm has TrustZone, OpenPOWER has SBE and couple other processors in processor etc. I'm pretty sure that if we would look in NVIDIA GPUs we probably would find the same paradigm. Best scientific explanation it happens, that I am aware of why, is here.

Nevertheless, I imagine a big reason for focusing on desktop is because embedded systems/laptops/tablets are much less standardized and proprietary and so the amount of benefit to porting coreboot to one of them would be minor (though I would imagine that porting coreboot to something like the Steam Deck could be particularly interesting). That being said, ECC support is always more welcome even on desktop since so many chips have the hardware but it is simply not enabled in firmware, even on AMD (non-pro APUs are the same silicon as pro APUs but, for APUs, only the pro models have ECC enabled in AGESA firmware).

Speaking of laptops, I know that the Framework Laptop folks were looking into coreboot and have already open sourced their embedded controller firmware; I don't suppose there's some "synergy" that could happen between your team and Framework since Framework are really big into the sort of ideas that makes coreboot, well, coreboot and their audience definitely skews towards the right-to-repair and/or libre PC-enthusiast type. Furthermore, this would also be more "standardized" hardware than you get on your usual embedded systems/laptops/tablets.

I'm pretty sure Framework Team is aware of 3mdeb work

Anyway, thank you for insightful post a lot of appealing points. It would be great to structure that and put on Dasharo roadmap.

[pietrushnic]

AMD makes a great product right now, but Intel still has >80% market share. It makes a lot of sense to go with the market leader when the competition makes you jump through the same (or more) hoops. Maybe AMD will learn this and do better at helping enthusiastic small companies to ship products with their chips.

davidhendricks agree, just couldn't express that as good as you did. Open-source firmware ecosystem would move way faster if every major organization would have someone with at least part of your mindset.

[mazumoto]

mazumoto unfortunately AMD is not easy to play with, we're trying hard, but let's be honest for now Intel has better ecosystem for open-source firmware development. This may be because AMD is in rush, and they are terribly understaffed in all areas in comparison to success they achieved. We're doing AMD open-source firmware development for 6+ years, including our yearly reports of open-source firmware status at FOSDEM, but level of support for small volume firmware developing company is not yet at level of competition.

Thanks a lot for the insight, I really appreciate it!
It's very unfortunate that AMD doesn't see it as a chance to differentiate themselves from other vendors (intel) by being more open. And their AGESA problems (USB connectivity, WHEA errors, etc. - for years) don't make them look very competent in developing firmware.

[Termy]

It's very unfortunate that AMD doesn't see it as a chance to differentiate themselves from other vendors (intel) by being more open.

They "promised" to open up the Firmware and PSP years ago and i still haven't heard of one tiny step in that direction - kind of disappointing given their good track record on the GPU-side :/

[NM64]

Anyway, thank you for insightful post a lot of appealing points.

While I'm here I might as well quickly mention two possibly less important, unrelated, and/or not-applicable things.

1. On the subject of locked-down devices, I've come into possession of a OneXPlayer equipped with a Ryzen 4800U and, bloody nora, I think it may have the most locked-down BIOS that I've ever seen - I can change the time, boot device order, quiet boot/splash screen, and I honestly think that's it which is unfortunate because the fan curve is WAAAAAAAY too aggressive, and the minimum fan speed it wants to run at is still way too loud for me despite temps only being in the 50s (I can hear it from the other side of a closed door ~2 meters away). I have an older HP DM1 laptop that's similar but isn't quite as loud, as well as an Asus EeePC 1000H that could run its first-gen Intel Atom completely passively and would max out at only ~85c, but this requires OS-level fan control software as the BIOS of course contains no options for that, not to mention the fan is also very loud and overly-aggressive (and I'm not even sure it does much of anything due to having no intake?)

2. SSD firmware; speaking of Framework, I find it a bit ironic that they use Western Digital SSDs when Western Digital only provides SSD firmware updates via a Windows EXE. Also I had the "joy" of experiencing Crucial's "power-loss protection" on a 480GB M500 and 512GB M550 where, if it detects poor power delivery or other issues with the power source, it'll permanently lock the drive into a read-only state, and yes it's completely permanent AFAIK despite a secure erase actually still functioning correctly (I even bit the bullet and contacted Crucial support, but alas they said there was nothing I could do). Interestingly I had an older 256GB Crucial M4 which predates this "power-loss protection" and, when it too ran into a situation of insufficient power, it initially seemed like it died but, after leaving the M4 plugged to only power for around an hour, unplugging it, then plugging it back in, the drive "just worked".

[DanaG]

I'd love to have CoreBoot in a modern low-power server board (Xeon D or such). I have an Asrock X570D4U-2L2T, and the firmware is kinda garbage: the IPMI shared interface drops connection during reboot, and the web UI lacks any options for serial-over-lan, and the BIOS doesn't allow ANY sort of suspend states. Also, it doesn't give very good control of the EFI framebuffer, and the BMC is artificially limited to 1024x768 and no EDID, unlike my previous board that would pass through a VGA monitor's EDID.

I realized I don't really need that much horsepower in my server machine, so something low-power with ECC would be best, but I'd still want something with at least one 10-gigabit ethernet to play with. The closest I've seen was a CoreBoot port for an Asrock Haswell board, but it had something about "no guarantees about ECC actually working" on it, and it stated that there was no fan control.

I'd also have to figure out what to do with that X570D4U-2L2T and the Ryzen 3700X in it. If I'd known the problems, I wouldn't have bought that board. I could sell it, but dunno who'd buy it.

[pietrushnic]

Thank you for comments NM64 and DanaG .

From my perspective this show that there is a lot of value to deliver because of poorly tested and developed vendor firmware. Existing firmware supply chain is broken and many people working in this ecosystem for years do not see need or potential for change.

Unfortunately, based on individual cases it is hard to build business model. Engineering time even in cases that at surface looks trivial is still expensive and driving high-risk business like embedded firmware development may not add up. That's why I think ecosystem requires new business models for firmware development. More to that above cases, if by any chance would be addressed by open-source firmware in the future, could be used as success stories. We require those stories to convince vendors that open-source firmware bring value.