On 12/14/2013 12:59 AM, ron minnich wrote:
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.
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?
-
mrnuke