Bug#676921: ITP: amd64-microcode -- Processor microcode firmware for AMD CPUs
On Fri, 22 Jun 2012, Ben Hutchings wrote:
> On Sat, 2012-06-16 at 15:08 -0300, Henrique de Moraes Holschuh wrote:
> > On Tue, 12 Jun 2012, Daniel Baumann wrote:
> > > On 06/12/2012 06:04 PM, Henrique de Moraes Holschuh wrote:
> > > > I don't care as long as nobody is going to get in the way of an
> > > > urgency=high upload of firmware-nonfree to stable-proposed-updates or
> > > > stable-updates.
> > >
> > > there have been updates of firmware-* packages in the past and more
> > > recently for squeeze too, so i don't think that's a problem.
> > >
> > > > Well, the amd64-microcode has not cleared NEW yet. How should we proceed?
> > >
> > > in my personal opinion, i'd prefere having it integrated into
> > > firmware-nonfree. but it's not my call but the kernel team to decide.
> >
> > Ok, I've looked into firmware-nonfree.
> >
> > The intel and amd64 microcode packages are not simple static data-drop
> > packages (next upload of amd64-microcode will add the required postinst
> > bits).
> >
> > They have to:
> >
> > 1. Issue sysfs commands to refresh running microcode
>
> With a current kernel, udev will load the firmware just as for any other
> device.
Yes, it will. At boot. And only if the driver is modular. And only if
something specifically modprobes microcode, because it has no autoloading
support in kernel 3.2 and earlier (I think that support was to land in 3.5,
but it might already have landed in 3.4).
So, Microcode needs to be refreshed when you upgrade the data files, and
also when the driver is not modular (at least last time I tested it in a 3.0
kernel for Intel), and that requires postinst and initramfs specific magic
(quite a lot for Intel, nearly none for AMD).
Backporting the autoload code is not straigthforward. Adding
MODULE_FIRMWARE() to the amd microcode driver is trivial and I think we
should do it anyway. MODULE_FIRMWARE() is currently impossible for Intel
and unless we want to possibly deviate from upstream, there is no way we can
fix that right now.
> > and update the initramfs when updated/installed.
>
> firmware-nonfree can do that (some network drivers need firmware).
Is it amicable to special postinst code? If it is, it can take care of
amd64-microcode.
> > 2. Ensure that the microcode module and processor microcode will be added
> > to the initramfs.
>
> Can be done by initramfs-tools.
Yes, it can. But initramfs-tools has no specific code other than some NFS
stuff, so we would probably benefit from a firmware-cpu-tools or whatever,
which could drop the initramfs helper, dpkg triggers and helper scripts to
get things done for both amd and intel microcode.
I'd rather not duplicate this code for Intel and AMD, so it would need to
end up in a -common/-util package of some sort (or in intramfs-tools
directly, but I don't think that's a good idea): soon we will also need a
new type of hook to piggyback the microcode using a initramfs-like
container, either to the initramfs itself, or to the kernel image (I am not
clear on that detail yet), and the microcode will be loaded on the BSP very
very early, and on other cores BEFORE they're activated.
This functionality has not landed in the kernel yet, but since we do know it
is coming, we better make sure we will be able to take advantage of it
without too much packaging rework. A -common/-util package is probably best
for that, and I intend to upload something to that effort this weekend.
> > This doesn't integrate automatically with firmware-nonfree right now, and I
> > really don't have the time to add support to figure out everything in
> > firmware-nonfree and add these operations to firmware-nonfree right before
> > the freeze,
> [...]
>
> Why don't you upload your package somewhere I can look at it? So far I
> don't see any reason to add a new source package.
Here:
http://people.debian.org/~hmh/microcode/
as one cannot download from the NEW queue, where it is currently.
The -1 packages are lacking the postinst snippet to refresh microcode, as
that area was in flux over the last few days and I was actively
participating on the thread in LKML to make sure we got something sane for
userspace as the result.
I was going to add the code to -2, now that the new sysfs nodes are set. It
is in my laptop at home, and I can send it in later today.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: