| 1 |
On Wednesday 01 Feb 2017 00:55:01 Marc Joliet wrote: |
| 2 |
> On Sunday 29 January 2017 13:51:39 Mick wrote: |
| 3 |
> > Hi All, |
| 4 |
> > |
| 5 |
> > I am trying out a systemd installation on a MackBook Pro and I am not sure |
| 6 |
> > the documentation on systemd + microcode is entirely correct. So, I read |
| 7 |
> > here: |
| 8 |
> > |
| 9 |
> > https://wiki.gentoo.org/wiki/Intel_microcode#systemd |
| 10 |
> > |
| 11 |
> > that the "microcode loader is set as a module in the kernel |
| 12 |
> > configuration". |
| 13 |
> > However, my kernel configuration is not offering this option. Both 'CPU |
| 14 |
> > microcode loading support' and 'Intel microcode loading support' can only |
| 15 |
> > be set as built in elements. I am not using an initramfs (yet) so I |
| 16 |
> > wonder how I should go about this. |
| 17 |
> |
| 18 |
> AIUI these days the microcode is supposed to be put in the initramfs and |
| 19 |
> loaded from there during early boot (I read this somewhere, but don't |
| 20 |
> remember where). Dracut takes care of this, e.g., the initramfs on my |
| 21 |
> laptop contains a microcode blob: |
| 22 |
> |
| 23 |
> # lsinitrd /boot/initramfs-4.9.6-gentoo.img|grep -i micro |
| 24 |
> drwxr-xr-x 1 root root 0 Jan 27 01:14 kernel/x86/microcode |
| 25 |
> -rw-r--r-- 1 root root 983040 Jan 27 01:14 |
| 26 |
> kernel/x86/microcode/GenuineIntel.bin |
| 27 |
> |
| 28 |
> The third journal entry on said laptop is then: |
| 29 |
> |
| 30 |
> Jan 30 20:42:17 localhost kernel: microcode: microcode updated early to |
| 31 |
> revision 0x4, date = 2013-06-28 |
| 32 |
> |
| 33 |
> So it looks to me like the kernel loads it autonomously, and the reason to |
| 34 |
> put the file in the initramfs is for the microcode to get updated as early |
| 35 |
> as possible (before the kernel has to read from disk). |
| 36 |
> |
| 37 |
> HTH |
| 38 |
|
| 39 |
I eventually got on top of this. No initramfs is needed, although if you are |
| 40 |
using one then it will serve the same purpose too. |
| 41 |
|
| 42 |
These are the steps I followed: |
| 43 |
|
| 44 |
Emerged sys-apps/iucode_tool and ran: |
| 45 |
|
| 46 |
iucode_tool -S |
| 47 |
|
| 48 |
which spewed out the CPU signature as: 0x00040661 |
| 49 |
|
| 50 |
Then I emerged intel-microcode with USE=split-ucode, to generate the microcode |
| 51 |
binaries the kernel can use directly. Saving and searching through the output |
| 52 |
of the emerge compilation I found this snippet: |
| 53 |
|
| 54 |
intel-ucode/06-46-01 |
| 55 |
signature: 0x40661 <===< |
| 56 |
flags: 0x32 |
| 57 |
revision: 0x16 |
| 58 |
date: 2016-04-01 |
| 59 |
size: 24576 |
| 60 |
|
| 61 |
Previously in a rush, I got confused when I compared the hex notation of the |
| 62 |
CPU signature with 0x000 in front of it, with the above. Thereafter I added |
| 63 |
'intel-ucode/06-46-01' in the kernel, like so: |
| 64 |
|
| 65 |
Device Drivers ---> |
| 66 |
Generic Driver Options ---> |
| 67 |
[*] Include in-kernel firmware blobs in kernel binary |
| 68 |
(intel-ucode/06-46-01 <other_CPU_firmware_follows_here>) External firmware |
| 69 |
blobs to build into the kernel binary |
| 70 |
(/lib/firmware/) Firmware blobs root directory |
| 71 |
|
| 72 |
The intel-ucode needs to be loaded early at the start of the boot process, so |
| 73 |
I put it first and comma separated the rest of the CPU firmware blobs. I now |
| 74 |
get an output which clearly states "microcode updated early". |
| 75 |
|
| 76 |
I posted this in case it helps others too. |
| 77 |
-- |
| 78 |
Regards, |
| 79 |
Mick |
Archives