It has a number of gaps, but it is mostly there. It doesn't build, it doesn't have source for some of the service calls iirc (SVC_.*), and the AGESA source isn't open (though a replacement is in progress, openSIL).
I can't wait for a modern system with an open firmware. Just so that there would be any hope for bugfixes outside "works for (default configuration) Windows".
It's all about incentives. My laptop spends good five seconds after each power-on (or resume from suspend-to-disk), showing me giant vendor's logo and doing nothing else.
Surely, open firmware could skip that and boot faster - if vendor would allow an escape hatch from the "secure boot" hell. But why would they expend effort on something 99.9% of users don't care about, and give up free ads in the process, too?
It is not so easy on servers. The AMD servers platforms perform RAM training on each boot, even before the CPU starts execution the firmware. So no matter of your BIOS/coreboot performance, you have a guaranteed 2min++ boot time (depending on amount of RAM and CPU sockets), because of memory training... There is no concept of fastboot from the cold boot like on Intel silicon.
Memory training or memory testing leading to the minutes long time spent in firmware?
I haven't used the most recent AMD server platforms, but on earlier Epyc generations the memory training and PCIe link training were noticed durations but measured in seconds, not minutes. Turning on debug for the PSP could turn this into minutes but would also show all the results of the memory training sequences. The memory testing would take minutes but was easily disabled to reduce the boot time. Has this changed in the newer Epyc generations?
Good post on troubleshooting the failure to boot, but from the title I was kind of hoping for something like decryption and analysis of the blobs' contents, rather than just metadata. Very "cool" that 3 megabytes of unauditable malware (the public blobs) are still not enough to even boot the platform...
The blog post describes the analysis of PSP blobs on Gigabyte. MZ33-AR1. The analysis covers various aspects of stitching AMD firmware BIOS images and how support for stitching Turin blobs was developed in coreboot.
This is a ridiculously cool blogpost. Thanks for sharing. Lots of detail.
Since you've looked at the firmware there quite a lot would you be able to share if you noticed if ES/QS CPUs have different configurations in the firmware or if it's just a matter of duplicating and renaming so that they're recognized?
I did not have any encounters with ES CPUs from AMD. I just remember my experience with Intel ES CPUs, which used a different set of keys for blob signing. I connected the dots and assumed that this is also true for AMD.
It is not about the configuration but rather a key burned into the CPU silicon that is used to verify the key used in blobs and the signatures of the blobs.
It has a number of gaps, but it is mostly there. It doesn't build, it doesn't have source for some of the service calls iirc (SVC_.*), and the AGESA source isn't open (though a replacement is in progress, openSIL).
Surely, open firmware could skip that and boot faster - if vendor would allow an escape hatch from the "secure boot" hell. But why would they expend effort on something 99.9% of users don't care about, and give up free ads in the process, too?
I haven't used the most recent AMD server platforms, but on earlier Epyc generations the memory training and PCIe link training were noticed durations but measured in seconds, not minutes. Turning on debug for the PSP could turn this into minutes but would also show all the results of the memory training sequences. The memory testing would take minutes but was easily disabled to reduce the boot time. Has this changed in the newer Epyc generations?
(But, to be fair, I find this content really interesting and a great fit for HN.)
Since you've looked at the firmware there quite a lot would you be able to share if you noticed if ES/QS CPUs have different configurations in the firmware or if it's just a matter of duplicating and renaming so that they're recognized?
It is not about the configuration but rather a key burned into the CPU silicon that is used to verify the key used in blobs and the signatures of the blobs.