krystian-hebel
commented
2 years ago Sorry for the delay, I was busy with other projects and then reading provided log (almost 200k lines). Based on it, and additional SCOM dumps performed on platform, I have some rough idea of what happens. There were actually multiple errors (11 to be exact) reported in FIR, but some of them probably were caused by trying to load exception handler that does not exist.
We messed up a bit during simplification done to various isteps, like this one. As a result, a bit that tells that current CPU is the only one in the system is not set. Because of that, when code tries to write to RAM, a message is sent to other CPU that it should flush and invalidate its L3 cache. That other CPU does not exist, so main CPU doesn't receive an acknowledgement to that message. After quick and dirty fix in place (hardcoding it to 1 CPU version) "only" 4 errors were reported.
Further issues were caused by misunderstanding what ATTR_PROC_FABRIC_X_LINKS_CNFG is - we thought it is total number of X links, instead it is number of X links in use. For Nimbus this is 1 when there are 2 CPUs, 0 otherwise. With some additional hacks we got down to 2 reported errors, and a bit different manifestation of the problem - now platform doesn't reboot, instead it gets into infinite loop, but this may be caused by different layout of code with regard to cache lines.
I also noticed some differences that will become important when we get to OCC initialization, but we're not that far just yet. Also, if OCC was (partially) started earlier, it should be able to gather FIR SCOM, basically what I tried to get with scripts few comments above. This would however require starting OCC (at least) twice, and as I haven't thought it would be necessary, we decided to skip it in coreboot. AFAIK there is no ready-to-use tool for parsing those dumps.
Right now we're about to remove one CPU from our platform and see if we get exactly the same issue, as at least some of this problems should happen on every 1 CPU platform, if I understood it correctly.
tlaurion
macpijan
Dasharo version 0.5.0 release from https://docs.dasharo.com/variants/talos_2/releases/
Dasharo variant Workstation
Affected component(s) or functionality Memory initialization fails ( 1x M393A1K43BB0-CRC in B1 memory slot)
Brief summary The coreboot output stops at
How reproducible Always (Single 16 cores CPU, one RAM module: 8GB (More info on changes needed to be documented on non-flashing instructions under https://github.com/Dasharo/dasharo-issues/issues/79)
How to reproduce
Steps to reproduce the behavior: On laptop:
On a seperated SSH connection to BMC:
On another seperate SSH connection to BMC:
Expected behavior Ram init succeeds and net steps are engaged
Actual behavior Stops at