All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
To: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "Yu,
	Fenghua" <fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC v1] dracut.sh: Support early microcode loading.
Date: Wed, 10 Jul 2013 10:58:15 -0400	[thread overview]
Message-ID: <20130710145815.GD11007@phenom.dumpdata.com> (raw)
In-Reply-To: <51DD0F27.70202-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org]
> >> 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.

  parent reply	other threads:[~2013-07-10 14:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-09 19:24 [RFC v1] dracut.sh: Support early microcode loading Konrad Rzeszutek Wilk
     [not found] ` <1373397849-11397-1-git-send-email-konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2013-07-10  0:29   ` Yu, Fenghua
     [not found]     ` <3E5A0FA7E9CA944F9D5414FEC6C712205A528195-P5GAC/sN6hlZtRGVdHMbwrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2013-07-10  7:37       ` Harald Hoyer
     [not found]         ` <51DD0F27.70202-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-10 14:58           ` Konrad Rzeszutek Wilk [this message]
     [not found]             ` <20130710145815.GD11007-6K5HmflnPlqSPmnEAIUT9EEOCMrvLtNR@public.gmane.org>
2013-07-12 21:02               ` Konrad Rzeszutek Wilk
     [not found]                 ` <20130712210254.GA26664-6K5HmflnPlqSPmnEAIUT9EEOCMrvLtNR@public.gmane.org>
2013-07-17 12:40                   ` Harald Hoyer
     [not found]                     ` <51E690C1.5010004-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-17 17:20                       ` Konrad Rzeszutek Wilk
2013-07-10 11:13       ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130710145815.GD11007@phenom.dumpdata.com \
    --to=konrad.wilk-qhclzuegtsvqt0dzr+alfa@public.gmane.org \
    --cc=fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.