<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 4, 2017 at 12:48 PM, Jay Talbott <span dir="ltr"><<a href="mailto:JayTalbott@sysproconsulting.com" target="_blank">JayTalbott@sysproconsulting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8153842124273724422WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hi Matt,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I’ll try XIP and see what happens… but how would that impact the UPD signature?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The signature is defined in coreboot/src/vendorcode/intel/<wbr>fsp/fsp2_0/skykabylake/FspUpd.<wbr>h, as well as in FspUpd.h in the headers included with the FSP on GitHub.</span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>ref:</div><div><a href="https://raw.githubusercontent.com/coreboot/coreboot/master/src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspUpd.h">https://raw.githubusercontent.com/coreboot/coreboot/master/src/vendorcode/intel/fsp/fsp2_0/skykabylake/FspUpd.h</a><br></div><div><a href="https://raw.githubusercontent.com/IntelFsp/FSP/Kabylake/KabylakeFspBinPkg/Include/FspUpd.h">https://raw.githubusercontent.com/IntelFsp/FSP/Kabylake/KabylakeFspBinPkg/Include/FspUpd.h</a><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8153842124273724422WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><span class="gmail-"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">- Jay<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Jay Talbott<br>Principal Consulting Engineer<br>SysPro Consulting, LLC<br><a href="https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gmail&source=g">3057 E. Muirfield St.</a><br><a href="https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gmail&source=g">Gilbert, AZ 85298</a><br>(480) 704-8045<br>(480) 445-9895 (FAX)<br><a href="mailto:JayTalbott@sysproconsulting.com" target="_blank">JayTalbott@sysproconsulting.<wbr>com</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><a href="http://www.sysproconsulting.com/" target="_blank">http://www.sysproconsulting.<wbr>com</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p></span><div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt"><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in"><p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Matt DeVillier [mailto:<a href="mailto:matt.devillier@gmail.com" target="_blank">matt.devillier@gmail.<wbr>com</a>] <br><b>Sent:</b> Saturday, November 04, 2017 9:59 AM<br><b>To:</b> Jay Talbott<br><b>Cc:</b> Nico Huber; coreboot; Stefan Reinauer</span></p><div><div class="gmail-h5"><br><b>Subject:</b> Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB?<u></u><u></u></div></div><p></p></div></div><div><div class="gmail-h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><div><p class="MsoNormal">On Sat, Nov 4, 2017 at 11:18 AM, Jay Talbott <<a href="mailto:JayTalbott@sysproconsulting.com" target="_blank">JayTalbott@sysproconsulting.<wbr>com</a>> wrote:<u></u><u></u></p><p class="MsoNormal">Ok, more details...<br><br>I'm currently building Coreboot off the end of the master branch as of<br>commit 43a285f983f6c29467d7f30f7e2b40<wbr>2926bd5c6f, but might back up to the<br>commit where the RVP7 support was added to see if that helps:<br><a href="https://github.com/coreboot/coreboot/commit/2ed14f61d1a2976d0ebce59fcc67bd61fce4100d" target="_blank">https://github.com/coreboot/<wbr>coreboot/commit/<wbr>2ed14f61d1a2976d0ebce59fcc67bd<wbr>61<br>fce4100d</a><br><br>I'm using the KBL FSP from GitHub:<br><a href="https://github.com/IntelFsp/FSP/tree/Kabylake/KabylakeFspBinPkg" target="_blank">https://github.com/IntelFsp/<wbr>FSP/tree/Kabylake/<wbr>KabylakeFspBinPkg</a><br><br>I got the SplitFspBin.py tool and split the FSP into its three separate<br>components. And, eventually, found the right microcode files and made them<br>into a binary blob using a modified version of the microcode2bin.sh script I<br>found in the coreboot tree.<br><br>My .config file (renamed as config.txt) is attached.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">you need to use the execute in place (XIP) option for FSP-M in your config<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal"><br>Note that the signature in the Fsp_M binary UPD struct is what does not<br>match what's in the corresponding FSP header file - and not just the header<br>file in the coreboot tree, but the one published as part of the FSP package<br>on GitHub. So something is definitely amiss here with this published FSP<br>package.<u></u><u></u></p></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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?<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal" style="margin-bottom:12pt"><br>I do not have the serial console working yet, so all I've had to go by are<br>post codes, and the last post code I was getting was 0x34, which I tracked<br>down to be a hardcoded (grr...) value at the beginning of<br>do_fsp_memory_init() in file memory_init.c of the FSP 2.0 driver<br>(./src/drivers/intel/fsp2_0)..<wbr>.<br><br>static void do_fsp_memory_init(struct fsp_header *hdr, bool s3wake,<br>                                        const struct memranges *memmap)<br>{<br>        uint32_t status;<br>        fsp_memory_init_fn fsp_raminit;<br>        FSPM_UPD fspm_upd, *upd;<br>        FSPM_ARCH_UPD *arch_upd;<br>        uint32_t fsp_version;<br><br>        post_code(0x34);<br><br>        fsp_version = fsp_memory_settings_version(<wbr>hdr);<br><br>        upd = (FSPM_UPD *)(hdr->cfg_region_offset + hdr->image_base);<br><br>        if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE)<br>                die("Invalid FSPM signature!\n");<br><br>        ...<br><br>I added a post code as part of the if to confirm that the signature<br>mis-match was where the code was hanging. So I'm 100% certain that the<br>mis-match exists with this particular FSP. Also, although the signature is<br>the same, there are a few other differences between the header files<br>included with the FSP and those currently in coreboot, but nothing that<br>would seemingly account for this issue.<br><br>Note that this particular FSP release on GitHub does NOT include any release<br>notes to indicate for which SkyLake/Kaby Lake variants (-H, -U, -Y, etc.) it<br>is applicable, but someone from Intel suggested that it's only applicable to<br>-H. If that's the case, then how was the RVP7 support ever validated prior<br>to integration into the coreboot tree? Which FSP was actually used? And does<br>that even have anything to do with the signature mis-match issue? Nobody<br>seems to know.<br><br>I've been trying to get support on this through various channels at Intel<br>that so far have not been particularly helpful, and it's extremely<br>frustrating. I've sent several e-mails to various folks, including the<br>individual that upstreamed the RVP7 support to coreboot and the individual<br>who published the FSP to GitHub, which remain unanswered.<br><br>Any help from the coreboot community would be most appreciated!<br><br>Thanks!<br><br><span class="gmail-m_8153842124273724422im">- Jay</span><br><br><span class="gmail-m_8153842124273724422im">Jay Talbott</span><br><span class="gmail-m_8153842124273724422im">Principal Consulting Engineer</span><br><span class="gmail-m_8153842124273724422im">SysPro Consulting, LLC</span><br><span class="gmail-m_8153842124273724422im"><a href="https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gmail&source=g">3057 E. Muirfield St.</a></span><br><span class="gmail-m_8153842124273724422im"><a href="https://maps.google.com/?q=3057+E.+Muirfield+St.+Gilbert,+AZ+85298&entry=gmail&source=g">Gilbert, AZ 85298</a></span><br><span class="gmail-m_8153842124273724422im">(480) 704-8045</span><br><span class="gmail-m_8153842124273724422im">(480) 445-9895 (FAX)</span><br><span class="gmail-m_8153842124273724422im"><a href="mailto:JayTalbott@sysproconsulting.com" target="_blank">JayTalbott@sysproconsulting.<wbr>com</a></span><br><span class="gmail-m_8153842124273724422im"><a href="http://www.sysproconsulting.com" target="_blank">http://www.sysproconsulting.<wbr>com</a></span><u></u><u></u></p><div><div><p class="MsoNormal">> -----Original Message-----<br>> From: coreboot [mailto:<a href="mailto:coreboot-bounces@coreboot.org" target="_blank">coreboot-bounces@<wbr>coreboot.org</a>] On Behalf Of Nico<br>> Huber<br>> Sent: Saturday, November 04, 2017 5:38 AM<br>> To: Jay Talbott; <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>> Cc: Stefan Reinauer<br>> Subject: Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15)<br>> CRB?<br>><br>> Hi Jay,<br>><br>> On 04.11.2017 01:26, Jay Talbott wrote:<br>> > I'm trying to get coreboot up and running on an Intel RVP15 CRB, which<br>is<br>> > the same as the RVP7 except that the RVP15 has DDR4 memory instead of<br>> DDR3.<br>> ><br>> > There is a mainboard solution for the RVP7 in coreboot. However, the<br>> current<br>> > KabyLake FSP published on GitHub doesn't seem like it's the right FSP<br>for<br>> > the SkyLake-U/KabyLake-U. If nothing else, there's a problem with that<br>FSP<br>> > such that the signature in the FSP-M UPD header does not match the<br>> signature<br>> > in the corresponding header files, so when the FSP 2.0 driver in<br>coreboot<br>> > goes to check that they are a match, execution dies right there.<br>> ><br>> >       if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE)<br>> >             die("Invalid FSPM signature!\n");<br>> ><br>> > (coreboot/src/drivers/intel/<wbr>fsp2_0/memory_init.c, in function<br>> > do_fsp_memory_init)<br>> ><br>> > I don't want to bypass that check in the code in case the FSP posted to<br>> > GitHub isn't the right FSP for this particular SoC.<br>><br>> the FSP binary is probably the correct one, but you have to separate it<br>> into three pieces: FSP-T, FSP-M, FSP-S. Did you do that? Only FSP-M and<br>> FSP-S are needed in coreboot. There is a script (SplitFspBin.py in EDK<br>> II) that can separate the blobs, I have no idea why Intel puts them to-<br>> gether at all.<br>><br>> IIRC, there is no version check on the binary. You have to compare the<br>> header files used in coreboot and those that come with the binary manu-<br>> ally. Generally, the binaries on github work with corebot. But they seem<br>> to come out of a different development process at Intel. The Intel deve-<br>> lopers working on coreboot seem to have no clue that the binaries on<br>> github exist at all. And if you compare the history of the header files<br>> in coreboot to those on github you'll see that Intel either pushes the<br>> wrong headers or the binaries on github and the binaries used for core-<br>> boot development are not from the same branch. It's really creepy (and<br>> hard to tell which of the versions are the one with the backdoors oO).<br>><br>> > Obviously, somebody at Intel has the right FSP that works for these<br>boards<br>> > in order to validate that the coreboot implementation worked prior to<br>> > upstreaming it to the repo. I'm just not sure how to get the right one<br>so<br>> > that I can get this booting.<br>><br>> As you have access to a CRB, your contact to Intel is probably better<br>> than mine. You have to ask Intel. OEMs/ODMs/IBVs, they all seem to have<br>> access to the binaries used for coreboot development... IMHO, a huge<br>> offense to the coreboot community that we get to maintain the code for<br>> blobs that we'll never see; not even the binaries!<br>><br>> > Furthermore, I have yet to get the serial console working on the DB-9<br>serial<br>> > port. I have the jumpers on the board configured to connect it to UART<br>#2,<br>> > and configured in coreboot accordingly, but I get nothing for console<br>> > output.<br>><br>> Please attach your .config file and point to the source revision you are<br>> using. Hard to tell anything w/o the code.<br>><br>> Nico<br>><br>> --<br>> coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>> <a href="https://mail.coreboot.org/mailman/listinfo/coreboot" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><u></u><u></u></p></div></div><p class="MsoNormal"><br>--<br>coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br><a href="https://mail.coreboot.org/mailman/listinfo/coreboot" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div></div></blockquote></div><br></div></div>