RE: RFC: changes to microcode update driver.

Maciej Zenczykowski
2003-10-07T15:58:46Z

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