There's a knob. It's called 'microcode updates'. If you set the knob to 'offf' the firmware image you build, and boot, may let the CPU do very bad things to you, in unpredictable ways, at unpredictable times, including (on some CPUs) cause very difficult to detect data corruption because (on some CPUs) there are issues with behavior of shared cache lines or the data path to memory.
The best part? The CPU may behave very well, 999,999,999 times out of 1000000000. It's that last misbehaving time that's going to bite you.
Don't believe me? How about this. I just typed microcode update xeon errata for the heck of it and: "Intel has discovered an erratum with Dual-Core Intel Xeon 5200-series and Quad-Core Intel Xeon 5400-series processors. The potential for this issue to occur does not apply when using Dual-Core Intel Xeon 5000-series, Dual-Core Intel Xeon 5100-series, or Quad-Core Intel Xeon 5300-series processors.
The issue is documented in an updated version of the Intel Processor Specification Update for all affected processors. For additional details regarding the Intel microcode update, reference Errata AX52 (5400-series processors) or Errata AY52 (5200-series processors) in the appropriate Intel Processor Specification Update on the Intel website at the following URL:http://www.intel.com/products/proces...cation_updates
The issue can lead to server hang/reboot and it has been observed to have this effect in recent AppLogic releases. The fix is to have the BIOS of servers using these processors upgraded to a version that resolves these errata."
See those three litle words: "intel microcode update". Oh, and how about "server hang/reboot". Gee, I can build in a 'more free' way if I'm willing to have the occasional hang or reboot. Terrific.
People have ideas about 'free is good, so turning off microcode updates, since it makes the code more free, must be good too'. And that's just plain wrong.
I can't see any redeeming value to the idea of moving the microcode updates into blobs. The point of blobs, when we created it, was to have a place to put things we can't put directly in the coreboot repo. It was never intended to be a destination for things already in the repo. You're misreading the intent of that directory.
And I think it even worse to put the microcode blobs in a location in the tree that implies, by its existence, that you can build without them and get a more free, working firmware image.
That's why I'm so unhappy with this change. I think it's a mistake.
ron