[coreboot] Exception on Skylake after enabling ACPI timer emulation

Youness Alaoui kakaroto at kakaroto.homelinux.net
Fri May 18 19:53:05 CEST 2018


Hi Piotr,

The Librems use the FSP 2.0 for SKL because I was told (I can't
remember by who, but I think it was on coreboot IRC channel) that the
FSP 2.0 works for both Skylake and Kabylake and that FSP 2.0 was
better supported within coreboot than FSP 1.1. We had the Librems use
FSP 1.1 before, but when we upgraded from coreboot 4.6 to coreboot
4.7, we also upgraded to using FSP 2.0 (as you can see in our
changelog : https://code.puri.sm/kakaroto/coreboot-files/src/master/Changelog.txt)
It wasn't particularly straightforward because of two issues :
1 - the FSP 2.0 headers in coreboot do not match the FSP 2.0 header
from the public github binaries. You can see our patch to fix it here
: https://review.coreboot.org/26108 (once coreboot.org maintenance is
done).
2 - the FSP 2.0 doesn't set the AC and DC Lodline values, so you need
to set those manually in devicetree.cb otherwise the CPU will have a
tendency to overheat under load within a few milliseconds then
shutdown (see patch here : https://review.coreboot.org/25324 )

Other than that, the FSP 2.0 has been working great for our SKL
platform. I don't remember specifics, but I believe it was a lot less
trouble and fixed issues from when we were using the FSP 1.1.

I also can't find any information on MSR 0x121 anywhere, but I can
confirm that it has the expected value that coreboot sets :
root at librem13:~# rdmsr 0x121
2fba2e2501311808

>From the crash though, I doubt your problem is the FSP, because it's a
crash on doing the 'wrmsr' instruction, probably because your CPU
doesn't recognize that MSR as being valid or something like that.

Here's my librem13v2 info as reported by coreboot :
CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
CPU: ID 406e3, Skylake D0, ucode: 000000c1
CPU: AES supported, TXT NOT supported, VT supported
MCH: device id 1904 (rev 08) is Skylake-U
PCH: device id 9d48 (rev 21) is Skylake-U Premium
IGD: device id 1916 (rev 07) is Skylake ULT GT2

So I can see that we have the exact same CPU, MCH, PCH and IGD, but
there is one difference that I noticed, your line said :
CPU: ID 406e3, Skylake D0, ucode: 00000000

It looks like you haven't set a microcode for the CPU, and I think
that might be your actual problem. I remember being unable to boot the
machine without a microcode update, but I think it was because the FSP
itself would crash/refuse to boot if one wasn't set, so the very first
thing I did was to add the microcode update to coreboot and consider
it "on skylake and above, you can't boot without a valid microcode
update". In your case, that looks like that might be your problem. It
might be that the 0x121 MSR didn't exist or wasn't valid in the
default CPU ucode, and is only valid (or can only be set) after the
ucode update is applied, so I suggest you first try that, and see if
it solves any of your issues.

Good luck!
Youness.

On Fri, May 18, 2018 at 1:31 PM, Nico Huber <nico.h at gmx.de> wrote:
> Hello Piotr,
>
> On 17.05.2018 18:20, Banik, Subrata wrote:
>>>> FSP2.0, I'm following Librem Purism options since they seem to boot the
>>>> same SoC. They use KabyLake FSP obtained by get_blobss.sh [1], if you
>>>> think this is incorrect then I would like to know why, because it may
>>>> mean that Pursim code is also incorrect from Intel point of view.
>>
>> SKL won't be compatible with KBL FSP. Please don’t try to use KBL FSP
>> and mix match with SKL Coreboot. No one tested that combination.
>
> Unless FSP is calling home, we can't say anything about the actual test
> coverage. KBL FSP somehow works on SKL. I assume the code is written for
> both platforms, the binaries are usually just not validated for all SKUs
> supported by the code (and it's often not documented for which they were
> validated).
>
> I wouldn't be surprised if the KBL FSP was more tested on SKL by now;
> not by Intel but by their customers and individuals. There's one simple
> reason: The older SKL FSP lacks most of the configuration options and
> is not well maintained within coreboot. So the KBL FSP works better (but
> you don't get any guarantee for that). OTOH, the KBL FSP release on
> GitHub is also not well integrated (although it was released half a year
> later, it's way behind regarding the header files in coreboot). The only
> Kabylake FSP binary 100% compatible with coreboot is the Google Support
> Package (not published separately, but you can carve it out of their
> firmware images).
>
> To wrap it up, if you want a public FSP binary that was validated for
> SKL, you'll have to use the old FSP1.1 version; or push Intel to publish
> something new. I would talk to your Intel support contact in any case,
> sometimes binaries pop up that nobody knew about.
>
> Nico
>
> PS. I can confirm that the KabylakeFsp0001 drop from last summer works
>     with a 25W SKL-S CPU. Judging from the commit date, I also run it
>     with that MSR write applied.
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot



More information about the coreboot mailing list