[coreboot] Removing microcode updates from blobs

[mrnuke]

On 12/14/2013 12:59 AM, ron minnich wrote:
> On Fri, Dec 13, 2013 at 10:46 PM, mrnuke <mr.nuke.me at gmail.com> wrote:
> 
>> You can't have a working build on a bunch of recent hardware without
>> blobs. So the assumption that you can build without blobs is false.
>> Pure and simple.
> 
> ok, so you are upset that "clueless" (your word, not mine :-) people
> complain about blobs, and in response you move a bunch of .h files
> from one place to another? With no real change, mind you, since they
> still have to use them. Nothing is more 'free'.
> 
> What's the point? Why not just enlighten them? I just can not understand this.
> 
Have you tried to enlighten them? Once they boot without microcode (and
they are willing to spend weeks removing the microcode just so they can
try this), and they see that their system works, they don't care if they
have to reboot every other week.

> Again, the intent of the blobs directory was to be a place into which
> to fetch binary blobs, for those things we could not include in the
> main tree. The microcode .h files don't fit that category, given that
> they are already in the tree. So I still don't see a point to all this
> extra effort.
>
The fact that we have them does not necessarily mean it's kosher to
include them. Whould you think differently if intel provided them as
binary, not C-arrays? They are redistributable, but no modification or
reverse engineering is permitted. We have CBFS to get around that.

Now, since we have the trick CBFS available, we can include things like
mrc.bin in the tree. We just can't link them to any stage. They end up
as CBFS files that we asm("jmp") to or asm("call"). However, mrc.bin and
friends reside in blobs.

There is a hidden advantage to moving microcode to blobs, especially on
the AMD site. AMD releases a binary container where they put not only
the updates, but a CPUID to revid mapping table. Right now, that table
is hardcoded in the tree, which makes its maintenance so much harder. If
we add support for that container format, including microcodes is as
simple as including the AMD provided file in CBFS.
I'm also working on a tool to purge that container of unneeded
microcode, and only leave updates relevant to the installed CPU (think
boards with soldered CPU).
If we want to maintain microcode updates for AMD, in their current form,
(I'm thinking non-AGESA), we need to tear down that container, extract
the updates, extract the mapping table, and convert them to C arrays --
every time AMD releases a new update (those updates fix important rare
crashes, so we must include them as soon as possible).

I don't have such a strong argument for the intel side of things.
Consistency is definitely one.

> Anyway, if you can convince me I'm happy to remove the -2 but I'm not
> yet convinced.
> 
There's a long way until the set of changes gets to where I envision it.
The patches you so hastily rushed to block are probably the quarter marker.
The idea of compiling a microcode_blob.c, so that we may later pass it
through the linker, only to then objcopy the .data section, is broken.
It's unnecessarily complex. It's better to just save the microcode
updates as binary files (in blobs repo), then cat >> them together. It's
also a micro-optimization for abuild.

Or would you rather hear all this from someone clueless, who will
understand nothing of what I just said, and who will also demand that
you make these changes?


> ron
>

Oh, did I mention we should enable blobs by default?