[coreboot] Removing microcode updates from blobs

[Scott Duplichan]

mrnuke [mailto:mr.nuke.me at gmail.com] wrote:

]Hi all,
]
]Following some recent discussions on IRC, we've see that some people
]just don't like us shipping microcode in the main repository. OK,
]microcode is a blob, so it belongs in blobs. Let's leave that at that.

De-blobing agesa is going to be a pain. I have seen these microcode
discussions here from time to time and never understood the concern.
There is no concern about the SMU binaries embedded in agesa, and
there is no concern about RD890 firmware either. Just microcode. I
understand the objection to lack of source code for something like
video option ROMS. With video option ROM source code, we could easily
modify the familiar x86 code to add customizations for improvements
such as boot time reduction. But the same is not true for microcode.
There is no reasonable expectation that the open source community 
could make meaningful improvements or bug fixes to a processor without
having the processor source code, internal docs, and access to the
processor designers. Even if I am wrong, there is still the problem
of the private encryption key needed to sign the patch. It is unlikely
Intel and AMD are going to reverse their policy of encrypting 
microcode patches. We choose to purchase processors without source
code then complain about lack of source code for their updates. I
understand the objection to putting binary data into source control.
It bloats the archive and does not produce meaningful diff output.
But the microcode size is fairly small when compared to a large
module like agesa. AMD tries to make agesa so that it can be used
without modification. That way updates can drop in easily. Pulling
out the microcode or other binary parts is going to defeat that. I
hope the idea of letting the agesa SMU, NB, and microcode stay where
they are will be considered.
Thanks,
Scott
 
]Kyösti and I are working on making all CPUs update microcode from CBFS.
]This is the first step in moving the microcode updates out of main. Our
]branches are already up on gerrit:
]
]Infrastructure (ready for review):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:microcod]e-cbfs/infrastructure,n,z
]
]Intel branch (ready for review):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:microcod]e-cbfs,n,z
]
]AMD branch (ready for review/needslove):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:microcod]e-amd,n,z
]
]I've also started integrating the microcode updates for Intel CPUs in
]blobs. The branch is here (ready for review):
]http://review.coreboot.org/#/q/status:open+project:blobs+branch:master+topic:microcode-]deblob,n,z
]
]Once ALL that is done, we can start removing those updates from master
](needslove):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:microcod]e-deblob,n,z

]This last branch is a WIP, but we should be able to have it build via
]Jenkins once all the other Intel stuff is done.
]
]And once ALL that is done, we'll be able to update Kconfig such that
]microcode is only included automatically when the blobs repository is
]enabled. This separation of blobs versus free code is only logical, and
]the end result is more options for the user.
]
]Reviews and testers highly appreciated. Let's get this done once and for
]all. Remember, this is a multi-step process with changes that are, sadly
]not trivial to keep track of.
]
]Alex