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) is still not enough to even boot the platform...
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?
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?
reply