Messages in this thread | | | Subject | Re: Intel Microcode loader, tg3 driver, and the -rc8-mmotd New World Order firmware... | From | David Woodhouse <> | Date | Thu, 03 Jul 2008 11:42:56 +0100 |
| |
On Thu, 2008-07-03 at 12:22 +0200, Kay Sievers wrote: > So, maybe a: > # rewrite firmware file name to all-in-one Intel CPU microcode data file > SUBSYSTEM=="firmware", ENV{FIRMWARE}=="intel-ucode/*", ENV{FIRMWARE}="intel-ucode/microcode.dat" > would be enough?
Nah, it needs the binary form. The actual 'microcode.dat' just looks like this...
0x00000001, 0x00000013, 0x02062001, 0x00000683, 0x2f0da1b0, 0x00000001, 0x00000001, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0xbf5ad468, 0xc79f5237, 0xbd53889e, 0x896bfd13, 0x7adc0c8f, 0x44e9e0bc, 0x1a331fc9, 0x00b0f479,
That's all microcode_ctl actually does; read in the text file and output the (complete) binary. Hence: /sbin/microcode_ctl -f "$DIR/microcode.dat" -d /sys$DEVPATH/data
At a later date, we could make userspace output only the part for the desired CPU, and rip out the kernel-side code which searches for it within the big blob. That was presumably the intention in the commit which changed things. But then again, the kernel-side code still needs to do a certain amount of sanity checking on what it receives -- so I'm not sure we gain a huge amount by trying to remove that functionality from the kernel (not that I've looked hard at the line count).
If we're _not_ going to make userspace provide only what's required, and we keep the selection code in the kernel, then I don't see the point in having separate firmware filenames for different cpus. We could just change the driver to call request_firmware("intel-microcode.bin") and do this one-off conversion: touch /lib/firmware/intel-microcode.bin microcode_ctl -d /lib/firmware/intel-microcode.bin
-- dwmw2
| |