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

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Tue Apr 22 22:46:29 CEST 2008


On 22.04.2008 22:37, Stefan Reinauer wrote:
> 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.

This was meant as "I hope there are no errata which could be triggered
by the lzma code".

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

Sorry, I have to admit I'm rather ignorant about microcode updates.
Thanks for educating me.

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

OK. I was just trying to address Marc's concerns.

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

OK, let's defer that to a point in time when we need 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.

Thanks for clarifying!

Regards,
Carl-Daniel




More information about the coreboot mailing list