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
That's not enough. The integers in the url of https://review.coreboot.org/cgit/blobs.git/tree/cpu/intel/mi
crocode/update-microcodes.sh#n24
change aswell, not just MICROCODE_VERSION.
I am empirical/practical guy, mit wenig Zeit (zu viele Dinge zu tun), dann ich sole super schnell Denken machen (taking some German practice as well, I must, it is bad).
I see some of earlier MCU packet downloads, so these are the following:
[image: Inline image 1]
As we all in Coreboot now see (attn: Martin, Patrick, Ron, Stefan), the latest and greatest you pointed to should be taken and implemented. It is, (Mein Gott), ~ 4,5x size of old currently used (20150121), so, my best guess, action is here needed on behalf of above mentioned people (to enrich Coreboot MCU database).
So if you're suggesting that a download fails, that's not the issue.
NOPE! I did/do not suggest that (it is, maybe, language limitation, I feel all the time in German). I suggest to add the 4th I/F (*dump_cpuids*) in the update-microcodes.sh_ bash.
Then, the following file I got from it on 20150121 (attached to this email dump_cpuids.txt).
Furthermore, since you are targeting Haswell, luckily enough, my HP EliteBook 840 G1 is based upon i3-4300U Haswell. What do I have here?
This:
[user@localhost microcode]$ uname -r 4.13.13-200.fc26.x86_64 [user@localhost microcode]$ dmesg | grep i5 *[ 0.100550] smpboot: CPU0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz (family: 0x6, model: 0x45, stepping: 0x1)* [user@localhost microcode]$
This is CPUID 0x40651 (I know this by heart, no questions asked)! ;-)
Now, if you search the file on 40651 I have created and attached on this email, you'll get the following:
Model: 40651(4065x) Microcode: microcode-m7240651_0000001c.h (copied)
I guess, for one, who is smart, I gave even redundant info. ;-)
Good Luck, Zoran Stojsavljevic
PS. Please, google what MCU is (Micro Code Unit and purpose of it), I am too lazy to write about it! _______
On Tue, Nov 21, 2017 at 1:48 PM, Martin Kepplinger martink@posteo.de wrote:
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/mi crocode/update-microcodes.sh#n24 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
-
Martin Kepplinger -
Zoran Stojsavljevic