lkml.org 
[lkml]   [2003]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: RFC: changes to microcode update driver.
> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:2.654 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site