[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
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>
More information about the coreboot
mailing list