<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 4, 2017 at 11:18 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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/2ed14f61d1a2976d0ebce59fcc67bd61
fce4100d" rel="noreferrer" 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" rel="noreferrer" 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.<br></blockquote><div><br></div><div>you need to use the execute in place (XIP) option for FSP-M in your config</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<span class=""><br>
        if (upd->FspUpdHeader.Signature != FSPM_UPD_SIGNATURE)<br>
                die("Invalid FSPM signature!\n");<br>
<br>
</span>        ...<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>
<span class="im HOEnZb"><br>
- Jay<br>
<br>
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.<wbr>com</a><br>
<a href="http://www.sysproconsulting.com" rel="noreferrer" target="_blank">http://www.sysproconsulting.<wbr>com</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">> -----Original Message-----<br>
> From: coreboot [mailto:<a href="mailto:coreboot-bounces@coreboot.org">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">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">coreboot@coreboot.org</a><br>
> <a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
</div></div><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" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br></blockquote></div><br></div></div>