[coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB?
Matt DeVillier
matt.devillier at gmail.com
Sat Nov 4 18:57:38 CET 2017
On Sat, Nov 4, 2017 at 12:48 PM, Jay Talbott <
JayTalbott at sysproconsulting.com> wrote:
> Hi Matt,
>
>
>
> I’ll try XIP and see what happens… but how would that impact the UPD
> signature?
>
>
>
> The signature is defined in coreboot/src/vendorcode/intel/
> fsp/fsp2_0/skykabylake/FspUpd.h, as well as in FspUpd.h in the headers
> included with the FSP on GitHub.
>
ok, but those signatures match for all three FSP segments (coreboot and
github) -- in fact, the FspUpd.h file is exactly the same between the two,
and I've verified that's what's in the blobs as well.
ref:
https://raw.githubusercontent.com/coreboot/coreboot/master/src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspUpd.h
https://raw.githubusercontent.com/IntelFsp/FSP/Kabylake/KabylakeFspBinPkg/Include/FspUpd.h
>
>
> - Jay
>
>
>
> Jay Talbott
> Principal Consulting Engineer
> SysPro Consulting, LLC
> 3057 E. Muirfield St.
> <https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gmail&source=g>
> Gilbert, AZ 85298
> <https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gmail&source=g>
> (480) 704-8045
> (480) 445-9895 (FAX)
> JayTalbott at sysproconsulting.com
>
> http://www.sysproconsulting.com
>
>
>
> *From:* Matt DeVillier [mailto:matt.devillier at gmail.com]
> *Sent:* Saturday, November 04, 2017 9:59 AM
> *To:* Jay Talbott
> *Cc:* Nico Huber; coreboot; Stefan Reinauer
>
> *Subject:* Re: [coreboot] Who has experience with the Intel RVP7 (or
> RVP15) CRB?
>
>
>
> On Sat, Nov 4, 2017 at 11:18 AM, Jay Talbott <JayTalbott at sysproconsulting.
> com> wrote:
>
> Ok, more details...
>
> I'm currently building Coreboot off the end of the master branch as of
> commit 43a285f983f6c29467d7f30f7e2b402926bd5c6f, but might back up to the
> commit where the RVP7 support was added to see if that helps:
> https://github.com/coreboot/coreboot/commit/2ed14f61d1a2976d0ebce59fcc67bd
> 61
> fce4100d
>
> I'm using the KBL FSP from GitHub:
> https://github.com/IntelFsp/FSP/tree/Kabylake/KabylakeFspBinPkg
>
> I got the SplitFspBin.py tool and split the FSP into its three separate
> components. And, eventually, found the right microcode files and made them
> into a binary blob using a modified version of the microcode2bin.sh script
> I
> found in the coreboot tree.
>
> My .config file (renamed as config.txt) is attached.
>
>
>
> you need to use the execute in place (XIP) option for FSP-M in your config
>
>
>
>
> Note that the signature in the Fsp_M binary UPD struct is what does not
> match what's in the corresponding FSP header file - and not just the header
> file in the coreboot tree, but the one published as part of the FSP package
> on GitHub. So something is definitely amiss here with this published FSP
> package.
>
>
>
> I'm not seeing any hardcoded signature value in FspmUpd.h (as there is in
> FSP 1.1) - can you point to a specific file/line number?
>
>
>
>
> I do not have the serial console working yet, so all I've had to go by are
> post codes, and the last post code I was getting was 0x34, which I tracked
> down to be a hardcoded (grr...) value at the beginning of
> do_fsp_memory_init() in file memory_init.c of the FSP 2.0 driver
> (./src/drivers/intel/fsp2_0)...
>
> static void do_fsp_memory_init(struct fsp_header *hdr, bool s3wake,
> const struct memranges *memmap)
> {
> uint32_t status;
> fsp_memory_init_fn fsp_raminit;
> FSPM_UPD fspm_upd, *upd;
> FSPM_ARCH_UPD *arch_upd;
> uint32_t fsp_version;
>
> post_code(0x34);
>
> fsp_version = fsp_memory_settings_version(hdr);
>
> upd = (FSPM_UPD *)(hdr->cfg_region_offset + hdr->image_base);
>
> if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE)
> die("Invalid FSPM signature!\n");
>
> ...
>
> 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.
>
> 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, but someone from Intel suggested that it's only applicable
> to
> -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.
>
> 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.
>
> Any help from the coreboot community would be most appreciated!
>
> Thanks!
>
> - Jay
>
> Jay Talbott
> Principal Consulting Engineer
> SysPro Consulting, LLC
> 3057 E. Muirfield St.
> <https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gmail&source=g>
> Gilbert, AZ 85298
> <https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gmail&source=g>
> (480) 704-8045
> (480) 445-9895 (FAX)
> JayTalbott at sysproconsulting.com
> http://www.sysproconsulting.com
>
> > -----Original Message-----
> > From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Nico
> > Huber
> > Sent: Saturday, November 04, 2017 5:38 AM
> > To: Jay Talbott; coreboot at coreboot.org
> > Cc: Stefan Reinauer
> > Subject: Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15)
> > CRB?
> >
> > Hi Jay,
> >
> > On 04.11.2017 01:26, Jay Talbott wrote:
> > > I'm trying to get coreboot up and running on an Intel RVP15 CRB, which
> is
> > > the same as the RVP7 except that the RVP15 has DDR4 memory instead of
> > DDR3.
> > >
> > > There is a mainboard solution for the RVP7 in coreboot. However, the
> > current
> > > KabyLake FSP published on GitHub doesn't seem like it's the right FSP
> for
> > > the SkyLake-U/KabyLake-U. If nothing else, there's a problem with that
> FSP
> > > such that the signature in the FSP-M UPD header does not match the
> > signature
> > > in the corresponding header files, so when the FSP 2.0 driver in
> coreboot
> > > goes to check that they are a match, execution dies right there.
> > >
> > > if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE)
> > > die("Invalid FSPM signature!\n");
> > >
> > > (coreboot/src/drivers/intel/fsp2_0/memory_init.c, in function
> > > do_fsp_memory_init)
> > >
> > > I don't want to bypass that check in the code in case the FSP posted to
> > > GitHub isn't the right FSP for this particular SoC.
> >
> > the FSP binary is probably the correct one, but you have to separate it
> > into three pieces: FSP-T, FSP-M, FSP-S. Did you do that? Only FSP-M and
> > FSP-S are needed in coreboot. There is a script (SplitFspBin.py in EDK
> > II) that can separate the blobs, I have no idea why Intel puts them to-
> > gether at all.
> >
> > IIRC, there is no version check on the binary. You have to compare the
> > header files used in coreboot and those that come with the binary manu-
> > ally. Generally, the binaries on github work with corebot. But they seem
> > to come out of a different development process at Intel. The Intel deve-
> > lopers working on coreboot seem to have no clue that the binaries on
> > github exist at all. And if you compare the history of the header files
> > in coreboot to those on github you'll see that Intel either pushes the
> > wrong headers or the binaries on github and the binaries used for core-
> > boot development are not from the same branch. It's really creepy (and
> > hard to tell which of the versions are the one with the backdoors oO).
> >
> > > Obviously, somebody at Intel has the right FSP that works for these
> boards
> > > in order to validate that the coreboot implementation worked prior to
> > > upstreaming it to the repo. I'm just not sure how to get the right one
> so
> > > that I can get this booting.
> >
> > As you have access to a CRB, your contact to Intel is probably better
> > than mine. You have to ask Intel. OEMs/ODMs/IBVs, they all seem to have
> > access to the binaries used for coreboot development... IMHO, a huge
> > offense to the coreboot community that we get to maintain the code for
> > blobs that we'll never see; not even the binaries!
> >
> > > Furthermore, I have yet to get the serial console working on the DB-9
> serial
> > > port. I have the jumpers on the board configured to connect it to UART
> #2,
> > > and configured in coreboot accordingly, but I get nothing for console
> > > output.
> >
> > Please attach your .config file and point to the source revision you are
> > using. Hard to tell anything w/o the code.
> >
> > Nico
> >
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> 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/fbd06845/attachment.html>
More information about the coreboot
mailing list