Am 21.11.2017 12:42 schrieb Zoran Stojsavljevic:
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 [1]
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 [1].tgz in bash shell script update-microcodes.sh and see what will happen?!
That's not enough. The integers in the url of https://review.coreboot.org/cgit/blobs.git/tree/cpu/intel/microcode/update-m... change aswell, not just MICROCODE_VERSION.
So if you're suggesting that a download fails, that's not the issue.
But maybe I got you wrong. Anyways, I haven't tried to change and run it. I might. so...
thanks
martin