On 12/14/2013 12:59 AM, ron minnich wrote:
On Fri, Dec 13, 2013 at 10:46 PM, mrnuke mr.nuke.me@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?