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.
next prev 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.