It is believed that all X200 laptops are compatible. X200S and X200 Tablet will also work, depending on the configuration.
It *might* be possible to put an X200 motherboard in an X201 chassis, though this is currently untested by the libreboot project. The same may also apply between X200S and X201S; again, this is untested. It's most likely true.
There are two possible flash chip sizes for the X200: 4MiB (32Mbit) or 8MiB (64Mbit). This can be identified by the type of flash chip below the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
The X200 laptops come with the ME (and sometimes AMT in addition) before flashing libreboot. Libreboot disables and removes it by using a modified descriptor: see gm45_remove_me.html (contains notes, plus instructions)
Flashing instructions can be found at ../install/index.html#flashrom
The X200, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if not, software virtualization should work fine (it's just slower).
On GM45 hardware (with libreboot), make sure that the kvm and kvm_intel kernel modules are not loaded, when using QEMU.
The following errata datasheet from Intel might help with investigation: http://download.intel.com/design/mobile/specupdt/320121.pdf
Anecdotal reports from at least 1 user suggests that some models with CPU microcode 1067a (on the CPU itself) might work with vt-x in libreboot.
X200S and X200 Tablet have raminit issues at the time of writing (GS45 chipset. X200 uses GM45).
X200S and X200 Tablet are known to work, but only with certain CPU+RAM configurations. The current stumbling block is RCOMP and SFF, mentioned in https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf.
The issues mostly relate to raminit (memory initialization). With an unpatched coreboot, you get the following: text/x200s/cblog00.txt. No SODIMM combination that was tested would work. At first glance, it looks like GS45 (chipset that X200S uses. X200 uses GM45) is unsupported, but there is a workaround that can be used to make certain models of the X200S work, depending on the RAM.
The datasheet for GS45 describes two modes: low-performance and high-performance. Low performance uses the SU range of ultra-low voltage procesors (SU9400, for example), and high-performance uses the SL range of processors (SL9400, for example). According to datasheets, GS45 behaves very similarly to GM45 when operating in high-performance mode.
The theory then was that you could simply remove the checks in coreboot and make it pass GS45 off as GM45; the idea is that, with a high-performance mode CPU (SL9400, for example) it would just boot up and work.
This suspicion was confirmed with the following log:
text/x200s/cblog01.txt.
The memory modules in this case are 2x4GB. However, not all
configurations work: text/x200s/cblog02.txt (2x2GB)
and text/x200s/cblog03.txt (1x2GB)
show a failed bootup. False alarm. The modules were mixed (non-matching). X200S
with high-performance mode CPU will work so long as you use matching memory modules
(doesn't matter what size).
This was then pushed as a patch for coreboot, which can be found at http://review.coreboot.org/#/c/7786/ (libreboot merges this patch in coreboot-libre now. Check the 'getcb' script in src or git).
A new northbridge gs45 should be added to coreboot, based on gm45, and a new port x200st (X200S and X200T) should be added based on the x200 port.
This port would have proper raminit. Alternatively, gs45 (if raminit is taken to be the only issue with it) can be part of gm45 northbridge support (and X200S/Tablet being part of the X200 port) with conditional checks in the raminit that make raminit work differently (as required) for GS45. nico_h and pgeorgi/patrickg in the coreboot IRC channel should know more about raminit on gm45 and likely gs45.
pgeorgi recommends to run SerialICE on the factory BIOS (for X200S), comparing it with X200 (factory BIOS) and X200 (gm45 raminit code in coreboot), to see what the differences are. Then tweak raminit code based on that.
This person seems to have a workaround: https://github.com/the-unconventional/libreboot-undock
LCD panel list (X200 panels listed there): http://www.thinkwiki.org/wiki/TFT_display
All LCD panels for the X200, X200S and X200 Tablet are known to work.
Adapted from https://github.com/bibanon/Coreboot-ThinkPads/wiki/ThinkPad-X200
Look at wikipedia for difference between TN and IPS panels. IPS have much better colour/contrast than a regular TN, and will typically have good viewing angles.
These seem to be from the X200 tablet. You need to find one without the glass touchscreen protection on it (might be able to remove it, though). It also must not have a digitizer on it (again, might be possible to just simply remove the digitizer).
If your X200 has an LED backlit panel in it, then you also need to get an inverter and harness cable that is compatible with the CCFL panels. To see which panel type you have, see #led_howtotell. If you need the inverter/cable, here are part numbers: 44C9909 for CCFL LVDS cable with bluetooth and camera connections, and 42W8009 or 42W8010 for the inverter.
There are glossy and matte versions of these. Matte means anti-glare, which is what you want (in this authors opinion).
Refer to the HMM (hardware maintenance manual) for how to replace the screen.
Sources:
http://forum.thinkpads.com/viewtopic.php?p=618928#p618928 explains that the X200S screens/assemblies are thinner. You need to replace the whole lid with one from a normal X200/X201.
Some X200s have a CCFL backlight and some have an LED backlight, in their LCD panel. This also means that the inverters will vary, so you must be careful if ever replacing either the panel and/or inverter. (a CCFL inverter is high-voltage and will destroy an LED backlit panel).
CCFLs contain mercury. An X200 with a CCFL backlight will (unless it has been changed to an LED, with the correct inverter. Check with your supplier!) the following: "This product contains Lithium Ion Battery, Lithium Battery and a lamp which contains mercury; dispose according to local, state or federal laws" (one with an LED backlit panel will say something different).
The coreboot wiki shows how to collect various logs useful in porting to new boards. Following are outputs from the X200:
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.
This page might be useful for RAM compatibility info (note: coreboot raminit is different, so this page might be BS)
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.
<sgsit> do you know if it's possible to flash thinkpads over the LPC debug connector at the front edge? <sgsit> that would make life much easier for systems like this <sgsit> all the Wistron manufactured systems have this thing called a "golden finger", normally at the front edge of the board <sgsit> you can plug a board in which gives diagnostic codes but i'm wondering whether it is capable of more <sgsit> http://www.endeer.cz/bios.tools/bios.html
Copyright © 2014, 2015 Francis Rowe <info@gluglug.org.uk>
Copyright © 2015 Patrick "P. J." McDermott <pj@pehjota.net>
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license can be found at ../gfdl-1.3.txt
Updated versions of the license (when available) can be found at https://www.gnu.org/licenses/licenses.html
UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.