On Mon 21/02/11 03:58 , Stefan Reinauer stefan.reinauer@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(...) ?