Messages in this thread | | | Subject | Re: Intel Microcode loader, tg3 driver, and the -rc8-mmotd New World Order firmware... | From | David Woodhouse <> | Date | Thu, 03 Jul 2008 16:54:25 +0100 |
| |
On Thu, 2008-07-03 at 06:56 -0700, Arjan van de Ven wrote: > On Thu, 03 Jul 2008 11:24:34 +0200 > "Giacomo A. Catenazzi" <cate@debian.org> wrote: > > > There are two format of Intel CPU microcode and two methods to load > > it. > > - old: the microcodes are in a big file, which include multiple > > microcodes (for multiple CPU). The driver require a char device > > and a user space loader ("microcode_ctl") > > - new: one microcode per file, using the 'request_firmware' > > infrastructure. No user space support needed.
Actually there are three:
1. The text format 'microcode.dat', including updates for all CPUs. 2. The binary format output by microcode_ctl, still including all CPUs. 3. The smaller files with just the relevant subset of #2.
The kernel (since 2006) can actually take either #2 or #3. The udev scripts I just posted will use microcode_ctl to feed it #2, when they find #1 on the file system.
A small amount of extra work in the userspace tool would let those udev scripts feed #3 to the kernel, and then the code in the kernel to select the appropriate update could be removed.
> > Actually Intel provides only the old methods. > > There was talks with Arjan and Intel about the distribution format > > for the new methods. But I don't have any new. > > I think that when the new format is fully specified (directory > > structure, tar, gzip,...) Intel will distribute the microcodes > > in the new form.
Doesn't the "new format" (#3) involve hard links too, since there are some cases where the same microcode update applies to more than one CPU revision?
> we hope to switch to the new form but there's the small case of > "installed base" using ancient kernels, and it's kind of not nice to > have to release 2 sets. At some point we will switch over though.
Do we really need to _ship_ it in a different form? It's not exactly hard to convert from the text form (#1) to either of the other two -- either on the fly in udev scripts, or at installation time.
-- dwmw2
| |