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.
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.
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.
Any help would be most appreciated!
Thanks,
- Jay
Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) mailto:JayTalbott@sysproconsulting.com JayTalbott@sysproconsulting.com
http://www.sysproconsulting.com/ http://www.sysproconsulting.com
Hi Jay,
the SKL/KBL FSP blob published on Github is compatible with the headers currently in coreboot, with the exception of the MEMORY_INFO_DATA_HOB - as is, coreboot will not be able to parse the HOB and populate the SMBIOS tables (minor adjustment needed, see: https://pastebin.com/Um9m7X43), but otherwise it should boot and run without issue (at least it does on the handful of SKL devices I've used it with, using both DDR3 and DDR4). The FSP signatures absolutely should match, so I'm not sure why you're seeing otherwise
-Matt
On Fri, Nov 3, 2017 at 7:26 PM, Jay Talbott <JayTalbott@sysproconsulting.com
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…
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.
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.
Any help would be most appreciated!
Thanks,
- Jay
Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott@sysproconsulting.com
http://www.sysproconsulting.com
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
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
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/2ed14f61d1a2976d0ebce59fcc67bd61 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.
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 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. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott@sysproconsulting.com http://www.sysproconsulting.com
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Nico Huber Sent: Saturday, November 04, 2017 5:38 AM To: Jay Talbott; coreboot@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
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: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
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. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott@sysproconsulting.com http://www.sysproconsulting.com
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Nico Huber Sent: Saturday, November 04, 2017 5:38 AM To: Jay Talbott; coreboot@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
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: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Hi,
On 04.11.2017 17:18, Jay Talbott wrote:
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.
coreboot likely is just looking at the wrong offset. Try what Matt suggested, enable XIP. IIRC, it was necessary but I never looked into it. (Kconfig options for FSP are a mess, often only one value for an option works, sometimes it's not the default. Some ppl working on core- boot for Intel don't understand the concept of options.)
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,
I've never seen FSP release notes that indicate it. FSP releases are rather undocumented. The idea seems to be to hide as much as possible and they succeeded: The UPDs of FSP are less documented than the regis- ters it sets.
but someone from Intel suggested that it's only applicable to -H.
I was told it would be working for -S, -H, -U and -Y, and it likely is. Maybe that someone meant it's only validated for -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.
They (Intel/OEMs/ODMs/IBVs) use a completely different line of binaries that only get published as part of their device' firmware. The interes- ting part: If you are a member of the club, you likely also have access to the FSP sources and don't need documentation that much.
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.
Heh, welcome to (Intel based) coreboot. I just went through the same pain, without success. We ended up with weird workarounds because what Intel delivers lacks any sense of firmware security. Not sure if we'll end up sandboxing or rewriting FSP. (If I'd do the latter it likely won't be GPL code. Pairing that one with blobs obviously failed the project.)
Nico
Hi,
Please try with CONFIG_FSP_M_XIP=y
I guess you are splitting the Fsp.fd file(python SplitFspBin.py split -f FSP_M.fd).
If so you can verify FSP_M.fd containing the signature.( hexdump -C FSP_M.fd | less ) Look for KBLUPD_M. I found it at offset 0x5a6cc.
Consider using config.kblrvp as reference : https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/r...
Regards, Naresh
On Sat, Nov 4, 2017 at 11:25 PM, Nico Huber nico.h@gmx.de wrote:
Hi,
On 04.11.2017 17:18, Jay Talbott wrote:
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.
coreboot likely is just looking at the wrong offset. Try what Matt suggested, enable XIP. IIRC, it was necessary but I never looked into it. (Kconfig options for FSP are a mess, often only one value for an option works, sometimes it's not the default. Some ppl working on core- boot for Intel don't understand the concept of options.)
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,
I've never seen FSP release notes that indicate it. FSP releases are rather undocumented. The idea seems to be to hide as much as possible and they succeeded: The UPDs of FSP are less documented than the regis- ters it sets.
but someone from Intel suggested that it's only applicable to -H.
I was told it would be working for -S, -H, -U and -Y, and it likely is. Maybe that someone meant it's only validated for -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.
They (Intel/OEMs/ODMs/IBVs) use a completely different line of binaries that only get published as part of their device' firmware. The interes- ting part: If you are a member of the club, you likely also have access to the FSP sources and don't need documentation that much.
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.
Heh, welcome to (Intel based) coreboot. I just went through the same pain, without success. We ended up with weird workarounds because what Intel delivers lacks any sense of firmware security. Not sure if we'll end up sandboxing or rewriting FSP. (If I'd do the latter it likely won't be GPL code. Pairing that one with blobs obviously failed the project.)
Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot