[coreboot] [patch][v2][2/4] Family 10

Stefan Reinauer stepan at coresystems.de
Tue Apr 22 22:37:09 CEST 2008

Carl-Daniel Hailfinger wrote:
> As the resident "everything in LAR" guy I'm strongly in favour of having
> microcode updates as blobs in a LAR. Two points need to be made sure,
> though:
> - If we compress the update, a decompression routine must not be able to
> trigger data-corruption bugs.
You mean you want to make our lzma algorithm more solid? That's welcome.

> - We have to know whether microcode updates can be deferred to a point
> after RAMinit.
Why do you think it should be deferred? It currently happens in what is 
stage2. That's long time after ram is initialized. It's even after all 
the PCI init.

> Agreed. Can we handle this like IP routing tables?
> Store familiy/model/stepping together with number of significant bits
> from the left, then pick the one which matches and has most significant
> digits.
That's basically how it has been working for the last 5 years, except 
that you can not omit family or model.
Adding that complexity is questionable, given that we don't even use the 
flexibility we have since 5+ ys except on the VIA CPUs where I recently 
introduced it.

> That even allows for append-only tables with overrides.
This should work quite nicely. If someone would use it.

> We have to make sure that the table is stored in a separate LAR blob to
> avoid having to update stage2 for microcode updates and more supported
> processors.
The table has nothing to do with the microcode. Microcode has its own 
format stating for which CPU revision it can be used. What we're talking 
about is the cpu_driver's id_table. Go have a look at the code to see 
how it is implemented. We're really just cutting out cpu steppings 

In the following code snippet

static struct device_operations cpu_dev_ops = {
        .init = model_10xxx_init,
static struct cpu_device_id cpu_table[] = {
        { X86_VENDOR_AMD, 0x100f00 },           /* SH-F0 L1 */
        { X86_VENDOR_AMD, 0x100f10 },           /* M2 */
        { X86_VENDOR_AMD, 0x100f20 },           /* S1g1 */
        { X86_VENDOR_AMD, 0x100f21 },
        { X86_VENDOR_AMD, 0x100f2A },
        { X86_VENDOR_AMD, 0x100f22 },
        { 0, 0 },
static struct cpu_driver model_10xxx __cpu_driver = {
        .ops      = &cpu_dev_ops,
        .id_table = cpu_table,

it would be 100% the same to have a cpu_table struct looking like this:

static struct cpu_device_id cpu_table[] = {
        { X86_VENDOR_AMD, 0x100f00 },           /* SH-F0 L1 */
        { X86_VENDOR_AMD, 0x100f10 },           /* M2 */
        { X86_VENDOR_AMD, 0x100f20 },           /* S1g1 */
        { 0, 0 }

No cpu caught by the version with the 6 IDs would ever fall through the 
3 ID version. It's just duplicate code.
If we really wanted to have special code in place for the 0x100f2A, we'd 
have to have a seperate struct cpu_driver anyways.


coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080422/37d6194d/attachment.sig>

More information about the coreboot mailing list