[coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB?
matt.devillier at gmail.com
Sat Nov 4 17:58:35 CET 2017
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:
> I'm using the KBL FSP from GitHub:
> 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
> 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
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
> 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;
> 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
> notes to indicate for which SkyLake/Kaby Lake variants (-H, -U, -Y, etc.)
> is applicable, but someone from Intel suggested that it's only applicable
> -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
> 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!
> - Jay
> Jay Talbott
> Principal Consulting Engineer
> SysPro Consulting, LLC
> 3057 E. Muirfield St.
> Gilbert, AZ 85298
> (480) 704-8045
> (480) 445-9895 (FAX)
> JayTalbott at 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
> > > 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
> > > the SkyLake-U/KabyLake-U. If nothing else, there's a problem with that
> > > 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
> > > 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
> > > 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
> > > 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
> > > port. I have the jumpers on the board configured to connect it to UART
> > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot