And if you ask Intel employees about it, they just ignore you.
In 99,9% of cases, asking INTEL employees about anything is just pure waste of the time and effort!
IMHO!
Zoran
On Tue, Nov 21, 2017 at 7:33 PM, Nico Huber nico.h@gmx.de wrote:
Hi Martin,
On 21.11.2017 09:31, Martin Kepplinger wrote:
Since there are many releases of Intel's cpu microcode since 2015-01, I was wondering if there's a reason why coreboot, if at all, uses this one.
the explanation might be a simple one, e.g. the last person who tried to update it, didn't know the new package exists at all. I bet that's true for 99% of the coreboot community.
Last time I checked for microcode updates (for Skylake) I had to click through a license at intel.com and promise not to redistribute it! And if you ask Intel employees about it, they just ignore you. So I'm overly pleased to see your link ;) thank you very much! Please tell us, for future reference, how you found it.
Now if you also tell us that it comes with a license that allows redris- tribution, that would be like an early Christmas xD That we don't have the (mandatory!) updates for current Intel processors in our blobs repo- sitory is one of the big bummers that make the upstream coreboot ex- perience suck.
I know very little about it really. It may well be potentially bad to simply use the latest version,
No, it's considered to be the best thing to use the latest updates.
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).
Please do so. Though, the `update-microcodes.sh` doesn't fit the binary format in the new package any more. I guess it can be replaced with a simpler script, e.g.
for f in ??-??-??; do model=$(echo $f | sed -e's/\(0.\)-\(.\)\(.\)-0./0x\2\1\3/') dir=$(printf "model_%xx\n" $model) mkdir -p $dir cat $f >>$dir/microcode.bin doneBest, Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot