On Wed, Jul 10, 2013 at 09:37:11AM +0200, Harald Hoyer wrote: > On 07/10/2013 02:29 AM, Yu, Fenghua wrote: > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx] > >> Sent: Tuesday, July 09, 2013 12:24 PM > >> Implement it per Linux kernel Documentation/x86/early-microcode.txt > >> (from v3.11-rc0): > [...] > > This patch works fine with one microcode blob in binary format. There are situations that the microcode is not delivered in one blob in binary format: > > > > First, each microcode patch is one file instead all microcode patches are in one big blob. Secondly, old delivered microcode file is in ascii format. > > > > To handle those formats, additional code needs to convert the formats into one big binary microcode blob. I'm not sure if we should consider the code and if we should put the code in dracut. > > > > Thanks. > > > > -Fenghua > > > > > $ ls /lib/firmware/amd-ucode > microcode_amd.bin microcode_amd_fam15h.bin microcode_amd_solaris.bin Right, so all of those blobs (for AMD) get stuck in AuthenticAMD.bin. > $ ls /lib/firmware/intel-ucode > 06-03-02 06-06-00 06-07-02 06-08-0a 06-0b-04 06-0f-06 06-16-01 06-1c-02 > 06-25-02 06-2d-07 0f-01-02 0f-02-09 0f-04-03 0f-04-0a > 06-05-00 06-06-05 06-07-03 06-09-05 06-0d-06 06-0f-07 06-17-06 06-1c-0a > 06-25-05 06-2f-02 0f-02-04 0f-03-02 0f-04-04 0f-06-02 > 06-05-01 06-06-0a 06-08-01 06-0a-00 06-0e-08 06-0f-0a 06-17-07 06-1d-01 > 06-26-01 06-3a-09 0f-02-05 0f-03-03 0f-04-07 0f-06-04 > 06-05-02 06-06-0d 06-08-03 06-0a-01 06-0e-0c 06-0f-0b 06-17-0a 06-1e-04 > 06-2a-07 0f-00-07 0f-02-06 0f-03-04 0f-04-08 0f-06-05 > 06-05-03 06-07-01 06-08-06 06-0b-01 06-0f-02 06-0f-0d 06-1a-04 06-1e-05 > 06-2d-06 0f-00-0a 0f-02-07 0f-04-01 0f-04-09 0f-06-08 And all of those get catted in GenuineIntel.bin. > > Also, for [[ $hostonly ]], we only want to add the current running CPU microcode. <nods> Will do that. Are you OK with me adding some of this CPU detection logic in dracut-functions.sh? > > Also, why does it have to be a separate cpio? Doesn't it work, if the files are > in the normal, single initramfs? It does not in 99%. The restriction is that it MUST be an uncompressed cpio. The code that handles the loading is at the start of the kernel so it does not have the uncompression logic built-in. I think your next question is going to be - if we are passed in '--no-compress' then we could stash the kernel/x86/microcode directory in the initramfs? That should work. -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
