Hi,
Please try with CONFIG_FSP_M_XIP=y
I guess you are splitting the Fsp.fd file(python SplitFspBin.py split -f FSP_M.fd).
If so you can verify FSP_M.fd containing the signature.( hexdump -C FSP_M.fd | less ) Look for KBLUPD_M. I found it at offset 0x5a6cc.
Consider using config.kblrvp as reference : https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/r...
Regards, Naresh
On Sat, Nov 4, 2017 at 11:25 PM, Nico Huber nico.h@gmx.de wrote:
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
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot