Hi Matt, Jay,
On 04.11.2017 03:25, Matt DeVillier wrote:
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
I'm not sure what versions you are comparing, I see many more diffe- rences between Kabylake FSP from github (54b6a31) and upstream sky- kabylake in coreboot (b2b2015, see attachment). Also in UPD values (SpiFlashCfgLockDown and ThreeStrikeCounterDisable were added to FSPS UPD, the former is used in coreboot).
Do I miss something? Is there another more recent published binary?
Nico
-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
On Sat, Nov 4, 2017 at 7:16 AM, Nico Huber nico.h@gmx.de wrote:
Hi Matt, Jay,
On 04.11.2017 03:25, Matt DeVillier wrote:
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
I'm not sure what versions you are comparing, I see many more diffe- rences between Kabylake FSP from github (54b6a31) and upstream sky- kabylake in coreboot (b2b2015, see attachment). Also in UPD values (SpiFlashCfgLockDown and ThreeStrikeCounterDisable were added to FSPS UPD, the former is used in coreboot).
Do I miss something? Is there another more recent published binary?
Nico
sorry my original msg was unclear - you are correct that the SKL/KBL FSP2 headers in coreboot do add a few new fields (though the majority of the diff is comment changes). I only meant to convey that the Github binary should boot with the coreboot headers, and is seemingly functional with the exception of the SMBIOS HOB/table issue.
-
Matt DeVillier -
Nico Huber