ThinkPad T500/W500

Edit this page -- Back to previous index

NOTE: At this time, 18 March 2021, only W500 is supported, but T500 is trivial to add (just need a config). W500 is basically the same board as the T500, but with an ATI graphics chip in addition to Intel (in osboot, the ATI one is not enabled by default, and the intel GPU is used). W500 comes with a higher resolution screen than the T500.

There are two possible flash chip sizes for the T500/W500: 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. You could de-solder the default chip and install a 16MiB one if you wanted to (16MiB is the maximum size supported, either SOIC8 or SOIC16. The machine has pads for both, but only one can be used at any given time).

The T500/W500 laptops come with the ME (and sometimes AMT in addition) before flashing osboot. osboot disables and removes it by using a modified descriptor: see ../install/ich9utils.html

Installation instructions

If running Lenovo BIOS, you need to disassemble and remove the mainboard. Follow this document: https://tim.id.au/laptops/lenovo/thinkpad%20t500%20w500.pdf

The flash chip is either a 4MiB SOIC8 or 8MiB SOIC16. Follow this guide: Reprogramming SPI 25XX NOR flash with Raspberry Pi

Be sure to read the notes about ich9gen, to change the default MAC address which is embedded into the ROM image that you flash: How to change the default ICH9M GbE MAC address

If you’re already running coreboot/osboot/libreboot, and you don’t have flash protection enabled, you can flash internally from flashrom in GNU+Linux running on your machine. See: How to update an existing installation

NOTE: Intel PHY is present, so you should use one of the 12KiB images that ich9gen generates. This contains the GbE region with a working NVM (non volatile memory) image inside, for NIC configuration. You should change the default MAC address! Use the --macaddress argument when running ich9gen!

Be very sure of this, otherwise you might accidentally use a GbE-less descriptor generated by ich9gen (which is a thing. Technically, Gbe-less descriptor is pointless but it was implemented by ich9gen as an option, for purely academic purposes and R500 thinkpads in osboot use those GbE-less images; you can tell because those ones are 4KiB instead of 12KiB).

EC update

It is recommended that you update to the latest EC firmware version. The EC firmware is separate from osboot, so we don’t actually provide that, but if you still have Lenovo BIOS then you can just run the Lenovo BIOS update utility, which will update both the BIOS and EC version. See:

NOTE: this can only be done when you are using Lenovo BIOS. How to update the EC firmware while running osboot is unknown. osboot only replaces the BIOS firmware, not EC.

Updated EC firmware has several advantages e.g. better battery handling.

Compatibility (without blobs)

Hardware virtualization (vt-x)

The T500/W500, 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 osboot), make sure that the kvm and kvm_intel kernel modules are not loaded, when using QEMU, if you don’t have microcode updates.

The following errata datasheet from Intel might help you learn something: http://download.intel.com/design/mobile/specupdt/320121.pdf

NOTE: osboot comes with microcode updates by default, for all ROM images. In fact, it’s official policy of the project to include them when available. It is irresponsible not to include them; the machines are in an unknown and unreliable state without them! However, anecdotal reports from Libreboot are that these machines can work well enough without them, should you wish to delete them from your ROM.

At present, this is the only binary blob added on GM45 laptops like W500/T500.

This means that KVM is safe to use, if you wish to use hardware assisted virtualization software, but only if you have the microcode updates.

Edit this pageLicenseTemplateAuthorsDonateBuy preinstalled

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 this license is found in /docs/fdl-1.3.html