[coreboot] [PATCH] disabling microcode update

xdrudis xdrudis at tinet.cat
Sat Feb 26 21:19:36 CET 2011


On Sat, Feb 26, 2011 at 04:01:56AM +0200, Alex G. wrote:
> On 02/26/2011 03:38 AM, xdrudis wrote:
> > This is the patch for option B. 
> > 
> > You may not be able to test it without my next patch. At least for me 
> > selectiong EXPERT in make menuconfig breaks the build. Next patch fixes it.
> > 
> > 

> I don't like the wording for the help option. 

Stefan Reinauer didn't like it either and I'm not sure he does now.  I
got no suggestions (alternative wordings) so I changed only the
particulars he pointed to.  Feel free to improve it.

[note: this pretty much summarised the other 120 lines, in case
you don't read it all]

> It creates the impression
> that the entire reason for this option is purely philosophical.

Not having the source, documentation and specific expertise 
is a philosophical problem but not only 
a philosophical problem. One of the consequences is that I can
not give any satisfactory practical reasons for updating or not
updating microcode. All I could write would be 

          Select this to apply non-free patches to the cpu
          microcode provided by AMD to correct issues in the CPU after
          production, and distributed with coreboot (not necessarily
          the latest microcode version produced by AMD, but only
          applied if newer than the version in your CPU). 

          The microcode patches are selected from mainboard Kconfig
          AMD_UCODE_PATCH_FILE among the
          src/cpu/amd/model_10xxx/mc_*.h files provided by AMD. We
          don't know the issues solved by each microcode patch file,
          the issues created by each file (possibly solved in other
          patches present in or absent from coreboot) or the
          preconditions to apply them to your particular CPU or to the
          set of CPUs the image you're configuring may run on.  We
          know the intent of the patches is to solve issues and that
          we've had systems running well with the patches and issues
          also solved by not applying them.
          
          Unselect to let FAM10 CPUs run with the unpatched microcode
          as shipped from factory.  If you unselect this, no binary
          microcode patches will be included in the image, so it will
          help you get an image which you have the entire source code
          for and may simplify license compliance.
          
But since Stefan didn't like "IANAL", I bet he won't like this either.
And maybe others here know more than what I just wrote, or it's
published somewhere, it's just that for philosophical reasons, and the
practical reason that it seems to work without updating microcode for
me, I'm not interested in investigating the microcode details, and I
suspect as much of Ivaylo.  Maybe Ivaylo and I picked the wrong mc*.h
file, maybe the right one isn't there, maybe the checks before the
microcode update are somehow wrong, maybe our CPU is newer than the
mc*.h files and it somehow fools the checks, maybe it's just wrong to
have AMD_UCODE_PATCH_FILE as a mainboard option, and a rutime check
should select, for each processor, beetwen all microcode patches
available, so that a coreboot image could run on any CPU revision you
can put on that board and socket. But I can't get past "maybe".

> I accepted your argument for this option because you quoted practical
> reasons, such as the updated microcode causing problems, and thus I
> would prefer a help text focusing on those reasons.

The practical reasons are that not updating microcode is a shortcut
through a few unknowns, and it may work better or worse than updating it
(certainly better for me an Ivaylo, but I don't write the help for us).
Since it has been previously stated that kconfig help shouldn't be qualified
with uncertainity valuations but just express correct facts to the best
of our knowledge, I'm unable to express the practical reasons without
hinting at uncertain facts. 

The only certain facts are that in some cases it works better without
updating and in some (many?) others it works updating. I think too that
in some cases it doesn't work without updating, but I don't have a
concrete case to show (no fool has tried?). I fail to see how saying
this can help.  It could maybe help to specify the details of when it
works updating or when it works not updating, but since I don't have
source, documentation or expertise, I cannot guess what are the
circumstances that cause it, I could only give every complete setup
for each collection of cases, which seems too detailed and verbose.
Should I say ASUS M4A77TD-PRO with Phenom X4 910e or rev RB_C3 in SVI
or DDR3 with AM3 ?
 
> That is not to say
> to avoid the philosophical issue altogether, but not invoke it as the
> main reason.
> 

I think you overestimate the philosophical nature of practical reasons 
such as a simpler license compliance or working with a source backed code
base. Of course they carry philosophical questions of no small importance
and even epistemological questions here noted, but less legal trouble
and less unknowns are practical reasons as well. 

> Other than that, pretty good job :)
> 

Thank you.

I hope Stefan and Peter agree with you, because I don't. For me it looks
uglier each time. 

In fact this is starting to feel like design by committee. I think I'm
doing something without further researching some parts because I'm not
interested, and, although I wouldn't have bothered the list without
practical reasons, I'm more motivated for legal peace of mind and
software freedom than for the practical reasons, so I'm relunctant to
hide it or to attribute it to practical reasons. And you (and possibly
others) are trying to accept a new option because you want to be nice,
sympathise with some general philosophy, and are concerned with
accomodating all use cases but you think it will hardly ever work so
you want it hidden, explained and with warnings. 

In a way we both stand in a quasi contradictory position each and are
trying to reconcile these different positions. If I liked this sort of
bargaining I'd send a resumé to the European Council. I'm all for peer
review (no offense intended calling you my peers) and throwing more
eyeballs at things, and discussing stuff until we're all convinced, but
I've run out of time and motivation, and i don't really find I have
much more to offer.

If anyone wants to take it from here you can refine and commit one
of these patches (option A or B), or come up with something new, 
but it will take someone more aligned with the general sentiment
than myself, to really code something that makes sense to herself and
later can be made acceptable to all. So I'll leave it here.

Thanks to all for your attention and sorry for not being able of more. 
 




More information about the coreboot mailing list