[coreboot] Removing microcode updates from blobs

[Kyösti Mälkki]

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