RE: RFC: changes to microcode update driver.

[Tigran Aivazian <tigran@veritas.com>]

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