@@ -384,6 +385,48 @@
It is believed that the motherboards on 14.1" and 15.1" T60's are the same, so the same configuration is used
on both the 14.1" and 15.1" T60's.
+
+
+ ThinkPad X200 configuration (file: resources/libreboot/config/x200_4mb/config and resources/libreboot/config/x200_8mb/config)
+
+
+ These are saved as two configs, because there are 2 size flash chips: 4MB or 8MB.
+
+
+
General / Expert mode = enable
+
Mainboard / Mainboard vendor = Lenovo
+
Mainboard / Mainboard model = ThinkPad X200
+
Mainboard / ROM chip size = 4096 KB (4 MB) or 8192 KB (8 MB) depending on flash chip size
+
Chipset / Include CPU microcode in CBFS = Do not include microcode updates
+
Chipset / Size of CBFS filesystem in ROM = byte size 0x7FD000 (for 8MB flash chip) or 3FD000 (for 4MB flash chip)
+
Devices / Use native graphics initialization = enable
+
+ Display / Keep VESA framebuffer = disable (disable for text-mode graphics, enable for coreboot vesa framebuffer)
+
+
Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time
+ to enable coreboot framebuffer for a separate set of ROM images, in each machine.
+
+
+
Generic Drivers / USB 2.0 EHCI debug dongle support = Enable
+
Generic Drivers / Enable early (pre-RAM) usbdebug = Enable
+
Generic Drivers / Type of dongle = BeagleBone Black
+
Console / Send console output to a CBMEM buffer = enable
+
Console / USB dongle log output = enable
+
Payload / Add a payload = An ELF executable payload
+
Payload / Payload path and filename = grub.elf
+
+
+ Go back and disable option ROM's:
+
+
+
Devices / Run VGA Option ROMs = disable
+
Devices / Run Option ROMs on PCI devices = disable
+
+
+ The resulting .config file was saved as resources/libreboot/config/x200_8mb/config and
+ resources/libreboot/config/x200_4mb/config and is used by the build
+ scripts for this machine.
+
If you are building on an i686 host, this will include statically linked 32-bit binaries in the binary release archive that you created,
- for: nvramtool, cbfstool, bucts, flashrom.
+ for: nvramtool, cbfstool, bucts, flashrom, ich9deblob.
- If you are building on an x86_64 host, this will include statically linked 32- and 64-bit binaries for cbfstool and nvramtool, while flashrom
+ If you are building on an x86_64 host, this will include statically linked 32- and 64-bit binaries for ich9deblob, cbfstool and nvramtool, while flashrom
and bucts will be included only as 64-bit statically linked binaries. To include a statically linked flashrom and bucts for i686, you
will need to build them on a chroot, a virtual machine or a real 32-bit system. You can find the build dependencies for these packages listed in deps-*
+ It is believed that all X200 laptops are compatible. X200s and X200t may also work,
+ but require soldering (for the initial installation/flashing of a ROM image, or
+ dumping the current firmware). Only the X200 is tested so far.
+
+
+ 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 ME (and sometimes AMT) before flashing libreboot. Libreboot disables and removes it
+ by using a modified descriptor: see x200_remove_me.html (contains notes, plus
+ instructions)
+
+ Unless otherwise noted (italic styling, underlined), these are CCFL 1280x800 screens with TN panels inside.
+ Please do advise if you spot mistakes here.
+
+
+ Use the instructions at ../misc/index.html#get_edid_panelname
+ to get the name of your panel, then check it against the list below. If your panel is untested, then by all means
+ try it! (and get in touch with the libreboot project to advise whether or not it worked).
+
+ 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).
+
+
+
BOE-Hydis HV121WX4-120, HV121WX4-110 or HV121WX4-100 - cheap-ish, might be hard to find
+
Samsung LTN121AP02-001 - common to find, cheap
+
+
+ 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.
+
+ Some X200's 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).
+
+
+ CCFL's 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).
+
+ This document is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See ../../license.txt for more information.
+
ThinkPad X200: remove the ME (manageability engine)
+
+ This sections relates to disabling and removing the ME (Intel Management Engine)
+ on the ThinkPad X200.
+
+
+ The ME is a blob that typically must be left inside the flash chip (in the ME region, as outlined
+ by the default descriptor). On the X200, it is possible to remove it without any ill effects. All
+ other parts of coreboot on the X200 can be blob-free, so removing the ME was the last obstacle to
+ get X200 support in libreboot (the machine can also work without the microcode blobs).
+
+ This is what you will use to generate the deblobbed descriptor+gbe regions for your libreboot ROM image.
+
+
+ If you are working with libreboot_src (or git), you can find the source under resources/utilities/ich9deblob/
+ and will already be compiled if you ran ./builddeps or ./builddeps-ich9deblob from the main directory (./),
+ otherwise you can build it like so:
+ $ ./builddeps-ich9deblob
+ An executable file named ich9deblob will now appear under resources/utilities/ich9deblob/
+
+
+ If you are working with libreboot_bin release archive, you can find the utility included, statically compiled
+ (for i686 and x86_64 on GNU/Linux) under ./ich9deblob/.
+
+
+
+ Place the factory.rom from your X200
+ (can be obtained using the guide at ../install/x200_external.html) in
+ the directory where you have your ich9deblob executable, then run the tool:
+ $ ./ich9deblob
+
+
+ A 12kiB file named deblobbed_descriptor.bin will now appear. Keep this and the factory.rom stored in a safe location!
+ The first 4KiB contains the descriptor data region for your machine, and the next 8KiB contains the gbe region (config data for your
+ gigabit NIC). These 2 regions could actually be separate files, but they are joined into 1 file in this case.
+
+
+
+ Assuming that your X200 libreboot image is named libreboot.rom, copy
+ the deblobbed_descriptor.bin file to where libreboot.rom is located
+ and then run:
+ $ dd if=deblobbed_descriptor.bin of=libreboot.rom bs=1 count=12k conv=notrunc
+
+
+
+ You should now have a libreboot.rom image containing the correct 4K descriptor and 8K gbe regions, which
+ will then be safe to flash. Refer back to ../install/index.html#flashrom_x200
+ for how to flash it.
+
+
+
+
+
+ The sections below are adapted from (mostly) IRC logs related to early development getting the ME removed on the X200.
+ They are useful for background information. This could not have been done without sgsit's help.
+
+ See reference to HDA_SDO (disable descriptor security)
+ strap connected GPIO33 pin is it on ICH9-M (X200). HDA_SDO applies to later chipsets (series 6 or higher).
+ Disabling descriptor security also disables the ethernet according to sgsit. sgsit's method
+ involves use of 'soft straps' (see IRC logs below) instead of disabling the descriptor.
+
+
+ and the location of GPIO33 on the x200s: (was an external link. Putting it here instead)
+ images/x200/gpio33_location.jpg
+ - it's above the number 7 on TP37 (which is above the big intel chip at the bottom)
+
+ Schematics for X200 laptop: http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006075.pdf
+ - Page 20 and page 9 refer to SDA_HDO or SDA_HDOUT only on series 6 or higher chipsets. ICH9-M (X200) does it with a strap connected to GPIO33 pin (see IRC notes below)
+ - According to page 29, the X200 can have any of the following flash chips:
+
+
ATMEL AT26DF321-SU 72.26321.A01 - this is a 32Mb (4MiB) chip
+
MXIC (Macronix?) MX25L3205DM2I-12G 72.25325.A01 - another 32Mb (4MiB) chip
+
MXIC (Macronix?) MX25L6405DMI-12G 41R0820AA - this is a 64Mb (8MiB) chip
+
Winbond W25X64VSFIG 41R0820BA - another 64Mb (8MiB) chip
+
+ sgsit says that the X200's with the 64Mb flash chips are (probably) the ones with AMT (alongside the ME), whereas
+ the 32Mb chips contain only the ME.
+
sgsit said this: There are problems with the DMAR table and I get a kernel panic with KVM but day to day it's fine with no ME or microcode.
+
+
Usual limitations apply for native graphics initialization (no VBT and/or INT10H and only GRUB works so no BIOS, so no DOS/Windows support
+ - who cares? There is no system but GNU, and Linux is one of it's kernels).
+
+
When connecting the AC adapter while system is powered off, system will then power on. This probably happens in coreboot aswell.
+ It's a minor annoyance, but it should be fixed (if it's not already fixed by now).
+
+
This method of disabling the ME leaves the flash descriptor and gbe in place (non-functional data, fully documented)
+ and disables the ME using soft straps. This means that the gigabit ethernet will still work (putting the machine in
+ non-descriptor mode would wipe it out, not to mention require hardware modifications that most users will be unwilling to make).
+
+
+
+
+
+
Early development notes
+
+
+ There is a tool called FITC which contains all the descriptor manipulation tools. This is what sgsit used initially;
+ it's proprietary software, for Windows, but it was useful for liberating the X200 and making it a real target in
+ libreboot. End justified means, and the software is no longer needed.
+
+
+
+<sgsit> here's some output:
+Was a paste link. putting it here instead:
+
+Start (hex) End (hex) Length (hex) Area Name
+----------- --------- ------------ ---------
+00000000 003FFFFF 00400000 Flash Image
+
+00000000 00000FFF 00001000 Descriptor Region
+00000004 0000000F 0000000C Descriptor Map
+00000010 0000001B 0000000C Component Section
+00000040 0000004F 00000010 Region Section
+00000060 0000006B 0000000C Master Access Section
+00000060 00000063 00000004 CPU/BIOS
+00000064 00000067 00000004 Manageability Engine (ME)
+00000068 0000006B 00000004 GbE LAN
+00000100 00000103 00000004 ICH Strap 0
+00000104 00000107 00000004 ICH Strap 1
+00000200 00000203 00000004 MCH Strap 0
+00000EFC 00000EFF 00000004 Descriptor Map 2
+00000ED0 00000EF7 00000028 ME VSCC Table
+00000ED0 00000ED7 00000008 Flash device 1
+00000ED8 00000EDF 00000008 Flash device 2
+00000EE0 00000EE7 00000008 Flash device 3
+00000EE8 00000EEF 00000008 Flash device 4
+00000EF0 00000EF7 00000008 Flash device 5
+00000F00 00000FFF 00000100 OEM Section
+00001000 001F5FFF 001F5000 ME Region
+001F6000 001F7FFF 00002000 GbE Region
+001F8000 001FFFFF 00008000 PDR Region
+00200000 003FFFFF 00200000 BIOS Region
+
+
+<sgsit> this is the one that's running on my machine at the moment:
+Was a paste link. Putting here instead:
+
+Start (hex) End (hex) Length (hex) Area Name
+----------- --------- ------------ ---------
+00000000 003FFFFF 00400000 Flash Image
+
+00000000 00000FFF 00001000 Descriptor Region
+00000004 0000000F 0000000C Descriptor Map
+00000010 0000001B 0000000C Component Section
+00000040 0000004F 00000010 Region Section
+00000060 0000006B 0000000C Master Access Section
+00000060 00000063 00000004 CPU/BIOS
+00000064 00000067 00000004 Manageability Engine (ME)
+00000068 0000006B 00000004 GbE LAN
+00000100 00000103 00000004 ICH Strap 0
+00000104 00000107 00000004 ICH Strap 1
+00000200 00000203 00000004 MCH Strap 0
+00000ED0 00000EF7 00000028 ME VSCC Table
+00000ED0 00000ED7 00000008 Flash device 1
+00000ED8 00000EDF 00000008 Flash device 2
+00000EE0 00000EE7 00000008 Flash device 3
+00000EE8 00000EEF 00000008 Flash device 4
+00000EF0 00000EF7 00000008 Flash device 5
+00000EFC 00000EFF 00000004 Descriptor Map 2
+00000F00 00000FFF 00000100 OEM Section
+00001000 00002FFF 00002000 GbE Region
+00003000 00202FFF 00200000 BIOS Region
+
+Build Settings
+--------------
+Flash Erase Size = 0x1000
+
+
+
+Tool used:
+<sgsit> it's called 'Flash Image Tool' from the 4.x package
+<sgsit> you drag a complete image into it and the the tool decomposes the various components
+<sgsit> and allows you to set the soft straps
+
+This tool is proprietary, for Windows only, but was used to deblob the X200. End justified by means, and
+the utility is no longer needed (sgsit's ich9deblob utility documented at the top of the page is now
+used to create deblobbed descriptors).
+
+
+<sgsit> this is the only content:
+Was a paste link. putting it here instead:
+
+00 1F 1F 1F 1F 1F 00 08 FF FF 83 10 FF FF FF FF
+08 10 FF FF C3 10 EE 20 AA 17 F5 10 86 80 00 00
+01 0D 00 00 00 00 05 06 20 30 00 0A 00 00 8B 8D
+02 06 40 2B 43 00 00 00 F5 10 AD BA F5 10 BF 10
+AD BA CB 10 AD BA AD BA 00 00 00 00 00 00 00 00
+00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+00 01 00 40 28 12 07 40 FF FF FF FF FF FF FF FF
+FF FF FF FF FF FF FF FF FF FF FF FF FF FF D9 F0
+20 60 1F 00 02 00 13 00 00 80 1D 00 FF 00 16 00
+DD CC 18 00 11 20 17 00 DD DD 18 00 12 20 17 00
+00 80 1D 00 00 00 1F
+
+<sgsit> the first part is the MAC address which I've set to all 0x1F
+<sgsit> it's repeated half way through the 8k area. the rest is 0xFF
+<sgsit> it's not a blob - i've just found the intel docs with the full spec of the data there
+<sgsit> thanks to mtjm: http://www.intel.co.uk/content/dam/doc/application-note/i-o-controller-hub-9m-82567lf-lm-v-nvm-map-appl-note.pdf
+<sgsit> so we have a mostly functional libre x200
+<sgsit> just need to sort some ACPI issues
+
+
+
+ The GBe region starts at 0x20A000 bytes from the *end* of a factory image and is 0x2000 bytes long.
+ In libreboot (deblobbed) the descriptor is set to put it directly after the initial 4K flash descriptor.
+ So the first 4K of the ROM is the descriptor, and then the next 8K is the gbe region.
+
+
+
+<sgsit> interesting fact about the gbe checksum: it's supposed to add up to 0xBABA (in honour of Baba O'Reilly apparently) but it is actually 0x3ABA
+<sgsit> either the checksum doesn't matter or the MSB of the checksum isn't checked. strange though
+<sgsit> https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums
+<sgsit> "One of those engineers loves classic rock music, so he selected 0xBABA"
+<sgsit> 0xBABA and 0x3ABA only differ by the most significant bit.
+
+<sgsit> the checksum in the GBe region of my X200S is 0x34BA
+<sgsit> when it should be 0xBABA
+34BA is BABA in L33T speak. 3=B and 4=A. Thus, 34BA=BABA
+Apparently these intel people have a sense of humour.
+
patch the number of regions present in the descriptor from 5 - 3
+
originally descriptor + bios + me + gbe + platform
+
modified = descriptor + bios + gbe
+
the next stage is to patch the part of the descriptor which defines the start and end point of each section
+
then cut out the gbe region and insert it just after the region
+
all this can be substantiated with public docs (ICH9 datasheet)
+
the final part is flipping 2 bits. Halting the ME via 1 MCH soft strap and 1 ICH soft strap
+
the part of the descriptor described there gives the base address and length of each region (bits 12:24 of each address)
+
to disable a region, you set the base address to 0xFFF and the length to 0
+
and you change the number of regions from 4 (zero based) to 2
+
+
+
+ There's an interesting parameter called 'ME Alternate disable', which allows the ME to only handle hardware errata in the southbridge,
+ but disables any other functionality. This is similar to the 'ignition' in the 5 series and higher but using the standard firmware
+ instead of a small 128K version. Useless for libreboot, though.
+
+
+
+ To deblob the x200, you chop out the platform and ME regions and correct the addresses in flReg1-4.
+ Then you set meDisable to 1 in ICHSTRAP0 and MCHSTRAP0.
+
+
+
How to patch the descriptor from the factory.rom dump
+
+
map the first 4k into the struct (minus the gbe region)
+
set NR in FLMAP0 to 2 (from 4)
+
adjust BASE and LIMIT in flReg1,2,3,4 to reflect the new location of each region (or remove them in the case of Platform and ME)
+
set meDisable to 1/true in ICHSTRAP0 and MCHSTRAP0
+
extract the 8k GBe region and append that to the end of the 4k descriptor
+
output the 12k concatenated chunk
+
Then it can be dd'd into the first 12K part of a coreboot image.
+
the GBe region always starts 0x20A000 bytes from the end of the ROM
+
+
+
+<sgsit> the data in the descriptor is little endian
+<sgsit> and it represents bits 24:12 of the address (bits 12-24. written as 24:12 since bit 24 is more nearer to left than bit 12)
+<sgsit> so x << 12 = address
+--
+<sgsit> if it is in descriptor mode, the first 4 bytes will be 5A A5 F0 0F
+--
+<fchmmr> so there are just 3 regions in libreboot (X200) rom then:
+<fchmmr> * descriptor (4K)
+<fchmmr> * gbe (8K)
+<fchmmr> * bios (rest of flash chip. CBFS also set to occupy this whole size)
+
+
+
+
+
+
+
platform data partition in boot flash (factory.rom / lenovo bios)
+
+
+ Basically useless for libreboot. Removing it didn't cause any issues.
+
+
+
+<mtjm> sgsit: thanks; have you checked what platform data partition has? my notes state that it has only a 448 byte fragment different from 0x00 or 0xff
+<sgsit> mtjm: the contents of mine from the stock rom are here:
+Was a paste link. Moving it here:
+
+53 FC 75 06 91 CA FA 62 91 27 D9 BF 59 93 A6 03
+38 FA 2E 96 02 8C BD 1D F5 5F A6 6A 87 30 47 45
+25 70 9A 60 B9 62 FD 9D 64 E1 88 37 FB 59 17 C2
+91 B0 A5 25 26 9B 36 44 85 09 E4 02 CC 91 28 8F
+01 FF 22 D9 7B AA 61 97 5B E6 EE 7D CD F2 7F B1
+83 74 36 88 6B 4C 4F D5 DF 11 1E DF C0 D9 87 48
+CA DC 57 B7 F9 65 E4 E5 78 BA 90 78 D7 1E CB 3B
+C3 8E 34 27 B9 B7 29 3D AA 53 96 0B 7D F7 47 82
+C6 E2 08 CD 94 49 10 C4 6D BD B2 2F BD 84 1B 20
+EC 8C 7E 33 6A B0 20 8D A4 7C 10 61 AD 11 66 BA
+8F B1 07 B1 52 C2 F0 B7 88 BB 3A 6F 27 8F C1 EA
+F7 BF 82 11 92 39 44 51 AB 19 25 2B 8A 7A D1 66
+2B 82 FF CE C7 EC 78 E2 9F 47 BE C2 37 F7 5A 2E
+A6 57 B6 B3 66 2B 2D 33 20 C6 4D F7 26 41 57 70
+DC 04 42 39 BD B8 96 71 3E B1 9C 13 76 BF E2 AC
+DD 65 E1 82 D6 46 F3 39 EA B5 FE F6 56 3F B9 67
+DE 5E 08 8B 00 77 D9 94 D0 16 F0 97 BF A6 44 3A
+C1 27 22 E1 7C DD 2F 15 A1 D5 53 61 2A 37 F8 E1
+94 8E 1F 3D 8F 79 08 37 09 45 AC 1B 33 75 FB 3D
+1D 6E 67 22 3D C3 90 B4 F8 9E 31 09 6F 70 1F BC
+9E 48 29 A0 1F 29 5E 1B B5 D3 C3 D7 6C 14 AE 63
+FE F3 3A 23 98 78 4C C9 7E 9E F0 A4 72 9F FF 25
+CC 6F 2B D1 41 27 00 A5 79 4A 37 D3 83 63 32 89
+FB 03 2C AE 6B 33 31 1A 5A A2 A8 C5 5E 1F A5 BD
+40 A7 76 7D A9 AC AC 18 21 6D F6 74 7D 18 19 C4
+DE 6D D1 55 A0 C9 2C FD 6A 56 BB 1B 08 C1 B6 60
+16 B7 EB D3 8B D8 BC 41 5F D6 86 A5 45 F8 A7 99
+68 6E EA 4D EA B6 39 6E 9B 5D 0E 58 9B D8 00 00
+
+<sgsit> i've removed it - doesn't seem to have had any ill effect
+<sgsit> the region is 32k but like yours the rest of it is 0x00 or 0xFF
+<mtjm> mine is different; maybe it's just something that the BIOS used
+<sgsit> i think that's the case
+
+
+
+
+
+
+
New targets
+
+
+R400, R500
+T400, T400s, T500
+W500
+X200, X200s, X200 Tablet, X301
+^ these are other gm45 targets for coreboot (not yet ported at the time of writing) that could be in libreboot one day
+^ some of them have ATI or Intel graphics. Avoid ATI (proprietary video bios rom needed)
+
+<sgsit> from the mailing list where somebody was enquiring abouy an R400 port:
+<sgsit> Your dmidecode.log shows that you have DDR2 memory.
+<sgsit> Sadly, our current GM45 chipset code does only support DDR3 (which is used in the Roda RK9).
+<sgsit> If this isn't a fault in your DMI tables and you really have DDR2 memory, porting coreboot will be especially hard (some more month of extra)
+<sgsit> re DDR3 on the R400, that's really weird
+<sgsit> mtjm will be able to confirm but maybe there's something messed up in the HW of the R400 because it reports DDR2
+text/r400/r400_dmidecode.txt is dmidecode output from factory bios on R400.
+
+Some of them use DDR2 memory, or DDR3 memory that is detected as DDR2, or they are GS45 chipset. Basically, some of
+them involve the hell of getting raminit right. but these are all fine targets that could be ported to coreboot
+based on the X200 port.
+
+
+
+
+
+
+
Unsorted notes
+
+
+<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 machines like this
+<sgsit> all the Wistron manufactured machines 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
+
+
+
+ sgsit couldn't use vt-x without microcode updates. setting vm to have 1 core made vm kernel panic.
+ setting vm to use 2 cores made host kernel panic. Might be possible to workaround this in qemu.
+ according to sgsit (if not, just use software-only virtualization, no acceleration)
+ http://download.intel.com/design/mobile/specupdt/320121.pdf
+
+
+
+
+
+
+
X200S and X200T
+
+
+ Only X200 is known to work so far. X200S and X200 Tablet have raminit issues at the time of writing
+ (GS45 chipset. X200 is GM45).
+
+
+
+X200S issues (X200T probably also affected):
+<sgsit> fchmmr: some light reading - https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf
+<sgsit> mentions RCOMP which is the current stumbling block
+<sgsit> oh god - SFF platform unsupported in write i/o initialization.
+<sgsit> i think the X200S is doomed
+<sgsit> hi. i've just flashed the X200 image to an X200S and i'm getting the error "SFF platform unsupported in RCOMP initialization." after "Setting IGD memory frequencies for VCO #1.". can anyone point me in the right direction to resolve this?
+<sgsit> full log here: text/x200s/cblog00.txt
+<sgsit> i've tried many different SODIMM combinations
+<PaulePanter> sgsit: src/northbridge/intel/gm45/raminit.c: die("SFF platform unsupported in RCOMP initialization.\n");
+<PaulePanter> sgsit: Check the source why it gets there. Found with `git grep "SFF platform"`.
+<sgsit> PaulePanter: thanks, i'll investigate
+<sgsit> PaulePanter: damn, looks like GS45 is unsupported
+<sgsit> pgeorgi: do you know if adding RCOMP and write i/o init support to GS45 is going to be a nightmare? or is it a matter of studying datasheets? did you write the GM45 raminit code?
+<pgeorgi> sgsit: I helped write some parts, but nico was the principal author
+<pgeorgi> sgsit: I think the ddr3 side is pretty complete
+<fchmmr> nico_h ?
+<sgsit> pgeorgi: is it possible that GM45 is marked as unsupported because it wasn't able to be tested?
+<sgsit> *GS45
+<pgeorgi> sgsit: we wrote that specifically for gm45. gs45 is unsupported because nobody ever cared for it
+<sgsit> i know that GS45 only supports 1066/1333 and GM45 supports 800 too. i wonder if that points to big differences in the ram init code
+<pgeorgi> fchmmr: nico_h, yes
+<sgsit> sorry i meant 667/800/1066
+<pgeorgi> sgsit: everything is possible. my approach on this (absent reasonable datasheet access) would be to trace the vendor bios with serialice, then compare against the gm45 code, since it's probably somewhat similar
+<sgsit> pgeorgi: thanks for the advice. you've given me hope
+<pgeorgi> of course, after testing that the current gm45 code isn't just blocked by something trivial (eg. a pci id test)
+<sgsit> yes, i was going to try removing the die command first.. the laptop i'm working on has a WSON-8 flash chip so i'm going to have to get the soldering iron out again. boo
+<kmalkki> sgsit: some lenovo boards have WSON-8 and SOIC-8 layout on the PCB in parallel
+<kmalkki> sgsit: does the silk screen have SPI1 and SPI2 ?
+<sgsit> kmalkki: on the X200S the land array can take a SOIC-8 too. i don't (yet) have a hot air rework tool though
+<sgsit> only thing is the supported SOIC-8 chips on that board are all 4MiB
+<kmalkki> sgsit: you can switch from WSON-8 to SOIC-8 if you have matching IDs on the SPI flash part
+<kmalkki> vendor bios might care, but for coreboot and flashrom you can switch to different SPI part entirely
+<sgsit> but i was looking forward to having loads of free space to do interesting things with
+<kmalkki> several options for 8MiB in SOIC-8
+<sgsit> kmalkki: sorry, i hadn't realised the significance of what you were saying. i actually have some new MX25L6445EM2I-10G here which i could probably swap over then. would flashing internally, using the ICH be a problem?
+<kmalkki> sgsit: change of SPI flash part may confuse vendor BIOS and may require (simple) coreboot and flashrom development work
+<kmalkki> sgsit: internal flashing is only issue once your system boots to OS
+<sgsit> fchmmr: i have renewed hope for the X200S. after digging through the datasheet, i've discovered that the GS45 operates in 2 modes.
+<sgsit> low and high performance
+<sgsit> low performance uses the SU range of ultra-low voltage chips eg SU9400
+<sgsit> my X200S has an SL9400 which is in the high-performance category
+<sgsit> from the docs, the GS45 behaves just like the GM45 when it's in high performance mode.
+<sgsit> i expect / hope that the coreboot devs were wary of the other mode. with any luck, if i remove the checks (or hardcode the sff param to 0) the board may just boot up. i may have time to try this later
+<sgsit> <fchmmr> I take it that the low-performance ones still wouldn't work, so for now you'd have to be careful to get one that has a particular cpu in it.
+<sgsit> that's my assumption
+<sgsit> orly_owl: no, i don't think so. the ulv cpus run at a different voltage. this is good news though, unless you buy an SUxxxx model
+<sgsit> fchmmr: my hand crafted and untested patch for raminit.c:
+<sgsit> ---
+<sgsit> 113
+<sgsit> +++ sysinfo->gs45_low_power_mode = 1;
+<sgsit> 113 sysinfo->gs45_low_power_mode = 0;
+<sgsit> ---
+<sgsit> 1696 const int sff = sysinfo->gfx_type == GMCH_GS45;
+<sgsit> +++
+<sgsit> 1696 const int sff = sysinfo->gfx_type == GMCH_GS45 && sysinfo->gs45_low_power_mode = 1;
+<sgsit> * 1696 const int sff = sysinfo->gfx_type == GMCH_GS45 && sysinfo->gs45_low_power_mode == 1;
+<sgsit> i'll try it later
+<sgsit> it assumes that GS45 is in high performance mode rather than low power which is no good for the masses
+<sgsit> fchmmr: progress ;)
+<sgsit> text/x200s/cblog01.txt
+<sgsit> doesn't like my 2GB dimms but it at least boots with 2x4GB
+<sgsit> haven't put it back together yet so no idea if it's stable
+<sgsit> note line 12 - GMCH: GS45, using high performance mode by default
+<sgsit> with the patch i wrote blind earlier
+<sgsit> needs testing
+<sgsit> may be barely functional
+<sgsit> and has problems with some SODIMMS
+<sgsit> text/x200s/cblog02.txt (2x2GB)
+<sgsit> text/x200s/cblog03.txt (1x2GB)
+<sgsit> the GS45 in high performance mode is just a shrunken GM45 afaict
+
+ This document is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See ../../license.txt for more information.
+
+
+
+
diff --git a/docs/install/images/x200/5252_bbb0.jpg b/docs/install/images/x200/5252_bbb0.jpg
new file mode 100644
index 0000000..8232d8d
--- /dev/null
+++ b/docs/install/images/x200/5252_bbb0.jpg
Binary files differ
diff --git a/docs/install/images/x200/5252_bbb1.jpg b/docs/install/images/x200/5252_bbb1.jpg
new file mode 100644
index 0000000..a4e72e2
--- /dev/null
+++ b/docs/install/images/x200/5252_bbb1.jpg
Binary files differ
diff --git a/docs/install/images/x200/mat.jpg b/docs/install/images/x200/mat.jpg
new file mode 100644
index 0000000..6a62f4e
--- /dev/null
+++ b/docs/install/images/x200/mat.jpg
Binary files differ
diff --git a/docs/install/images/x200/psu_jumper_leads.jpg b/docs/install/images/x200/psu_jumper_leads.jpg
new file mode 100644
index 0000000..04bbf30
--- /dev/null
+++ b/docs/install/images/x200/psu_jumper_leads.jpg
Binary files differ
diff --git a/docs/install/images/x200/psu_power.jpg b/docs/install/images/x200/psu_power.jpg
new file mode 100644
index 0000000..c85bb34
--- /dev/null
+++ b/docs/install/images/x200/psu_power.jpg
Binary files differ
diff --git a/docs/install/images/x200/psu_screws_removed.jpg b/docs/install/images/x200/psu_screws_removed.jpg
new file mode 100644
index 0000000..e9ab9d7
--- /dev/null
+++ b/docs/install/images/x200/psu_screws_removed.jpg
Binary files differ
diff --git a/docs/install/images/x200/strap.jpg b/docs/install/images/x200/strap.jpg
new file mode 100644
index 0000000..39a23b1
--- /dev/null
+++ b/docs/install/images/x200/strap.jpg
Binary files differ
diff --git a/docs/install/images/x200/stripped_jumper_lead.jpg b/docs/install/images/x200/stripped_jumper_lead.jpg
new file mode 100644
index 0000000..54373a0
--- /dev/null
+++ b/docs/install/images/x200/stripped_jumper_lead.jpg
Binary files differ
diff --git a/docs/install/images/x200/wson_soldered.jpg b/docs/install/images/x200/wson_soldered.jpg
new file mode 100644
index 0000000..9a964a2
--- /dev/null
+++ b/docs/install/images/x200/wson_soldered.jpg
Binary files differ
diff --git a/docs/install/images/x200/x200_pomona.jpg b/docs/install/images/x200/x200_pomona.jpg
new file mode 100644
index 0000000..602fe1b
--- /dev/null
+++ b/docs/install/images/x200/x200_pomona.jpg
Binary files differ
diff --git a/docs/install/index.html b/docs/install/index.html
index bfae94e..7bd670d 100644
--- a/docs/install/index.html
+++ b/docs/install/index.html
@@ -26,6 +26,7 @@
+ This guide is for those who want libreboot on their ThinkPad X200
+ while they still have the original Lenovo BIOS present. This guide
+ can also be followed (adapted) if you brick your X200, to know how
+ to recover.
+
+
+
+ The X200S is also briefly covered (image showing soldering joints, wired up
+ to a BBB). Note, the X200S and X200T are unsupported both in coreboot an libreboot at the time of writing (raminit doesn't work). This info
+is just for future reference. Only the X200 is supported.
+
+
+
+ Before following this section, please make sure to setup your libreboot ROM properly first.
+ Although ROM images are provided pre-built in libreboot, there are some modifications that
+ you need to make to the one you chose before flashing. (instructions referenced later in
+ this guide)
+
+ 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 (8 pins), 8MiB
+ is SOIC-16 (16 pins). The X200S uses a WSON package and has the same
+ pinout as SOIC-8 (covered briefly later on in this guide) but
+ the chip is on the underside of the board (disassembly required).
+
+
+
+ Shopping list (pictures of this hardware is shown later):
+
+
+
+ External SPI programmer: BeagleBone Black (rev. C)
+ is highly recommended. Sometimes referred to as 'BBB'.
+
+
+ Clip for connecting to the flash chip: Pomona 5250
+ (SOIC-8) or Pomona 5250 (SOIC-16) is recommended
+
+
+ External 3.3V DC power supply. The one used by this
+ author has the label HF100W-SF-3.3 on it, but any decent
+ supply will be fine. Some people use the 3.3V from an ATX
+ PSU for instance (the kind that you get on a typical
+ Intel/AMD desktop computer. 6A supply should be fine,
+ the one used by this author is 20A (it won't actually use
+ that, it's just what the PSU is capable of).
+
+
+ Dupont jumper cables (the kinds of cables that you see
+ used on the pins on a raspberry pi - note: the pi is
+ proprietary and not endorsed by libreboot, merely refered
+ to in this instance to let you know the type of cables.
+ You should get male-male, male-female and female-female
+ cables in 10cm and 20cm sizes.
+
+
+ Mini USB A-B cable (the BeagleBone probably already comes
+ with one.)
+
+
+ FTDI serial board, for unbricking the BeagleBone if
+ necessary.
+
+
+ 5V DC power supply (from wall outlet to the BeagleBone).
+ The BeagleBone can have power supplied via USB, but a
+ dedicated power supply is recommended.
+
+ With my PSU, first I had wire up the mains power cable. Any clover or kettle lead will do. Cut the end off (not the one
+ that goes in the wall, but the kettle/clover connector).
+ Strip the protection away by a decent length, then strip the wires inside so that a decent amount of
+ copper is shown. Then wire up earth/live/neutral. This will vary according to what country you live in
+ and/or the colour codes that your cable uses inside. Make sure to get this right, as a botched job
+ could result in extreme damage to you and your surroundings. Here's what mine looks like after wiring up
+ the power cable: images/x200/psu_power.jpg - also, make sure
+ that the plug (for the wall) has the correct fuse. In my case I had a 240V wall socket, and the device
+ says that it accepts 1.5A at that voltage, so I used the smallest fuse available (3A). For 110-120V the device
+ says it needs 2.8A. Also, if yours looks like in the image linked above, make sure to wrap electrical tape (lots)
+ around it for safety. (otherwise, don't touch the terminals while the PSU is plugged in).
+
+
+ Now take a red and black 20cm female-female jumper lead, and cut one of the ends off. Strip away the bare copper by about 1 or
+ 1.5cm so you get this: images/x200/stripped_jumper_lead.jpg.
+
+
+ Black goes on -V, red goes on +V. In my case, I removed those screws from my PSU like this:
+ images/x200/psu_screws_removed.jpg. Then,
+
+
+ Then I twisted the exposed copper on the jumper leads (so that they don't fray), and wrapped each to one of the
+ screws each, around it near the head. I then screwed them in:
+ images/x200/psu_jumper_leads.jpg.
+
+
+ If you are using a different PSU, then the steps will change from those above. Anyway, once you are satisfied,
+ continue reading...
+
+
Setting up the BBB
+
+ Since it's a bare board (no case) and you are also touching inside your X200, you should be earthed/grounded.
+ images/x200/strap.jpg shows how I earthed myself. This is to prevent you
+ from causing any ESD damage. The surface that you place components on should also be earthed/grounded.
+ (for this, I used a shielded ESD bag with a wire, copper exposed, attached from the bag to the exposed metal
+ part on a radiator, which was earthed - not professional, but it should work. see images/x200/mat.jpg).
+ Most people ignore this advice and don't ground/earth themselves, at their own risk. You should also store the BBB
+ in a shielded anti-static bag when you are finished with it.
+ (the principles above apply to any computer components, since they are extremely sensitive te ESD).
+
+
+ These instructions may or may not work for you. They are simply the steps that this author took.
+
+
+ setting up SPIDEV on the BBB: http://elinux.org/BeagleBone_Black_Enable_SPIDEV#SPI0
+ - If you only setup SPI0, you don't have to disable the HDMI out. (you only need one).
+ That guide is for seting up the device overlay for SPIDEV, last part is to make it persist across reboots.
+ Needed to turn the BBB into an SPI flasher.
+
+ You need to update the software on the BBB first. Before being able to use apt-get,
+ I had to use the workaround defined here:
+ - Replace the contents of /etc/init.d/led_aging.sh with:
+
+
+#!/bin/sh -e
+### BEGIN INIT INFO
+# Provides: led_aging.sh
+# Required-Start: $local_fs
+# Required-Stop: $local_fs
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: Start LED aging
+# Description: Starts LED aging (whatever that is)
+### END INIT INFO
+
+x=$(/bin/ps -ef | /bin/grep "[l]ed_acc")
+if [ ! -n "$x" -a -x /usr/bin/led_acc ]; then
+ /usr/bin/led_acc &
+fi
+
+
+ Run apt-get update and apt-get upgrade then reboot the BBB, before continuing.
+
+
+ Run those commands:
+ # echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots
+ Then I did:
+ # ls -al /dev/spidev0.*
+ ls: cannot access /dev/spidev0.*: No such file or directory
+ Then I rebooted and did:
+ # cat /sys/devices/bone_capemgr.*/slots
+ Output:
+
+ Now the BBB is ready to be used for flashing. Make this persist
+ across reboots:
+ In /etc/default/capemgr add CAPE=BB-SPI0-01 at the end
+ (or change the existing CAPE= entry to say that, if an
+ entry already exists.
+
+
+ Now you will download and build flashrom on the BBB.
+ # apt-get install libpci-dev pciutils zlib1g-dev libftdi-dev build-essential subversion
+ # svn co svn://flashrom.org/flashrom/trunk flashrom
+ # cd flashrom/
+ # make
+
+
+
+ Now test flashrom:
+ # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
+ Output:
+
+
+Calibrating delay loop... OK.
+No EEPROM/flash device found.
+Note: flashrom can never write if the flash chip isn't found automatically.
+
+
+
+ This means that it's working (the clip isn't connected to any flash chip,
+ so the error is fine).
+
+ The following shows how to connect clip to the BBB (on the P9 header), for SOIC-16 (clip: Pomona 5252):
+
+
+=== front (display) ====
+ NC - - 21
+ 1 - - 17
+ NC - - NC
+ NC - - NC
+ NC - - NC
+ NC - - NC
+ 18 - - 3.3V PSU RED
+ 22 - - NC - this is pin 1 on the flash chip
+=== back (palmrest) ===
+This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
+
+
+ The following shows how to connect clip to the BBB (on the P9 header), for SOIC-8 (clip: Pomona 5250):
+
+
+=== front (display) ====
+ 18 - - 1
+ 22 - - NC
+ NC - - 21
+ 3.3V PSU RED - - 17 - this is pin 1 on the flash chip
+=== back (palmrest) ===
+This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
+On the X200S (not fully covered in this guide) the flash chip is underneath the board, in a WSON package.
+The pinout is very much the same as a SOIC-8, except you need to solder (there are no clips available).
+images/x200/wson_soldered.jpg (image copyright (C) 2014 Steve Shenton under CC-BY-SA 4.0
+or higher, same license that this document uses) shows it wired (soldered) and
+connected to a BBB. Note, the X200S and X200T are unsupported both in coreboot an libreboot at the time of writing (raminit doesn't work). This info
+is just for future reference.
+
+
+ NC = no connection
+
+
+ DO NOT connect 3.3V PSU RED yet. ONLY connect this once the pomona is connected to the flash chip.
+
+
+ You also need to connect the BLACK wire from the 3.3V PSU to pin 2 on the BBB (P9 header). It is safe to install this now.
+
+
+ if you need to extend the 3.3v psu leads, just use the same colour M-F leads, but keep all other
+ leads short (10cm or less)
+
+ Connect Pomona 5252/5250 to the X200 flash chip, and dump/flash
+
+
+ images/x200/x200_pomona.jpg
+ shows everything connected. In this picture, the X200 is being flashed
+ with the BBB.
+
+
+ Remove the battery from your X200, then remove all the screws on
+ the bottom (underside) of the machine. Then remove the keyboard and palmrest.
+ The flash chip is below the palm rest. Lift back the tape that goes over it,
+ and then connect your 5252/5250 (make sure to get it the right way round).
+ Then connect the 3.3v PSU wire (red one) and make sure that everything else is connected.
+
+
+ I did:
+ # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
+ In my case, the output was:
+
+
+flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
+flashrom is free software, get the source code at http://www.flashrom.org
+Calibrating delay loop... OK.
+Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
+Found Macronix flash chip "MX25L6406E/MX25L6436E" (8192 kB, SPI) on linux_spi.
+Found Macronix flash chip "MX25L6445E/MX25L6473E" (8192 kB, SPI) on linux_spi.
+Multiple flash chip definitions match the detected chip(s): "MX25L6405(D)", "MX25L6406E/MX25L6436E", "MX25L6445E/MX25L6473E"
+Please specify which chip definition to use with the -c <chipname> option.
+
+
+ This is just to test that it's working. In my case, I had to define which chip to use, like so (in your case
+ it may be different, depending on what flash chip you have):
+ # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -c "MX25L6405(D)"
+
+
+ At this point, you need to create a copy of the original lenovo firmware that is currently flashed.
+ This is so that you can extract the gbe (gigabit ethernet) and flash descriptor regions for use in libreboot. These
+ are not blobs, they only contain non-functional data (configuration details, fully readable) which is fully documented in public datasheets.
+ The descriptor will need to be modified
+ to disable the ME (also disable AMT) so that you can flash a ROM that excludes it.
+
+
+ How to backup factory.rom (change the -c option as neeed, for your flash chip):
+ # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -c "MX25L6405(D)" -r factory.rom
+ # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -c "MX25L6405(D)" -r factory1.rom
+ # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -c "MX25L6405(D)" -r factory2.rom
+ Now compare the 3 images:
+ # sha512sum factory*.rom
+ If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another machine, not
+ the BBB). You will need it later for part of the deblobbing.
+
+
+ Information about the descriptor and gbe can be found in the notes linked at
+ ../hcl/x200_remove_me.html - also shows how to modify them to disable and remove the ME/AMT blob.
+ MAKE SURE TO FOLLOW THE GUIDE IN THIS LINK, BEFORE CONTINUING.
+ FAILURE TO DO SO WILL RESULT IN A BRICKED MACHINE.
+
+
+ Assuming that your libreboot ROM image is properly setup (modified descriptor plus gbe region included in the ROM),
+ then you can flash (assuming that the filename is libreboot.rom) for example I had to do:
+ # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -c "MX25L6405(D)" -w libreboot.rom
+
+
+ You might see errors, but if it says Verifying flash... VERIFIED at the end, then it's flashed and should boot.
+ Test it! (boot your X200)
+
+
+ My output when running the command above:
+
+
+flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
+flashrom is free software, get the source code at http://www.flashrom.org
+Calibrating delay loop... OK.
+Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
+Reading old flash chip contents... done.
+Erasing and writing flash chip... FAILED at 0x00001000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xd716
+ERASE FAILED!
+Reading current flash chip contents... done. Looking for another erase function.
+Erase/write done.
+Verifying flash... VERIFIED.
+
+ This document is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See ../license.txt for more information.
+