On Sat, Nov 4, 2017 at 12:48 PM, Jay Talbott < [email protected]> 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) > [email protected] > > http://www.sysproconsulting.com > > > > *From:* Matt DeVillier [mailto:[email protected]] > *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@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) > [email protected] > http://www.sysproconsulting.com > > > -----Original Message----- > > From: coreboot [mailto:[email protected]] On Behalf Of Nico > > Huber > > Sent: Saturday, November 04, 2017 5:38 AM > > To: Jay Talbott; [email protected] > > 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: [email protected] > > https://mail.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot > > >
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
