Open ghtux opened 5 years ago
A Theory: Electronically, it seems plausible, since we are all using some sort of cobbled tool and programming the EERPOM in circuit, that some cells were in a quasi state and flipped back after the verify was run. Usually that would cause an erratic or bricked machine. But in this one instance your machine booted.
For what it's worth, in my case upgrading does not exhibit such behaviour, but I did use the nonfree image and Intel ME is still there. 8+8GB RAM configuration.
What I did run into recently was that one of the DIMM slots got picky about RAM all of a sudden. Both RAM sticks were detected, but only 8GB of RAM was available for use. Reseated both RAM sticks multiple times until everything started working again. Might be related.
I experience the same issue: Only half ram useable. Second flash remedies this problem. In retrospect, the issue I opened at that time ( https://github.com/merge/skulls/issues/127 ) was likely the same symptom.
Seeing only half the installed RAM means that raminit failed to train one channel, so it tried again with the failing channel disabled, and then succeeded. However, it saved the training data in flash, so it won't retrain again unless the DIMMs change or the training data is erased. Reflashing clears that training data, so raminit will run again. Sure, this could be changed, but someone has to do it.
@Th3Fanbus https://ticket.coreboot.org/issues/462
As mentioned in this issue, I tried flashing the BIOS a second time, but it didn't seem to solve the problem of only half of the memory being recognized, and there didn't seem to be anything useful in the logs.
But these two memory modules seem to be able to be initialized if used alone.
HW: x230 me_removed, 8 GB Ram
Reproduce: upgrade bios (while iomem=relaxed), reboot. Only 4 GB ram are available. Flash again, reboot. All ram is available.
Expected behaviour: only one flash should be required.
Same behaviour for the last three releases.