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:30:29 +0100 |
| |
On Thu, 2008-07-03 at 06:17 -0400, Valdis.Kletnieks@vt.edu wrote: > On Thu, 03 Jul 2008 10:23:48 BST, David Woodhouse said: > > > The recent firmware changes haven't modified this. The important change > > seems to have been here (in 2006): > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a30a6a2c > > Aha. That's the part I was missing. :) > > From the changelog for that commit, Shaohua Li wrote: > > "with the changes, we should put all intel-ucode/xx-xx-xx microcode files > into the firmware dir (I had a tool to split previous big data file into > small one and later we will release new style data file). The init script > should be changed to ..." > > And apparently I got stuck between the unreleased tool to split the file, > and the release of the new style data file.
That 'new style' data file is just the binary output of the microcode_ctl tool. The kernel is still capable of finding the section it requires, when fed the whole blob.
> Anyhow, it appears the firmware_request() was just a bullet loaded in the > chamber waiting for me to pull the trigger 2 years later by setting > CONFIG_FIRMWARE_IN_KERNEL=n :)
No, the recent firmware changes haven't modified this. The FIRMWARE_IN_KERNEL option makes no difference here.
> The behavior is explained, and presumably Intel will eventually release > a method of getting the new-format bits, and all will be right with the > world (or at least this part of it.. ;)
Some would say that Intel already released a method for making it work, in the form of the email to which you're replying... does that udev configuration not work for you?
-- dwmw2
| |