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/+/refs/heads/master/sys-boot/coreboot/files/configs/config.kblrvp Regards, Naresh On Sat, Nov 4, 2017 at 11:25 PM, Nico Huber <[email protected]> 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: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot > -- -------- * ---------------* ----------------* ----------- *-------------------------------------- ------- --------- -------------- ------- ------ -------------- ------- - ---- -------------- ------- ---- - -------------- ------- ------ --------------- ------- -------- --------------- --------------------------------------*
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
