Re: [PATCH V3 4/4] microcode/x86/amd: early microcode patch loading support for AMD

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Fri, 31 May 2013, Andreas Herrmann wrote:
> On Fri, May 31, 2013 at 01:26:49AM -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 30 May 2013, Jacob Shin wrote:
> > >  mkdir initrd
> > >  cd initrd
> > > -mkdir kernel
> > > -mkdir kernel/x86
> > > -mkdir kernel/x86/microcode
> > > -cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
> > > -find .|cpio -oc >../ucode.cpio
> > > +mkdir -p kernel/x86/microcode
> > > +cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin)
> > 
> > Can I just 
> > 'cat /lib/firmware/amd-ucode/*bin >kernel/x86/microcode/AuthenticAMD.bin' 
> > to get a valid microcode container for all amd processors?
> > 
> > The answer for Intel is "yes".  I sure hope it is the same for AMD...
> 
> No, this doesn't work for AMD.
> 
> The container file includes a header section with information how to
> map CPU F/M/S to microcode revisions provided with a container
> file. Concatenating several container files will not create an
> all-embracing header section.
> 
> More details were available on the amd64.org web pages.  But it seems
> that the web site is not available anymore ...

Well, this is a problem for userspace.  Maybe the easier solution would be
to make kernel/x86/microcode/AuthenticAMD a folder, and look for files there
with names we can derivate from the ones used by the firmware interface (or
even the same names)?

The early-initramfs API easily allows this to be implemented...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh