Hi,
On 04.11.2017 17:18, Jay Talbott wrote:
I added a post code as part of the if to confirm that the signature mis-match was where the code was hanging. So I'm 100% certain that the mis-match exists with this particular FSP. Also, although the signature is the same, there are a few other differences between the header files included with the FSP and those currently in coreboot, but nothing that would seemingly account for this issue.
coreboot likely is just looking at the wrong offset. Try what Matt suggested, enable XIP. IIRC, it was necessary but I never looked into it. (Kconfig options for FSP are a mess, often only one value for an option works, sometimes it's not the default. Some ppl working on core- boot for Intel don't understand the concept of options.)
Note that this particular FSP release on GitHub does NOT include any release notes to indicate for which SkyLake/Kaby Lake variants (-H, -U, -Y, etc.) it is applicable,
I've never seen FSP release notes that indicate it. FSP releases are rather undocumented. The idea seems to be to hide as much as possible and they succeeded: The UPDs of FSP are less documented than the regis- ters it sets.
but someone from Intel suggested that it's only applicable to -H.
I was told it would be working for -S, -H, -U and -Y, and it likely is. Maybe that someone meant it's only validated for -H?
If that's the case, then how was the RVP7 support ever validated prior to integration into the coreboot tree? Which FSP was actually used? And does that even have anything to do with the signature mis-match issue? Nobody seems to know.
They (Intel/OEMs/ODMs/IBVs) use a completely different line of binaries that only get published as part of their device' firmware. The interes- ting part: If you are a member of the club, you likely also have access to the FSP sources and don't need documentation that much.
I've been trying to get support on this through various channels at Intel that so far have not been particularly helpful, and it's extremely frustrating. I've sent several e-mails to various folks, including the individual that upstreamed the RVP7 support to coreboot and the individual who published the FSP to GitHub, which remain unanswered.
Heh, welcome to (Intel based) coreboot. I just went through the same pain, without success. We ended up with weird workarounds because what Intel delivers lacks any sense of firmware security. Not sure if we'll end up sandboxing or rewriting FSP. (If I'd do the latter it likely won't be GPL code. Pairing that one with blobs obviously failed the project.)
Nico