[coreboot] [PATCH] disabling microcode update

Xavi Drudis Ferran xdrudis at tinet.cat
Mon Feb 21 14:47:33 CET 2011


On Mon 21/02/11 03:58 , Stefan Reinauer <stefan.reinauer at coreboot.org> wrote:

> On 2/19/11 12:45 PM, xdrudis wrote:   
> On Fri, Feb 18, 2011 at 10:19:31AM -0500, Ward Vandewege wrote:
> 
> > Hi Xavi,
>> > On Wed, Feb 16, 2011 at 02:45:02PM +0100, Xavi Drudis Ferran 
> wrote:
> > > Should I send a patch making a Kconfig option to not upgra
> > > de microcode for fam10? Is there any interest in that ? 

> What's the particular rationale behind this? 

Rationale for disabling microcode update:

Ivaylo and I have had issues when updating microcode in FAM10

We dont' have source for it (if it exists at all)

I've suggested it and got 2 expressions of interest and negative reaction, so I did it.

Some mainboard Kconfig specify one header file for microcode and some 
another. I'm not aware of the criteria for picking one or other (looking at svn log
it appears to depend on the CPU revision, but I think I remember there was some
revisions which could get more than one header file). If you disable microcode 
update you may use the same mainboard dir for some more different CPU revisions, 
assuming you are not affected by any of the bugs the microcode update adresses.
 
Rationale for restricting it to FAM10

Laziness/Lack of time

lack of hadrware for testing

no specfific request, no specific issues reported on other hardware

> When disabling microcode
> updates, why don't you also disable the other erratas?

Because we have source for that code, and some documentation.I've 
fixed code for erratas when it has given me problems. But I cannot fix
microcode, only disable update. 

>> 
>> +          Select this to apply (propietary?) patches to t
>> he cpu
> I don't think the word proprietary (nor the question mark) applies very
> well here.
>

word :

I meant propietary as in non-free. Of course within out legal systems 
all code is the property of some person or entity, and in that sense it is 
propietary. But I meant non-free. Would it be better "non-free" ? 
Have another suggestion for a word to tell its difference of its distribution
terms with the rest of coreboot (or most of the rest)

question mark:

Laziness. I have only looked at one microcode file. I don't know about the license
for the rest. I agree to remove it if you know it's all the same

> +          microcode provided by AMD to correct issues in�
> �the CPU after+          production, and distributed with coreboot (not n
> ecessarily+          the latest microcode version produced by AMD, b
> ut only+          applied if newer than the version in your CPU)
> .+
> +      Unselect to let FAM10 CPUs run with factory microcode.
>   If
> Here's some formatting problem. It's also unclear what you mean by
> "factory microcode" imho.
> 

formatting: 
sorry, I think a tab slipped in. I'll try to fix it if we agree to a new text.

"factory microcode":
possibly my poor English. I meant the version of the microcode the 
CPU came with from factory, that is, the version of microcode that 
will be used in the CPU if we don't update microcode. 


> +          you unselect this, no binary microcode patches 
> will be+          included in the image, so it will help you ge
> t an image+          which you have the entire source code for and�
> �may simplify+          license compliance (IANAL).
> 
> I don't see how this makes license compliance any easier. Also, please
> refrain from using terms like IANAL. If we make claims they should be
> either right to the best of our knowledge or we don't put them in the
> source code, anyways.
> 

It is right to the best of my knowledge, but IANAL, so my knowledge may 
not be enough. I agree to remove IANAL if the list thinks it's enough.
 
License compliance is easier when there are fewer licenses to deal with. 
update_microcode.c is under GPL. It includes one of a few header files, 
like mc_patch_010000b6.h which
 has an adhoc license restricting uses (you can't use it for teaching, not
explicitly allowing redistribution, etc.). For a layman it is easier not to 
worry about whether that is linkable with GPL code, whether the forbidden 
uses are possible, whether some copyright holder will one day sue 
because their GPL code is in coreboot liked with this... Having to decide
about implicit licenses in sign-off, application of "source code" definition, 
etc. isn't so simple.

It may be safe after all, but it is easier to make sure if you don't inlcude it. 
License compliance would be simplified by removing microcode 
even if the microcode was BSD licensed.
The fewer licenses the simpler it is. Although probably if it was BSD I wouldn't
have bothered sayign it. Those of us who are mere individuals and like 
to try to keep legal without a legal department may like this extra simplicity.

> BTW, some corporations had legal teams analyze the microcode license and
> it was considered not problematic for inclusion in coreboot in the sense of
> the GPL.
> 

Which wouldn't have been needed if everything was GPL, right ? So disabling
microcode simplifies license compliance.
But I'd be interested in reading their arguments if you can share them. 
I'm sure for example AMD has nothing to fear here, since they don't distribute
coreboot and don't need a license for their own contributions. 

> +#if CONFIG_UPDATE_CPU_MICROCODE
> static const u8 microcode_updates[] __attribute__ ((aligned(16))) = 
> {
> Please change the patch to not include update_microcode.c in the
> Makefile for the case that microcode selection is disabled.
> 

I thought of that, then I opened Makefile.inc and found
# no conditionals here. If you include this file from a socket, then you get all the binaries.

I wasn't sure whether "no conditionals here" was a statement of fact or a policy statement, 
so in order not to step on anybody's toes, I looked at doing it in some other way. 
Then I found that by keepping an empty update_microcode I didn't have to change calls
in some romstage.c files, and I wouldn't potentially break any board not yet commited. 
So I thought the patch I sent was less invasive. 

To recap: 

I can change the text, but you may not like it again. Can you suggest some other help text 
for the otpion ? 

Does everyone prefer to have it not include update_microcode.c and change romstage.c in 
those boards that call update_microcode(...) ? 





More information about the coreboot mailing list