Board:lenovo/x200: Difference between revisions

From coreboot
Jump to navigation Jump to search
(good shit)
Line 30: Line 30:
* digitizer on x200t variant (probably doesn't work)
* digitizer on x200t variant (probably doesn't work)


== X200S and X200 Tablet ==


== proprietary components status ==
These use the GS45 chipset which is very similar to GM45 chipset that the X200 uses. Boards with the SL* CPUs (so-called "high-performance") are compatible with GM45, and can be enabled in coreboot.
* CPU microcode
 
* VGA option rom (optional): you need it if you want graphics in SeaBIOS but most payloads should work without it (text mode or corebootfb mode)
[http://review.coreboot.org/#/c/7786/ This patch on gerrit] enables GS45 chipset and makes the X200S or X200 Tablet work, if it has the "high-performance" CPU. SL model (CPU) is compatible, SU is not.
* ME(Management Engine) (optional) => can be removed by modifying the flash descriptor.
 
Both the X200S and X200 Tablet use a WSON-8 package for the flash chip. This has the same pinout as a SOIC-8 flash chip, but you will need to solder some (very thin) wires to a pin header since no clips are available for this type of connection.
 
[http://libreboot.org/docs/install/images/x200/wson_soldered.jpg Here is an example]
 
Regular X200 laptops will use either a SOIC-8 or SOIC-16 connection (recommended for average users, who most likely do not want to solder).
 
== Proprietary components status ==
* CPU microcode (optional*):
* VGA option rom (optional): you need it if you want graphics in SeaBIOS but most payloads should work without it (text mode** or corebootfb mode)
* ME(Management Engine) (optional) => can be removed by using a modified flash descriptor (see notes below about the ich9gen utility)
* EC(Embedded Controller) =>  you do not have to touch it(just leave it where it is)
* EC(Embedded Controller) =>  you do not have to touch it(just leave it where it is)


== Flashing ==
-* Many machines were tested without it and did not show any issues that most users would notice. The only minor issue reported by 1 user is that vt-x (hardware-assisted virtualization) stopped working without the update, but otherwise the machine boots and works reliably.
First flashing needs to be external. I use buspirate and pomona clip (SOIC-16)
 
-** text-mode native gfx init is currently broken on the X200, but framebuffer mode (what most people use) works. This will need to be investigated.
 
== Dumping the original firmware ==
First flashing needs to be external. phcoder used the buspirate and a pomona 5252 clip (SOIC-16). For SOIC-8 flash chips, you can use the Pomona 5250.
 
Unless modified (through the descriptor), the X200 flash as shipped by Lenovo is divided in 5 parts.
 
For systems with the 8MiB flash chip:
 
* Descriptor (4K) - first region
* ME (also includes AMT) (6100K) - 2nd region
* Gbe (8K) - 3rd region
* Platform (32K) - 4th region
* BIOS (2M) - 5th region


Flash in X200 is divided roughly in 4 parts:
For systems with the 4MiB flash chip:


* Descriptor (12K)
* Descriptor (4K) - first region
* ME firmware (6M-12K)
* ME (no AMT) (2004K) - 2nd region
* Rewriteable flash (2M-128K)
* Gbe (8K) - 3rd region
* Locked bootblock (128K)
* Platform (32K) - 4th region
* BIOS (2M) - 5th region
 
Flash chip sizes can be identified through flashrom. Generally, the following is true:
 
* SOIC-8  = 4MiB (rare on these machines)
* SOIC-16 = 8MiB (common on these machines)


<gallery>
<gallery>
Line 53: Line 84:
</gallery>
</gallery>


Descriptor and bootblock are read-only. ME firmware is not readable.
The descriptor and ME regions are read-only. ME firmware is not readable.
Rewriteable region can be rewritten easily with flashrom.


For coreboot we need to preserve descriptor and ME firmware while overwriting
All regions are re-writeable with an external SPI flasher, and the descriptor can be modified to unlock these regions (see notes about ich9gen below) for Host CPU / BIOS.
rewriteable region and bootblock. To achieve this there are 2 ways:


* External flasher.
For coreboot we need to preserve at least the descriptor and Gbe regions while overwriting the flash chip contents. To achieve this there are 2 ways:
* Unlock bootblock


For the first one proceeds as follows:
* External flasher (most reliable method known at this time).
* Turn off your laptop, remove battery and AC adapter.
* Unlock bootblock (method unknown at this time)
 
For the first method, proceed as follows:
* Turn off your laptop
* Remove the battery and AC adapter.
* Remove the keyboard.
* Remove the keyboard.
* Connect your external SPI flasher to the SPI chip which is under palmrest,
* Connect your external SPI flasher to the SPI chip which is underneath the palmrest, around the position of the trackpoint under a protective layer.  
around the position of trackpoint under protective layer.  
 
Depending on the flasher that you use, you may need a separate +/- 3.3V DC power source (make sure not to feed any more than this).
phcoder used the buspirate and for 3.3V DC he used an ATX PSU.
 
The pinout is as follows (colours are based on the buspirate):


I recommend using SOIC-16 clip. Depending on the flasher you use, you may have to use separate
3.3V source. Make sure not to feed more than 3.3V ot the chip. I used
buspirate as flasher and 3.3V power lines from ATX PSU.
The pinout is as follows, the colors are buspirate colors
   ===  front (display) ====
   ===  front (display) ====
   NC              -      - MISO (black)
   NC              -      - MISO (black)
Line 79: Line 111:
   NC              -      - NC
   NC              -      - NC
   NC              -      - NC
   NC              -      - NC
   MOSI (gray)    -      - 3.3V (red)
   MOSI (gray)    -      - +3.3V (red)
   violet (SCLK)  -      - NC
   violet (SCLK)  -      - NC
   ===  back (palmrest) ===
   ===  back (palmrest) ===
 
+3.3v (red) must ONLY be connected once the clip is connected, and make sure that the -3.3v is also connected beforehand.
NEVER connect +3.3v (red) prior to the other connections on your flash chip / programmer.


* I wasn't able to eliminate interference in my setup (you may have better luck), so it worked only on 30kHz. Adding battery increased quality somewhat. Read the flash. Twice. Compare the files to be sure. Save a copy of it on
* phcoder wasn't able to eliminate interference in his setup (you may have better luck), so it worked only on 30kHz; adding a battery increased the quality slightly. Read the flash twice, and compare (sha512sum) the files to be sure. Save a copy of the dump onto
external media. Due to interference I reread it 10 times, 2 were corrupted.
external media. Due to interference it had to be read about 10 times, 2 of which were corrupted.
  flashrom -p <yourprogrammer> -r flash.bin
  flashrom -p <yourprogrammer> -r flash.bin
  flashrom -p <yourprogrammer> -r flash2.bin
  flashrom -p <yourprogrammer> -r flash2.bin
  diff flash.bin flash2.bin
  diff flash.bin flash2.bin


An alternative flashing guide (uses BeagleBone Black instead of Bus Pirate for faster, more reliable flashing) can be found at the libreboot website:
[http://libreboot.org/docs/install/x200_external.html Flashing the X200 with a BBB]


See also [http://flashrom.org/ISP In-System Programming]
See also [http://flashrom.org/ISP In-System Programming]


== Flashing your coreboot ROM image ==
You cannot simply build the image and flash it, without first including several other "regions" that are discussed below.


* Recover descriptor and me firmare:
=== With ME/AMT (inadvisable) ===
 
The following method involves extracting the descriptor, Gbe, ME and Platform regions from the original firmware and placing them (unmodified) inside the coreboot image.
 
In this setup, every region is present:
* Descriptor - copied from original firmware (config data, describes regions in the boot flash and so on)
* ME - copied from original firmware (intel management engine. huge blob. can be removed, see next section)
* Gbe - copied from original firmware (configuration data for the onboard ethernet chipset, also contains your MAC address)
* Platform - copied from original firmware (contents unknown)
* BIOS (where coreboot goes)
 
For the 8MiB flash chip:
 
* Recover the descriptor, me, gbe and platform data:
   dd if=flash.bin of=descriptor_me.bin count=6 bs=1M
   dd if=flash.bin of=descriptor_me.bin count=6 bs=1M
* Compile coreboot
* Compile coreboot
* Put descriptor and me back:
* Put descriptor and me back:
   dd if=descriptor_me.bin of=build/coreboot.rom bs=1M conv=notrunc
   dd if=descriptor_me.bin of=build/coreboot.rom bs=1M conv=notrunc
* Flash the resulting build/coreboot.rom. If it fails due to interference, try again, and again. It took me ~10 times.
 
For the 4MiB flash chip:
 
* Recover the descriptor, me, gbe and platform data:
  dd if=flash.bin of=descriptor_me.bin count=2 bs=1M
* Compile coreboot
* Put descriptor and me back:
  dd if=descriptor_me.bin of=build/coreboot.rom bs=1M conv=notrunc
 
* Flash the resulting build/coreboot.rom. If it fails due to interference, then try again many times until it works.
 
=== Without ME/AMT (highly recommended) ===
 
It is possible to boot without the ME, by using a modified descriptor region.
 
The ME is a serious security and privacy risk, so removing it is preferable. Removing it also means that the BIOS region can fill most of the flash chip, giving plenty of flashing space (example use-case scenario: BusyBox+Linux system in SPI flash, to be used as a live rescue system).
 
Download the libreboot source code at [http://libreboot.org/docs/release.html the release page] or the metadata through git (git clone http://libreboot.org/libreboot.git) and
you will find ich9gen under resources/utilities/ich9deblob/. Alternatively, ich9gen is included statically compiled in the binary releases under ./ich9deblob/
 
Use the ich9gen utility from the libreboot project, to generate a descriptor and Gbe region (the utility generates them from scratch, without needing a factory.rom dump). In this setup, the following regions are enabled:
 
* Descriptor (4K) - data created in ich9gen goes here (config data, describes regions in the boot flash, etc)
* Gbe (8K) - data created in ich9gen goes here (config data for the onboard ethernet chipset, also contains your MAC address)
* BIOS (8180K or 4084K, depending on whether the machine has a 4MiB or 8MiB flash chip) - coreboot goes here
 
In menuconfig, set the size of CBFS (in bytes, in hex) to 8MiB - 12KiB, or 4MB - 12KiB depending on whether you have a 4MiB or 8MiB flash chip.
 
Note your machines current MAC address (for the onboard ethernet chipset) and keep this information safe. It should be printed below the DDR3 modules, which are accessible by removing two screws and a door on the underside of the machine.
 
Build your coreboot image as usual, and generate the 12KiB descriptor+gbe file as follows (replace the XX characters with those from your MAC address):
./ich9gen --macaddress XX:XX:XX:XX:XX:XX
 
The files ich9fdgbe_8m.bin and ich9fdgbe_4m.bin will have been generated by ich9gen.
 
For the 8MiB flash chip:
dd if=ich9fdgbe_8m.bin of=build/coreboot.rom bs=1 count=12k conv=notrunc
For the 4MiB flash chip:
dd if=ich9fdgbe_4m.bin of=build/coreboot.rom bs=1 count=12k conv=notrunc
 
ich9gen is available in libreboot binary releases as static binaries, or as source under resources/utilities/ich9deblob/ under libreboot src or git.
 
More information about ich9gen at the [http://libreboot.org/docs/hcl/x200_remove_me.html#ich9gen libreboot project website]
 
Libreboot also distributes pre-compiled X200 ROM images in the binary archive, built from libreboot sources with the descriptor
and Gbe already included inside the ROM images (generated from ich9gen). However, do note that the Gbe region will contain a default MAC address
other than what you probably want to use. Before using this, in the libreboot_bin or src/git (if you built everything yourself) you can run:
 
./ich9macchange XX:XX:XX:XX:XX:XX
 
(replace the XX characters with those from your MAC address)
 
After doing this, the the ROM images will have a correct Gbe region inside containing your MAC address.
 
By default, the ich9gen utility generates a descriptor with all regions writeable from the Host CPU / BIOS. You can optionally write-protect
the flash chip (or select regions) by modifying ich9gen; see src/ich9gen/mkdescriptor.c. '''If you write-protect your flash chip, it will mean that external flashing is needed later on when you want to re-flash those regions.'''
 
You can learn about the descriptor/Gbe region contents by reading the ich9gen/ich9deblob source code in libreboot under resources/utilities/ich9deblob/
 
== Internal flashing ==
 
Once coreboot is installed and running, internal flashing should be easier.
 
If the read/write bits in flmstr1 (see ich9gen src) are all set to 1, it means that '''-p internal''' in flashrom should work such that re-flashing in hardware is no longer necessary.
 
If there are locked regions (as defined in the descriptor), then you will still need to unlock them by re-flashing a modified descriptor externally. However, flashrom can still flash to those regions which are not currently set to read-only.
 
At the time of writing, flashrom did not yet have a whitelist for the ThinkPad X200. If that is the case with your version of flashrom, you can use '''-p internal:laptop=force_I_want_a_brick'''.
 
If you need the whitelist patch, apply this to the file board_enable.c then re-compile flashrom:
 
[http://paste.debian.net/plain/141084 X200 flashrom whitelist]
 
=== Other flashrom patches (optional) ===
 
Most X200 laptops use one of the Macronix flash chips. Those chips will be detected several times, forcing you to use the -c parameter for selecting a flash chip.
 
One easy and permanent way to avoid this is to remove those definitions that are redundant to you (this method is inappropriate for upstream).


Apply the following patch to flashchips.c: [http://paste.debian.net/141086/ for purging redundant flash chip definitions]


== Research ==
== Research ==
* [[Board:lenovo/x200/internal_flashing_research| Research to get more details on the BIOS updates mecanism]]
* [[Board:lenovo/x200/internal_flashing_research| Research to get more details on the BIOS updates mecanism]]

Revision as of 18:08, 24 January 2015

Status

Thanks for your interest in Lenovo X200 port. Works:

  • USB
  • Audio (internal speakers, internal mic, headphones, external mic)
  • WLAN (first minipcie slot)
  • WWAN (second minipcie slot)
  • UWB (third minipcie slot)
  • SD card slot
  • LAN
  • Battery and AC indicator
  • Thermal
  • EEPROM
  • Linux (through GRUB-as-payload)
  • trackpoint
  • keyboard
  • Bluetooth
  • LID
  • Video (internal panel and VGA)
  • Hotkeys
  • Fingerprint reader.
  • Windows (through GRUB-as-payload loading SeaBIOS image from disk; you have to use extracted VGA blob, dumped from memory isn't good enough)
  • suspend to RAM (S3)
  • Expresscard slot (including hotplug)
  • Wake on LID, wake on Fn.
  • Dock

Untested:

  • Modem (probably works)
  • digitizer on x200t variant (probably doesn't work)

X200S and X200 Tablet

These use the GS45 chipset which is very similar to GM45 chipset that the X200 uses. Boards with the SL* CPUs (so-called "high-performance") are compatible with GM45, and can be enabled in coreboot.

This patch on gerrit enables GS45 chipset and makes the X200S or X200 Tablet work, if it has the "high-performance" CPU. SL model (CPU) is compatible, SU is not.

Both the X200S and X200 Tablet use a WSON-8 package for the flash chip. This has the same pinout as a SOIC-8 flash chip, but you will need to solder some (very thin) wires to a pin header since no clips are available for this type of connection.

Here is an example

Regular X200 laptops will use either a SOIC-8 or SOIC-16 connection (recommended for average users, who most likely do not want to solder).

Proprietary components status

  • CPU microcode (optional*):
  • VGA option rom (optional): you need it if you want graphics in SeaBIOS but most payloads should work without it (text mode** or corebootfb mode)
  • ME(Management Engine) (optional) => can be removed by using a modified flash descriptor (see notes below about the ich9gen utility)
  • EC(Embedded Controller) => you do not have to touch it(just leave it where it is)

-* Many machines were tested without it and did not show any issues that most users would notice. The only minor issue reported by 1 user is that vt-x (hardware-assisted virtualization) stopped working without the update, but otherwise the machine boots and works reliably.

-** text-mode native gfx init is currently broken on the X200, but framebuffer mode (what most people use) works. This will need to be investigated.

Dumping the original firmware

First flashing needs to be external. phcoder used the buspirate and a pomona 5252 clip (SOIC-16). For SOIC-8 flash chips, you can use the Pomona 5250.

Unless modified (through the descriptor), the X200 flash as shipped by Lenovo is divided in 5 parts.

For systems with the 8MiB flash chip:

  • Descriptor (4K) - first region
  • ME (also includes AMT) (6100K) - 2nd region
  • Gbe (8K) - 3rd region
  • Platform (32K) - 4th region
  • BIOS (2M) - 5th region

For systems with the 4MiB flash chip:

  • Descriptor (4K) - first region
  • ME (no AMT) (2004K) - 2nd region
  • Gbe (8K) - 3rd region
  • Platform (32K) - 4th region
  • BIOS (2M) - 5th region

Flash chip sizes can be identified through flashrom. Generally, the following is true:

  • SOIC-8 = 4MiB (rare on these machines)
  • SOIC-16 = 8MiB (common on these machines)

The descriptor and ME regions are read-only. ME firmware is not readable.

All regions are re-writeable with an external SPI flasher, and the descriptor can be modified to unlock these regions (see notes about ich9gen below) for Host CPU / BIOS.

For coreboot we need to preserve at least the descriptor and Gbe regions while overwriting the flash chip contents. To achieve this there are 2 ways:

  • External flasher (most reliable method known at this time).
  • Unlock bootblock (method unknown at this time)

For the first method, proceed as follows:

  • Turn off your laptop
  • Remove the battery and AC adapter.
  • Remove the keyboard.
  • Connect your external SPI flasher to the SPI chip which is underneath the palmrest, around the position of the trackpoint under a protective layer.

Depending on the flasher that you use, you may need a separate +/- 3.3V DC power source (make sure not to feed any more than this). phcoder used the buspirate and for 3.3V DC he used an ATX PSU.

The pinout is as follows (colours are based on the buspirate):

 ===  front (display) ====
 NC              -       - MISO (black)
 ground (brown)  -       - CS (white)
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 MOSI (gray)     -       - +3.3V (red)
 violet (SCLK)   -       - NC
 ===  back (palmrest) ===
 

+3.3v (red) must ONLY be connected once the clip is connected, and make sure that the -3.3v is also connected beforehand.

NEVER connect +3.3v (red) prior to the other connections on your flash chip / programmer.

  • phcoder wasn't able to eliminate interference in his setup (you may have better luck), so it worked only on 30kHz; adding a battery increased the quality slightly. Read the flash twice, and compare (sha512sum) the files to be sure. Save a copy of the dump onto

external media. Due to interference it had to be read about 10 times, 2 of which were corrupted.

flashrom -p <yourprogrammer> -r flash.bin
flashrom -p <yourprogrammer> -r flash2.bin
diff flash.bin flash2.bin

An alternative flashing guide (uses BeagleBone Black instead of Bus Pirate for faster, more reliable flashing) can be found at the libreboot website: Flashing the X200 with a BBB

See also In-System Programming

Flashing your coreboot ROM image

You cannot simply build the image and flash it, without first including several other "regions" that are discussed below.

With ME/AMT (inadvisable)

The following method involves extracting the descriptor, Gbe, ME and Platform regions from the original firmware and placing them (unmodified) inside the coreboot image.

In this setup, every region is present:

  • Descriptor - copied from original firmware (config data, describes regions in the boot flash and so on)
  • ME - copied from original firmware (intel management engine. huge blob. can be removed, see next section)
  • Gbe - copied from original firmware (configuration data for the onboard ethernet chipset, also contains your MAC address)
  • Platform - copied from original firmware (contents unknown)
  • BIOS (where coreboot goes)

For the 8MiB flash chip:

  • Recover the descriptor, me, gbe and platform data:
 dd if=flash.bin of=descriptor_me.bin count=6 bs=1M
  • Compile coreboot
  • Put descriptor and me back:
 dd if=descriptor_me.bin of=build/coreboot.rom bs=1M conv=notrunc
 

For the 4MiB flash chip:

  • Recover the descriptor, me, gbe and platform data:
 dd if=flash.bin of=descriptor_me.bin count=2 bs=1M
  • Compile coreboot
  • Put descriptor and me back:
 dd if=descriptor_me.bin of=build/coreboot.rom bs=1M conv=notrunc
 
  • Flash the resulting build/coreboot.rom. If it fails due to interference, then try again many times until it works.

Without ME/AMT (highly recommended)

It is possible to boot without the ME, by using a modified descriptor region.

The ME is a serious security and privacy risk, so removing it is preferable. Removing it also means that the BIOS region can fill most of the flash chip, giving plenty of flashing space (example use-case scenario: BusyBox+Linux system in SPI flash, to be used as a live rescue system).

Download the libreboot source code at the release page or the metadata through git (git clone http://libreboot.org/libreboot.git) and you will find ich9gen under resources/utilities/ich9deblob/. Alternatively, ich9gen is included statically compiled in the binary releases under ./ich9deblob/

Use the ich9gen utility from the libreboot project, to generate a descriptor and Gbe region (the utility generates them from scratch, without needing a factory.rom dump). In this setup, the following regions are enabled:

  • Descriptor (4K) - data created in ich9gen goes here (config data, describes regions in the boot flash, etc)
  • Gbe (8K) - data created in ich9gen goes here (config data for the onboard ethernet chipset, also contains your MAC address)
  • BIOS (8180K or 4084K, depending on whether the machine has a 4MiB or 8MiB flash chip) - coreboot goes here

In menuconfig, set the size of CBFS (in bytes, in hex) to 8MiB - 12KiB, or 4MB - 12KiB depending on whether you have a 4MiB or 8MiB flash chip.

Note your machines current MAC address (for the onboard ethernet chipset) and keep this information safe. It should be printed below the DDR3 modules, which are accessible by removing two screws and a door on the underside of the machine.

Build your coreboot image as usual, and generate the 12KiB descriptor+gbe file as follows (replace the XX characters with those from your MAC address):

./ich9gen --macaddress XX:XX:XX:XX:XX:XX

The files ich9fdgbe_8m.bin and ich9fdgbe_4m.bin will have been generated by ich9gen.

For the 8MiB flash chip:

dd if=ich9fdgbe_8m.bin of=build/coreboot.rom bs=1 count=12k conv=notrunc

For the 4MiB flash chip:

dd if=ich9fdgbe_4m.bin of=build/coreboot.rom bs=1 count=12k conv=notrunc

ich9gen is available in libreboot binary releases as static binaries, or as source under resources/utilities/ich9deblob/ under libreboot src or git.

More information about ich9gen at the libreboot project website

Libreboot also distributes pre-compiled X200 ROM images in the binary archive, built from libreboot sources with the descriptor and Gbe already included inside the ROM images (generated from ich9gen). However, do note that the Gbe region will contain a default MAC address other than what you probably want to use. Before using this, in the libreboot_bin or src/git (if you built everything yourself) you can run:

./ich9macchange XX:XX:XX:XX:XX:XX

(replace the XX characters with those from your MAC address)

After doing this, the the ROM images will have a correct Gbe region inside containing your MAC address.

By default, the ich9gen utility generates a descriptor with all regions writeable from the Host CPU / BIOS. You can optionally write-protect the flash chip (or select regions) by modifying ich9gen; see src/ich9gen/mkdescriptor.c. If you write-protect your flash chip, it will mean that external flashing is needed later on when you want to re-flash those regions.

You can learn about the descriptor/Gbe region contents by reading the ich9gen/ich9deblob source code in libreboot under resources/utilities/ich9deblob/

Internal flashing

Once coreboot is installed and running, internal flashing should be easier.

If the read/write bits in flmstr1 (see ich9gen src) are all set to 1, it means that -p internal in flashrom should work such that re-flashing in hardware is no longer necessary.

If there are locked regions (as defined in the descriptor), then you will still need to unlock them by re-flashing a modified descriptor externally. However, flashrom can still flash to those regions which are not currently set to read-only.

At the time of writing, flashrom did not yet have a whitelist for the ThinkPad X200. If that is the case with your version of flashrom, you can use -p internal:laptop=force_I_want_a_brick.

If you need the whitelist patch, apply this to the file board_enable.c then re-compile flashrom:

X200 flashrom whitelist

Other flashrom patches (optional)

Most X200 laptops use one of the Macronix flash chips. Those chips will be detected several times, forcing you to use the -c parameter for selecting a flash chip.

One easy and permanent way to avoid this is to remove those definitions that are redundant to you (this method is inappropriate for upstream).

Apply the following patch to flashchips.c: for purging redundant flash chip definitions

Research