summaryrefslogtreecommitdiff
path: root/3rdparty
diff options
context:
space:
mode:
authorAngel Pons <th3fanbus@gmail.com>2020-03-21 18:06:03 +0100
committerPatrick Georgi <pgeorgi@google.com>2020-03-23 19:27:34 +0000
commita6a64183d6c5d535df5e62fad419402cd896f03d (patch)
tree6bb33bd8f63cb2200ef7afad7b748ffcfb1ee95d /3rdparty
parent80037f715c9de5a8bb926a0820508d7530e6f429 (diff)
nb/intel/sandybridge: Void MRC cache if CPUID differs
Native raminit asserts that the DIMMs haven't been replaced before reusing the saved training data. However, it does not check if the CPU is still the same, so it can end up happily reusing data from an Ivy Bridge CPU onto a Sandy Bridge CPU, which runs the raminit_ivy.c code path. This can make the CPU run in unsupported configurations, which may result in an unstable system, or a failure to boot. To prevent that, ensure that the stored CPUID matches the CPUID of the installed CPU. If they differ, print a message and do not use the saved data. As it does not pose a problem for a regular boot, but precludes resuming from S3, use different loglevels depending on the bootpath. Tested on Asus P8Z77-V LX2 with an i7-2600 and an i5-3330, works well. Change-Id: Ib0691f1f849b567579f6afa845c9460e14f8fa27 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39734 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Diffstat (limited to '3rdparty')
0 files changed, 0 insertions, 0 deletions