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

[Naresh G. Solanki]

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 <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>