Removing microcode updates from blobs

[mrnuke]

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.

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+to...

Intel branch (ready for review):
http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...

AMD branch (ready for review/needslove):
http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...

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...

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+to...

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

Moving microcode updates from main to blobs

[mrnuke]

There, I fixed the title.

On 12/13/2013 05:48 PM, mrnuke 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.
>
> 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+to...
>
> Intel branch (ready for review):
> http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
>
> AMD branch (ready for review/needslove):
> http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
>
> 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...
>
> 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+to...
>
> 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

[Scott Duplichan]

mrnuke [mailto:[e-mail]] 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+to...
]
]Intel branch (ready for review):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
]
]AMD branch (ready for review/needslove):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
]
]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...
]
]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+to...

]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

[ron minnich]

Scott, I don't see the point of this change either.

In the beginning, we had no microcode in coreboot, per the main goal:
let linux do it. We just let Linux do the update. Not our problem.

At some point, ca. 2005 or so, we had to let the blobs in because many
of the new CPUs are *broken* without the microcode update: the
microcode that comes embedded in the CPU must be updated or you'll get
some real problems, and possibly not even get through firmware.

As you point out, this is nothing like the VGA BIOS issue.

So, sure, it's pure to build without the microcode blob, which means
in reality that you're deciding to use the microcode blob *already
embedded in the CPU*. And, on many new CPUs, the one that comes with
the CPU has issues that mean you won't get past DRAM init. And, if you
do get past DRAM init and boot, you've got a CPU that may have subtle
errors and corrupt memory. Oh, joy.

I guess I don't understand why people feel better being able to build
a firmware image which will boot the CPU in a broken mode.

ron

[Stefan Reinauer]

Hi Alex,

thanks for this effort. Without having looked at the patches yet, I
think moving microcode into 3rdparty / blobs.git is the right way to
go. This is one of the (my) original intentions of having CBFS to begin
with.

Stefan

* mrnuke  [131214 00:48]:
> 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.
>
> 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+to...
>
> Intel branch (ready for review):
> http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
>
> AMD branch (ready for review/needslove):
> http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+to...
>
> 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...
>
> 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+to...
>
> 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