RE: RFC: changes to microcode update driver.

Tigran Aivazian
2003-10-07T16:03:27Z

On Tue, 7 Oct 2003, Maciej Zenczykowski wrote:

> > As Tigran pointed out, we are active in this area too. At this point we
> > want to add support of the extended update format to the driver, before
> > we ship the latest microcode data. Some of them require the new format.
>
> Do we even have any use for a userspace utility anymore?
> strace'ing the microcode_ctl -u process results in information that the
~~~~~~~~~~

If you read the code instead of stracing you would have discovered that
there is a little (i.e. undocummented :) switch to do everything you
described below.

As for compiling the microcode data into the kernel (as scsi firmware etc)
I recall that Alan Cox said we are moving away from that sort of thing,
so it's not a good idea.

Kind regards.
Tigran

> microcode.dat file is converted to binary and written to
> /dev/cpu/microcode. The following code:
> #include <stdio.h>
> int main (void) {
> int x[4], i;
> while ((i = scanf("%x, %x, %x, %x,\n", &x[0], &x[1], &x[2], &x[3])) > 0)
> fwrite(x, 4, i, stdout);
> return 0;
> };
> does the conversion to binary:
> cat /etc/microcode.dat | grep -v "^/" | ./a.out > microcode.raw
> and the following loads it:
> dd bs=`ls -s --block-size=1 microcode.raw | cut -f 1 -d " "`
> if=microcode.raw of=/dev/cpu/microcode
>
> Either distribute the microcode in binary form and load it via dd (in the
> /etc/rc.d/init.d/microcode script)
> or include the text file parser in the microcode module - since the module
> is only needed during loading of the update this tiny amount of extra code
> is likely acceptable. For reducing kernel size for embedded systems (any
> based on ia32 lacking the few kb?) try compiling the 2kb update relevant
> for the given processor directly into the kernel...
>
> Just a few ideas...
>
> MaZe.
>
>