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(...) ?
-----Original Message----- From: coreboot-bounces+scott=notabs.org@coreboot.org [mailto:coreboot-bounces+scott=notabs.org@coreboot.org] On Behalf Of Xavi Drudis Ferran Sent: Monday, February 21, 2011 07:48 AM To: Stefan Reinauer; coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] disabling microcode update
]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)
This really isn't relevant, but microcode patch source code certainly exists, as does source code for the main microcode that the patch modifies. A microcode assembler converts the source code into binary form.
Think about what it would take for public microcode patch source code to be useful. First, the processor vendor would have to publish the thousands of lines of source code for the microcode that will be patched. Next, the microcode assembler and related tools would have to be published. At that point, a lot of training is needed to even understand the microcode. Microcode is not written in any standard programming language. The language is completely different for different processor vendors, and even for different processor models in some cases. Anyway, assume that somehow a non-employee became a microcode expert for a particular processor model. Why would the patch need to be modified? The patch corrects a processor erratum. To modify microcode in a way that works around a processor erratum usually requires details of the processor design that are not published.
When a processor is purchased, its source code is not provided. The microcode patch is a modification of the processor design, so it is not surprising the source code is not supplied.
Thanks, Scott
Next, the processor vendor will have to publish the source code to the microprocessor itself. The microprocessor source code is needed
On Mon, Feb 21, 2011 at 08:44:35AM -0600, Scott Duplichan wrote:
This really isn't relevant, but microcode patch source code certainly exists, as does source code for the main microcode that the patch modifies. A microcode assembler converts the source code into binary form.
I think it's relevant. In any case, thank you for the information.
Think about what it would take for public microcode patch source code to be useful. First, the processor vendor would have to publish the thousands of lines of source code for the microcode that will be patched. Next, the microcode assembler and related tools would have to be published. At that point, a lot of training is needed to even understand the microcode. Microcode is not written in any standard programming language. The language is completely different for different processor vendors, and even for different processor models in some cases. Anyway, assume that somehow a non-employee became a microcode expert for a particular processor model. Why would the patch need to be modified? The patch corrects a processor erratum. To modify microcode in a way that works around a processor erratum usually requires details of the processor design that are not published.
Yes, I know the processor is not open hardware. Yet, the issue does not vanish just because of this.
You say it would require an expert. Well, that's what average people think of free software, it takes an expert to modify a program, so who needs software freedom. I won't untangle that fallacy here to avoid preaching to the choir. Sure, there may be more experts apt at modifying emacs than certain microcode source, but so what? Before I knew coreboot I didn't think the expertise necessary to write firmware could be had in a free software project, and now I'm arguing with one of those experts I thought didn't exist.
There are several free software projects that work around or reverse engineer secret designs. The fact that it is unlikely or difficult is no excuse to use other people's work against the license they have choosen. It's not me you have to convince or you I have to convince, it's any copyright holder to code linked to this microcode if we want to make a derivative work.
When a processor is purchased, its source code is not provided. The microcode patch is a modification of the processor design, so it is not surprising the source code is not supplied.
That's a particular point of view, seeing microcode patches as some kind of binary soldering iron of sorts. I don't see it like that. Changing microcode does not change the microprocessor design any more than changing documentation or firmware. The circuits are so that given some microcode perfom some function. They'd do something else with a different microcode but they would still be the same circuits. Otherwise any software would be a circuit metamorphoser.
I see microcode as a preloaded propietary program for a VLIW processor whose purpose is to emulate a CISC processor that happens to have more application software available. The x86, amd64 or whatever instruction set works just like an ABI, similar to parrot or java bytecodes allowing people to write once and run anywhere, and makes economic sense. But it does not change the nature of the VLIW processor.
The processor design is information, VHDL programs if you like. The only thing that distinguishes the logic that goes to silicon from what goes to software is the possibility to change it without building another device. Therefore, microcode is software for a (nondocumented) machine as soon as it can be modified. This VLIW nondocumented machine could have compilers for any language that generate microcode or interpreters for other instruction sets, and maybe I could have the compiler generate a new opcode to optimize a tight loop or run ARM or PPC binaries in my Phenom. Not that I'm interested, I'd rather recompile free software for amd64. And not that it would be economic to build such a compiler backend for such a small number of CPUs out there.
All this is not trying to bash any cpu vendor or imply any wrongdoing by anyone. When I bought my CPU it was advertised as amd64, x86 , MMX , etc. compatible, not as a VLIW processor I could reprogram by microcode patches. And I'm not claiming I have a great business model for paying the engineers and factories to build open hardware of similar power (although if someone does, I'd like to get some advertising). And I'm not saying that I'm surprised to know that sources or documentation for microcode or cpu designs are not published. I'm just surprised to find microcode linked into GPL binaries. My intent is just to explain that those wanting these binary parts left out of their coreboot image are not some kind of luddite zealots, simply people that like to apply uniform criteria to their free software.
And this is just too much for a rationale for a 69 lines patch, so I'll leave it here and sorry for the noise.
Xavi Drudis Ferran wrote:
Does everyone prefer to have it not include update_microcode.c and change romstage.c in those boards that call update_microcode(...) ?
At least I like this better. It makes it clear what effect this option has for mainboard code.
//Peter
On 02/22/2011 02:47 AM, Peter Stuge wrote:
Xavi Drudis Ferran wrote:
Does everyone prefer to have it not include update_microcode.c and change romstage.c in those boards that call update_microcode(...) ?
At least I like this better. It makes it clear what effect this option has for mainboard code.
If this option ever existed, I want it to stay out of my way entirely. I don't even want to know it exists without explicitly searching for it. I don't want to ever be in the situation where I find out that my board froze because the microcode update was disabled, and I don't want newcomers to waste their time asking about that pompous sounding "Disable Microcode update" option in menuconfig.
If I _really_ wanted to disable microcode updates, I would simply comment out a line of code.
As far as the licensing discusion gooes, I have thought of this intensely. I don't see microcode as violating my freedom. It is hardware. modifying microcode modifies the hardware. This is something that software cannot do.
+ We are firmware developers, not hardware engineers.
I'm not voting no on this, just so as long as it is completely invisible to me.
Alex
-
Alex G. -
Peter Stuge -
Scott Duplichan -
Xavi Drudis Ferran -
xdrudis