> I know very little about it really. It may well be potentially bad to simply use the latest version,> but in case it's really only because nobody did it, I might prepare a patch to use>
downloadmirror.intel.com/27337/eng/microcode-20171117.tgz instead (someday, after> I testing it on my device).
To understand what is really going on, I did the following investigation on my only coreboot clone version,
I have on my current SSD the following: WIN10, using VMware® Workstation 12 Player, version 12.5.8 build-7098237
with Fedora 26 VM, where the coreboot is located.
CLI transcript follows:
[user@localhost coreboot]$ pwd
/home/user/projects/coreboot/coreboot
[user@localhost coreboot]$ git describe
4.5-1006-gef7e98a2ac
[user@localhost coreboot]$ grep -r 20150121 *
3rdparty/blobs/cpu/intel/microcode/update-microcodes.sh:MICROCODE_VERSION=20150121
[user@localhost coreboot]$ cd 3rdparty/blobs/cpu/intel/microcode
[user@localhost microcode]$ ls -al
total 24
drwxrwxr-x. 2 user user 12288 Nov 21 12:27 .
drwxrwxr-x. 24 user user 4096 Feb 18 2017 ..
-rwxrwxr-x. 1 user user 1782 Feb 18 2017 microcode2bin.sh
-rwxrwxr-x. 1 user user 2989 Nov 21 12:27 update-microcodes.sh
[user@localhost microcode]$ tail -10 update-microcodes.sh
}
get_microcode
separate_microcode
move_microcode
dump_cpuids <<=========================== I added this line of code to see which CPUIDs's MCUs are added here:
rm -f $MICROCODE_ARCHIVE
rm -f $MICROCODE_FILE
[user@localhost microcode]$
Now, you can substitute 20150121.tgz
with 20171117.tgz in bash shell script
update-microcodes.sh and see what will happen?!
I somehow hope this exercise is helpful.
Zoran