Board:lenovo/x60/Installation: Difference between revisions

From coreboot
Jump to navigation Jump to search
(picture guides for unbricking)
Line 52: Line 52:
== Recovery ==
== Recovery ==
If you had a bad flash you will need a recovery method.
If you had a bad flash you will need a recovery method.
The libreboot project has picture guides showing disassembly and external flashing instructions:
* [http://libreboot.org/docs/howtos/x60_unbrick.html X60/X60s unbricking guide]
* [http://libreboot.org/docs/howtos/x60tablet_unbrick.html X60 Tablet unbricking guide]
* [http://libreboot.org/docs/howtos/t60_unbrick.html T60 unbricking guide]
The guides linked above are based on the information below:


If you only set bucts, then rebooted without doing any flash writes, things might be easier:
If you only set bucts, then rebooted without doing any flash writes, things might be easier:

Revision as of 11:55, 23 September 2014

Coreboot Installation for T60, X60/X60s and X60 Tablet

Flashing Procedure (with Libreboot Tools)

The Libreboot project (coreboot distro), has created some helpful tools that simplify the installation process, and comes with pre-compiled ROM images for the X60/X60s, X60 Tablet and T60.

Libreboot X60/T60 Flashing Guide

NOTE: If flashing libreboot on a T60, make sure it has an Intel GPU (not ATI), and that it has one of these supported LCD panels.

NOTE: These instructions do not involve backup up factory.bin (original Lenovo BIOS). If you want to be able to re-flash Lenovo BIOS later, follow the tutorial below up to step 2. The libreboot project distributes patches for flashrom already, with scripts to build the patched executables.

Flashing Procedure (Advanced)

Lenovo X60, X60s, X60 tablet, T60 and T60p flashing instructions.

See Build HOWTO for how to build ROM images in coreboot.

These Lenovo laptops have a register bit that must be flipped before coreboot can be flashed.

For those/some models with SPI flash chips you have also to modify flashrom. Because the chipset locks down the available commands that flashrom can send to the flash chip, you also need to change the flashrom source in a way that is not suitable to upstream. Flash chips can be identified by various commands (REMS*, RDID etc.). Some of them reply with an ID for the vendor and the exact chip model; others just reply with a single byte which is fine if there is only a small number of chips to distinguish, but won't work for the huge number of flash chips known to flashrom. The problem with the vendor BIOS is that it forbids the higher quality identification commands, so you need to force flashrom to use the lower quality opcode for the chip in your Thinkpad. You have to know the chip model beforehand (e.g. by inspection). Known models on the x60s are SST25VF016B, MX25L1605D and maybe others.

You will need: the flashrom source (at least r1613 to make sure the laptops are whitelisted to work with flashrom), a small modification of it (as explained below in detail), the datasheet of your flash chip retrieve the right values for the modification, and the bucts utility.

  1. Patch flashrom to use RES SPI identification and spi_chip_write_1 for your flash chip, as well as change the flash chip model id to fit the RES opcode.
    • Find the definition of your flash chip in flashrom's flashchips.c
      • Optionally, you can copy the existing definition as it is done in this patch. This will allow to switch between the two definitions with the -c parameter. Be sure to change the .name field in that case (e.g. .name = "SST25VF016B-RES",).
    • Change the .probe field to probe_spi_resN where N equals the number of ID bytes the flash replies to the RES ID command (opcode 0xAB, look it up in the chip's datasheet) (e.g. .probe = probe_spi_res2, if the chip replies with one byte vendor ID and one byte model ID)
    • Change the .model_id field to the RES model ID given in the datasheet of the flash chip (e.g. .model_id = 0x14,)
    • Change the .write field to spi_chip_write_1 (i.e. .write = spi_chip_write_1,)
  2. Run flashrom -p internal -r factory.bin
    This step is IMPORTANT since the factory BIOS in your machine is tied to your particular system board (or "planar" in IBM FRU terms) with a unique ID not present in factory BIOS updates.
  3. Run dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
  4. Run dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
    Verify that the complete range is filled with ff bytes before proceeding! The above command must output:
    0000000 ffff ffff ffff ffff ffff ffff ffff ffff
    *
    0010000
    If this is not the case, the coreboot image needs to be rebuilt with the second-to-last 64kbyte block unused.
  5. Run dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
  6. Run bucts 1
  7. Run flashrom -p internal -w coreboot.rom
    This will be slow, it will output errors for addresses 0x0 and 0x1f0000 when working with a 2 Mbyte flash chip, and it will say "FAILED!" at the end, see Peter's mail before you panic.
  8. Power cycle the machine (i.e. a cold boot, not just a reboot), now starting with coreboot
  9. Revert all changes made to flashrom (maybe backup the binary for later experiments)
  10. Run flashrom -p internal -w coreboot.rom.
    This will successfully overwrite the entire flash chip, including the last 64k that were write protected with the factory BIOS.
  11. Run bucts 0


See also http://thread.gmane.org/gmane.linux.bios/69354 http://thread.gmane.org/gmane.linux.bios.flashrom/575

Recovery

If you had a bad flash you will need a recovery method.

The libreboot project has picture guides showing disassembly and external flashing instructions:

The guides linked above are based on the information below:

If you only set bucts, then rebooted without doing any flash writes, things might be easier: bucts sets a register that lives on the RTC well, ie. it is powered by the same source that keeps the clock alive. Usually that's a battery on the mainboard, and often there's some way to cut the source (by removing the battery, a jumper, or pads that can be shorted). After doing that (for a few seconds, there might be some capacitors in the way that keep power stable), the register should be reset and the system should boot as normal.

On the x60x, bucts issues might also be solved by "discarging RTC", which is done by pressing the power button 5 times for 10 seconds.

Required/advised hardware and informations

Howto

0. wire the pomona clip to a programmer that way:

From the #coreboot IRC Channel on FreeNode servers:

Oct 01 15:35:48 <CareBear\>     one important thing is that when you connect the clip to the X60 you should not connect all pins
[...]
Oct 01 15:36:22 <CareBear\>     only connect these pins: 1, 2, 4, 5, 6
[...]
Oct 01 15:37:21 <CareBear\>     also important: first connect charger to laptop, then connect the clip
[...]
Oct 01 17:49:41 <CareBear\>     GNUtoo-desktop : the mainboard must be powered off, but with the charger connected
[...]
Oct 01 17:50:39 <CareBear\>     um, that way there is no way anything will break
[...]
Oct 01 17:51:00 <CareBear\>     it is important not to connect 3v3 from the outside
Oct 01 17:51:39 <CareBear\>     because the correct power sequencing is not known, and if any other rail must come on before the standby 3v3 then the machine may well break when 3v3 is applied from the outside
[...]
Oct 01 17:52:48 <CareBear\>     it may also be fine - but it is unknown what happens
[...]
Oct 01 17:53:47 <CareBear\>     not supplying 3v3 from the outside is safer
Oct 01 17:54:25 <CareBear\>     and because the machine is powered off, there is no risk of the chipset accessing the flash chip

In another hand I didn't follow that and wired it without powering the mainboard(mainboard disconnected from power plug, no battery in) and with all pins and it worked...

  1. Disassemble carefully the laptop, the SO-8 chip is on the bottom of the mainboard...
  2. connect the pomona clip to the BIOS chip
  3. flash coreboot or the BIOS
  4. remount the laptop

See also In-System Programming

Coreboot standard configuration

  • It's now the default that when running SeaBios, that it (instead of coreboot) runs the VGA option rom.

See VGA_support for details on how to include the VGA BIOS image.

VBIOS replacement (native graphics)

The VGA option ROM (see above) is proprietary. Under devices in menuconfig, disable loading option ROM,s and enable 'Native graphics initialization'. Use the GRUB payload.

TODO: add notes here for how to patch coreboot for T60 native graphics (it's in libreboot already, or on 5345 on coreboot gerrit).

Recently tested revisions on the X60

See the most recent board-status submissions

970ad7076388b3ef98988121170df86196d493b4 coreboot-4.0-5534-g970ad70

8496c4dbec41b3a9284fc29b0dcd97fc8946223b coreboot-4.0-5045-g9bf05de

Recently tested revisions on the T60

See the most recent board-status submisssions

a172ea546992c3f6f6a99b4dbaabbdae4c959707 4.0-5611-ga172ea5

9bf05de5ab2842fc83cea8da5e9058417fc4bc24 4.0-5045-g9bf05de

Status