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

[Stefan Reinauer]

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 
artificially.

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.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://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>