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.
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@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@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-
Nico Huber -
Youness Alaoui