Messages in this thread | | | Date | Tue, 7 Oct 2003 17:56:30 +0200 (CEST) | From | Maciej Zenczykowski <> | Subject | RE: 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/
| |