<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.im
{mso-style-name:im;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Matt,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’ll try XIP and see what happens… but how would that impact the UPD signature?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>- Jay<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Jay Talbott<br>Principal Consulting Engineer<br>SysPro Consulting, LLC<br>3057 E. Muirfield St.<br>Gilbert, AZ 85298<br>(480) 704-8045<br>(480) 445-9895 (FAX)<br><a href="mailto:JayTalbott@sysproconsulting.com">JayTalbott@sysproconsulting.com</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="http://www.sysproconsulting.com/">http://www.sysproconsulting.com</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Matt DeVillier [mailto:matt.devillier@gmail.com] <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<br><b>Subject:</b> Re: [coreboot] Who has experience with the Intel RVP7 (or RVP15) CRB?<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></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.com</a>> wrote:<o:p></o:p></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 43a285f983f6c29467d7f30f7e2b402926bd5c6f, 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/coreboot/commit/2ed14f61d1a2976d0ebce59fcc67bd61<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/FSP/tree/Kabylake/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.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>you need to use the execute in place (XIP) option for FSP-M in your config<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;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.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></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?<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal style='margin-bottom:12.0pt'><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)...<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(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=im>- Jay</span><br><br><span class=im>Jay Talbott</span><br><span class=im>Principal Consulting Engineer</span><br><span class=im>SysPro Consulting, LLC</span><br><span class=im>3057 E. Muirfield St.</span><br><span class=im>Gilbert, AZ 85298</span><br><span class=im>(480) 704-8045</span><br><span class=im>(480) 445-9895 (FAX)</span><br><span class=im><a href="mailto:JayTalbott@sysproconsulting.com">JayTalbott@sysproconsulting.com</a></span><br><span class=im><a href="http://www.sysproconsulting.com" target="_blank">http://www.sysproconsulting.com</a></span><o:p></o:p></p><div><div><p class=MsoNormal>> -----Original Message-----<br>> From: coreboot [mailto:<a href="mailto:coreboot-bounces@coreboot.org">coreboot-bounces@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">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/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">coreboot@coreboot.org</a><br>> <a href="https://mail.coreboot.org/mailman/listinfo/coreboot" target="_blank">https://mail.coreboot.org/mailman/listinfo/coreboot</a><o:p></o:p></p></div></div><p class=MsoNormal><br>--<br>coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br><a href="https://mail.coreboot.org/mailman/listinfo/coreboot" target="_blank">https://mail.coreboot.org/mailman/listinfo/coreboot</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></body></html>