On 12/14/2013 05:44 AM, ron minnich wrote:
Scott, I don't see the point of this change either.
In the beginning, we had no microcode in coreboot, per the main goal: let linux do it. We just let Linux do the update. Not our problem.
At some point, ca. 2005 or so, we had to let the blobs in because many of the new CPUs are *broken* without the microcode update: the microcode that comes embedded in the CPU must be updated or you'll get some real problems, and possibly not even get through firmware.
As you point out, this is nothing like the VGA BIOS issue.
So, sure, it's pure to build without the microcode blob, which means in reality that you're deciding to use the microcode blob *already embedded in the CPU*. And, on many new CPUs, the one that comes with the CPU has issues that mean you won't get past DRAM init. And, if you do get past DRAM init and boot, you've got a CPU that may have subtle errors and corrupt memory. Oh, joy.
I guess I don't understand why people feel better being able to build a firmware image which will boot the CPU in a broken mode.
ron
I do not understand builds without microcode updates either, but there are the legal aspects to concern.
Microcode update files downloaded from Intel or AMD sites may contain licensing terms not compatible with GPLv2. Those original license texts have not been enclosed in the same commit with microcode update when they were submitted to coreboot.git repository and for some cases they may not have allowed redistribution in any form.
If you are a vendor planning to distribute system with pre-installed coreboot, GPLv2 would dictate that sources and the toolchain need to be available for download. The best solution would be to push to coreboot.git, while the next best would be to host their own public repository. This is where missing or incompatible licensing for files files in coreboot.git may become a show-stopper.
Quoting from FSP review : http://review.coreboot.org/#/c/4016/
Ronald G. Minnich Nov 25 20:15
"And, in fact, vendors over time have shown us they are sensitive on this issue. Keeping it (microcode) in cbfs removes their worries."
With this quote, I do not understand why you are against moving microcodes to blobs.git. I also do not understand why you approved this patch to be submitted to coreboot.git without the (required) microcode update files.
Kyösti
On Fri, Dec 13, 2013 at 11:47 PM, Kyösti Mälkki kyosti.malkki@gmail.com wrote:
Microcode update files downloaded from Intel or AMD sites may contain licensing terms not compatible with GPLv2. Those original license texts have not been enclosed in the same commit with microcode update when they were submitted to coreboot.git repository and for some cases they may not have allowed redistribution in any form.
Given the amount of time we spent in discussions with AMD ca. 2006/7, about making the microcode license work, this is one argument I'm not going to believe. The vendors have been good about making sure they don't break GPLv2.
With this quote, I do not understand why you are against moving microcodes to blobs.git. I also do not understand why you approved this patch to be submitted to coreboot.git without the (required) microcode update files.
because we have something that works today, that we have worked with the vendors to make sure has working licensing. I can not see how moving the microcode to a separate repo improves the situation.
ron
-
Kyösti Mälkki -
ron minnich