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:
2) 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
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
