[coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB?

Naresh G. Solanki naresh.solanki.2011 at gmail.com
Sat Nov 4 19:21:20 CET 2017


Please try with CONFIG_FSP_M_XIP=y

I guess you are splitting the Fsp.fd file(python SplitFspBin.py split -f

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 :


On Sat, Nov 4, 2017 at 11:25 PM, Nico Huber <nico.h at 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 at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot


-------- * ---------------* ----------------* -----------

*-------------------------------------- -------    ---------
-------------- -------       ------    -------------- -------    -
----    -------------- -------    ----    -    -------------- -------
------      --------------- -------    --------    ---------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171104/fdf1bc78/attachment-0001.html>

More information about the coreboot mailing list