Actions
Bug #43
closedLow memory and coreboot table corrupts after s3 resume on Sandy/Ivy Bridge machines
Start date:
04/18/2016
Due date:
% Done:
100%
Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:
Description
My Lenovo T520 gives a low memory corruption MCE after s3 resume, and `cbmem -l' will report no coreboot table. And reverting the 'always enable mrccache' commit will solve it. As Nico Huber said on IRC, channel_test() will be run after s3resume in this commit, and I tried the following and solved the problem:
diff --git a/src/northbridge/intel/sandybridge/raminit.c b/src/northbridge/intel/sandybridge/raminit.c
index 042898d..c4f53a3 100644
--- a/src/northbridge/intel/sandybridge/raminit.c
+++ b/src/northbridge/intel/sandybridge/raminit.c
@@ -4037,7 +4037,7 @@ static void restore_timings(ramctr_timing * ctrl)
write32(DEFAULT_MCHBAR + 0x4ea8, 0);
}
-static int try_init_dram_ddr3(ramctr_timing *ctrl, int fast_boot,
+static int try_init_dram_ddr3(ramctr_timing *ctrl, int fast_boot, int s3resume,
int me_uma_size)
{
int err;
@@ -4148,9 +4148,11 @@ static int try_init_dram_ddr3(ramctr_timing *ctrl, int fast_boot,
write_controller_mr(ctrl);
+ if (!s3resume) {
err = channel_test(ctrl);
if (err)
return err;
+ }
return 0;
}
@@ -4228,7 +4230,7 @@ void init_dram_ddr3(spd_raw_data *spds, int mobile, int min_tck,
printk(BIOS_DEBUG, "Trying stored timings.\n");
memcpy(&ctrl, ctrl_cached, sizeof(ctrl));
- err = try_init_dram_ddr3(&ctrl, fast_boot, me_uma_size);
+ err = try_init_dram_ddr3(&ctrl, fast_boot, s3resume, me_uma_size);
if (err) {
/* no need to erase bad mrc cache here, it gets overritten on
* successful boot. */
@@ -4243,7 +4245,7 @@ void init_dram_ddr3(spd_raw_data *spds, int mobile, int min_tck,
/* Get DDR3 SPD data */
dram_find_spds_ddr3(spds, &ctrl);
- err = try_init_dram_ddr3(&ctrl, fast_boot, me_uma_size);
+ err = try_init_dram_ddr3(&ctrl, fast_boot, s3resume, me_uma_size);
}
if (err)
die("raminit failed");
Updated by Patrick Rudolph almost 8 years ago
You patch looks good.
I can't reproduce the issue on T520, but it's clearly a regression of my previous patch.
Updated by Patrick Rudolph almost 8 years ago
Updated by Iru Cai almost 8 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Actions