From df6cf20129120208b9d04f3244f45276cc5f4aa2 Mon Sep 17 00:00:00 2001 From: Francis Rowe Date: Wed, 01 Jul 2015 08:55:50 -0400 Subject: docs/hcl/x200.html: Notes about raminit, S3 and microcode --- (limited to 'docs/hcl/x200.html') diff --git a/docs/hcl/x200.html b/docs/hcl/x200.html index 8567a91..b8bbfd9 100644 --- a/docs/hcl/x200.html +++ b/docs/hcl/x200.html @@ -307,6 +307,48 @@
+

RAM, S3 and microcode updates

+ +

+ Not all memory modules work. Most of the default ones do, but you have to be careful + when upgrading to 8GiB; some modules work, some don't. +

+ +

+ pehjota started collecting some steppings for different CPUs on several X200 laptops. + You can get the CPUID by running:
+ $ dmesg | sed -n 's/^.* microcode: CPU0 sig=0x\([^,]*\),.*$/\1/p' +

+ +

+ What pehjota wrote: + The laptops that have issues resuming from suspend, as well as a laptop that (as I mentioned earlier in #libreboot) won't boot with any Samsung DIMMs, all have CPUID 0x10676 (stepping M0). +

+ +

+ What pehjota wrote: + Laptops with CPUID 0x167A (stepping R0) resume properly every time and work with Samsung DIMMs. I'll + need to do more testing on more units to better confirm these trends, but it looks like the M0 microcode + is very buggy. That would also explain why I didn't have issues with Samsung DIMMs with the Lenovo BIOS + (which would have microcode updates). I wonder if VT-x works on R0. +

+ +

+ What pehjota wrote: + As I said, 10676 is M0 and 1067A is R0; those are the two CPUIDs and steppings for Intel Core 2 Duo P8xxx CPUs with factory microcode. (1067 is the family and model, and 6 or A is the stepping ID.) +

+ +

+ + TODO: check the CPUIDs and test S3 resume and/or KVM on any C2D systems (including non-P8xxx ones, which I don't have here) you have available. I'd be curious if you could confirm these results. + + It might not be coreboot that's buggy with raminit/S3; it might just be down to the microcode updates. +

+ +
+ +
+

Unsorted notes

--
cgit v0.9.1