No - Coreboot knows exactly what is being run, both revision and SKU. This was a decision about what silicon should be supported by the coreboot code. The earlier silicon revisions had issues which will may at times cause failures unrelated to coreboot. Because of this, the decision was made that only B2/B3 silicon was going to be supported by the coreboot release. I'm working with Intel now and we're re-visiting that decision.
Currently coreboot doesn't do anything with the microcode more than providing the FSP with a pointer and length. We could certainly add code to coreboot to parse through all of the headers at runtime and verify that there's a valid microcode patch included, but the FSP is supposed to do that already. I think that code just needs to be enhanced.
Martin
On 06/05/2014 11:02 AM, Peter Stuge wrote:
Martin Roth wrote:
- The microcode that's included for the intel FSP is for B2/B3 silicon,
but it seems like many users are still using B0 silicon, which requires a different microcode patch. This shouldn't be a problem but since there are 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR* to work, but cause issues later
Are you saying that there is no way for coreboot to know which silicon it is running on?
If the same code is supposed to work across more silicon revisions then the only helpful solution I can think of is to allow choosing in Kconfig which platforms should be supported by the image that is being built. Yes/no per silicon revision, with microcode pulled in for each one. The code would need to check at runtime which silicon it is running on, and load the corresponding microcode.
//Peter