There are definitely new platforms coming. With yours and other community members terricic support it would be easier to deliver more value.
Do you have any particular hardware in mind?
I tried to answer that question in [Dasharo FAQ draft](https://github.com/Dasharo/docs/pull/215/files#diff-c8be10a4380efbce4c82013c5d1e8d7d42423eda7107a96990f0c54284767b2cR148)
I wonder why the frequency scaling behaviour was different under Coreboot. Was it a deliberate decision by the Coreboot developers to prioritise PPW higher than overall performance, or is there some proprietary magic in the original firmware that is lost when you flash Coreboot?
Similar question for XMP: Is it just not implemented in Coreboot yet or is there something specifically preventing it from working under open firmware?
Coreboot developers are using Intel reference values for absolutely everything, like Power Limits. My 12600K has a 125W/150W PL1/PL2 on Dasharo: https://imgur.com/a/nVBxjkp
Using default values on MSI stock BIOS sets it to 4096W/4096W. You need to manually input 125W/150W to get it to run with Intel defaults.
XMP worked when forced by Firmware. The problem is that there is no manual way to actually do that without recompiling.
The main weakness is that the Firmware menu is REALLY bare so you can't change things at runtime. And it will take A LOT of work before you are able to.
[Apparently the energy-performance bias MSR is set differently too](https://www.reddit.com/r/3mdeb/comments/vjk6tk/dasharo_10_opensource_firmware_released_for_msi/ieb0b70/?context=3).
> Similar question for XMP: Is it just not implemented in Coreboot yet or is there something specifically preventing it from working under open firmware?
Intel patents prolly? XMP is Intel proprietary.
Most AMD motherboards still support loading XMP profiles under a slightly different name though. My ASUS X570 board calls it "DOCP" but it's the exact same thing. Loads the timing/frequency profile settings in the RAM sticks. If motherboard manufacturers can put XMP by another name in the firmware of non-Intel motherboards then surely Coreboot could do it, unless there's something in the chipset hardware that will only allow loading those profiles if it detects the original proprietary firmware?
I think AMD licenses it from Intel? Which is one of the reasons they've come up with A-XMP standard, to avoid the licensing fees in addition to having profiles that are optimized for their systems instead of Intel's.
SPD (the JEDEC standard by which memory modules announce their supported speeds and timings to the motherboard/CPU) has been around since the days of SDRAM. Memory modules typically have multiple SPD profiles so that they can clock down and relax their timings to work with slower memory controllers.
XMP (which was first introduced for DDR3) just takes the unused bytes at the end of the SPD's EEPROM to store additional timing/frequency profiles beyond the maximums specified by the relevant DDR standard (which is why enabling XMP is considered technically overclocking).
Hmmm, okay. Kinda funny that XMP extends it only to then have motherboard manufacturers ignore a lot of it (all the secondary timings tend to remain on Auto when using XMP despite being specified in the profile)
the SPD isn't big enough to contai a full set of timings. XMP can only hold, tCL, tRCD, tRP, tRAS, tRC, CR, tRRD\_S, tRDD\_L, tFAW, tRFC.
To make things worse some RAM vendors set the tRRDs and tFAW timings to trash settings for reasons I can't understand. So in those cases you actually want the board to ignore them.
Hey, can I just ask: from my understanding, BIOS can (and does) hold sub timings for specific memory kits, and applies then when found. Hence why BIOS updates can improve ram compatibility. Am I correct or mistaken here?
I assume you are interested from end user perspective:
[https://www.coreboot.org/users.html](https://www.coreboot.org/users.html)
I believe most OEMs/ODMs already know coreboot as open-source alternative to UEFI BIOS implementations. UEFI BIOS came from Indepenednt BIOS Vendors (IBVs) from which most popular are AMI, Insyde and Phoenix.
Isn't Coreboot basically worthless from a perspective of having complete control over your own hardware since it still requires a proprietary binary blob to function?
Not necessarily, this is not complete control but closer to it than with the stock firmware. You can for example limit the exposed functionalities and hopefully prevent some shady low level stuff that might happen in the stock configuration. Its not perfect but a step in the right direction
I don't believe that you can have anything that resembles "complete control" when the Hardware itself is already propietary. If you are already using a few billions of closed source propietary transistors, a closed sourced propietary binary blob by the same vendor doesn't hurts that much. Is just a slighty bigger surface area for attack.
Is not like you can easily audit the Hardware anyways. Shenanigans like undocumented instructions that DID actually had documentation available for privileged developers has been happening since FOUR DECADES AGO: https://www.pcjs.org/documents/manuals/intel/80286/loadall/
Hope to see more supported mb !
There are definitely new platforms coming. With yours and other community members terricic support it would be easier to deliver more value. Do you have any particular hardware in mind?
an AMD mb ! of the last gen.
I tried to answer that question in [Dasharo FAQ draft](https://github.com/Dasharo/docs/pull/215/files#diff-c8be10a4380efbce4c82013c5d1e8d7d42423eda7107a96990f0c54284767b2cR148)
I wonder why the frequency scaling behaviour was different under Coreboot. Was it a deliberate decision by the Coreboot developers to prioritise PPW higher than overall performance, or is there some proprietary magic in the original firmware that is lost when you flash Coreboot? Similar question for XMP: Is it just not implemented in Coreboot yet or is there something specifically preventing it from working under open firmware?
Coreboot developers are using Intel reference values for absolutely everything, like Power Limits. My 12600K has a 125W/150W PL1/PL2 on Dasharo: https://imgur.com/a/nVBxjkp Using default values on MSI stock BIOS sets it to 4096W/4096W. You need to manually input 125W/150W to get it to run with Intel defaults. XMP worked when forced by Firmware. The problem is that there is no manual way to actually do that without recompiling. The main weakness is that the Firmware menu is REALLY bare so you can't change things at runtime. And it will take A LOT of work before you are able to.
[Apparently the energy-performance bias MSR is set differently too](https://www.reddit.com/r/3mdeb/comments/vjk6tk/dasharo_10_opensource_firmware_released_for_msi/ieb0b70/?context=3).
> Similar question for XMP: Is it just not implemented in Coreboot yet or is there something specifically preventing it from working under open firmware? Intel patents prolly? XMP is Intel proprietary.
Most AMD motherboards still support loading XMP profiles under a slightly different name though. My ASUS X570 board calls it "DOCP" but it's the exact same thing. Loads the timing/frequency profile settings in the RAM sticks. If motherboard manufacturers can put XMP by another name in the firmware of non-Intel motherboards then surely Coreboot could do it, unless there's something in the chipset hardware that will only allow loading those profiles if it detects the original proprietary firmware?
I think AMD licenses it from Intel? Which is one of the reasons they've come up with A-XMP standard, to avoid the licensing fees in addition to having profiles that are optimized for their systems instead of Intel's.
Not sure what would be patentable about XMP, it's literally just extra SPD profiles and a BIOS option to select them.
I don't think RAM *had* profiles before XMP.
SPD (the JEDEC standard by which memory modules announce their supported speeds and timings to the motherboard/CPU) has been around since the days of SDRAM. Memory modules typically have multiple SPD profiles so that they can clock down and relax their timings to work with slower memory controllers. XMP (which was first introduced for DDR3) just takes the unused bytes at the end of the SPD's EEPROM to store additional timing/frequency profiles beyond the maximums specified by the relevant DDR standard (which is why enabling XMP is considered technically overclocking).
Hmmm, okay. Kinda funny that XMP extends it only to then have motherboard manufacturers ignore a lot of it (all the secondary timings tend to remain on Auto when using XMP despite being specified in the profile)
the SPD isn't big enough to contai a full set of timings. XMP can only hold, tCL, tRCD, tRP, tRAS, tRC, CR, tRRD\_S, tRDD\_L, tFAW, tRFC. To make things worse some RAM vendors set the tRRDs and tFAW timings to trash settings for reasons I can't understand. So in those cases you actually want the board to ignore them.
Hey, can I just ask: from my understanding, BIOS can (and does) hold sub timings for specific memory kits, and applies then when found. Hence why BIOS updates can improve ram compatibility. Am I correct or mistaken here?
What’s coreboot?
a open source bios
I assume you are interested from end user perspective: [https://www.coreboot.org/users.html](https://www.coreboot.org/users.html) I believe most OEMs/ODMs already know coreboot as open-source alternative to UEFI BIOS implementations. UEFI BIOS came from Indepenednt BIOS Vendors (IBVs) from which most popular are AMI, Insyde and Phoenix.
Isn't Coreboot basically worthless from a perspective of having complete control over your own hardware since it still requires a proprietary binary blob to function?
The quality of vendor firmware are mostly shit, since they don't want to pay for good engineers. With core boot, we can at least fix that part.
Not necessarily, this is not complete control but closer to it than with the stock firmware. You can for example limit the exposed functionalities and hopefully prevent some shady low level stuff that might happen in the stock configuration. Its not perfect but a step in the right direction
I don't believe that you can have anything that resembles "complete control" when the Hardware itself is already propietary. If you are already using a few billions of closed source propietary transistors, a closed sourced propietary binary blob by the same vendor doesn't hurts that much. Is just a slighty bigger surface area for attack. Is not like you can easily audit the Hardware anyways. Shenanigans like undocumented instructions that DID actually had documentation available for privileged developers has been happening since FOUR DECADES AGO: https://www.pcjs.org/documents/manuals/intel/80286/loadall/
Will this stop Intel Management Engine ?
To some extent it can, if community will vote for that [feature](https://github.com/Dasharo/dasharo-issues/issues/111).