Christian Walter has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37094 )
Change subject: Revert "3rdparts/fsp: Update fsp submodule" ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
How are we planing on dealing with this longterm? Reverting this would let fall Ice Lake out of support again... Could it be a temporary solution to keep the last known-good FSP.fd in the blobs repo for now and raise the problem with Intel or figure out the problem?
It might also be a quick solution to test the commit 9e53d779eb34e944f9b3386ad6a9df80f710bddd, that updated most but is before the f3ecfc496e9c07b553582197b5086cfe9948b384 commit "Coffee Lake FSP 7.0.68.40" and "Coffee Lake FSP 7.0.68.41" later that same day, so it still contains the CoffeLake FSP 7.0.64.40 Version from May 23rd.
I think i made a mistake.. Cannonlake is derived from Comet and not from CoffeeLake, right?
Cannonlake was meant to be the successor to Kaby Lake, with a shrink from 14nm to 10nm. However, AFAIUI, that shrink caused yield issues, and the only commercial Cannonlake chip is the i3-8121U. Instead, Coffee Lake was released, which uses a 14nm process.
I found this table particularly useful: https://en.wikipedia.org/wiki/Tick%E2%80%93tock_model#Roadmap
Patch Set 2:
Okay lets ease down here. I just double checked. What we could to is change this here - and instead of reverting it, just use commit 573bd5d6861376c8b4947d177dfe70592ff80fc2 (which is the renaming one) and use this as the submodule commit for now.
To be honest - I dont think it's my responsibility to debug the FSP now (how could I) - I am just notifying about the error - reverting this and we are go to go again.
Commit 573bd5d6861376c8b4947d177dfe70592ff80fc2 seems to work.
Alright, thanks for testing. This would narrow the issue down to three commits, one of which is just a documentation change. Therefore, the other two commits are extremely likely to be where the regression was introduced.
These last two commits correspond to the FSP 7.0.68.40 and FSP 7.0.68.41 updates for CFL. Do note that the former adds two additional FSP UPDs:
- LctRelaxedReset
- ScsSdCardWpPinEnabled
The latter is a FSP-S UPD related to the SD card controller's Write-Protect pin. I don't think it's much of an issue.
However, the other UPD is a FSP-M UPD, and is specific to DDR4 memory! The UPD description says:
Late Command Training Relaxed Reset Enable/Disable Relaxed JEDEC Reset during Late Command Training (Only for DDR4) 0:Disable, 1:Enable
Of course, if its value is never set, then it will very likely default to zero, and probably breaks things. This is definitely worth a try.
Okay - I did checked some things. So Commit f3ecfc496e9c07b553582197b5086cfe9948b384 (Update to version 7.0.68.40) is the commit which breaks the FSP. I tried setting the new introduced option 'LctRelaxedReset' in romstage/fsp_params.c to zero and one - none of those values work.
I would suggest this patch here and merge CB 37669 instead.