Bricked Lenovo T60

[Damien Zammit]

Hi folks,

Thanks #coreboot for all your help with my laptop, I learnt a lot today
from you all.
Unfortunately my first attempt at installing coreboot has resulted in a
bricked laptop.

I tried to cheat by making an educated guess of the SPI chip model
without pulling my laptop to bits to verify.  However, it seemed right
according to the responses i was getting from flashrom -V for the failed
chips, since the manufacturer id and model id I was getting from
flashrom matched the datasheet specs for a particular chip.

I downloaded and compiled the crossgcc toolchain.

I created a patch for flashrom and proceeded to read my flash.
I got a successful read from flashrom and dumped my vgabios.

I compiled coreboot for T60 and followed the wiki grabbing the 3 patches
for Lenovo stuff and inserting my custom SMBIOS details in the config.

Once i felt happy with my coreboot.rom I followed exactly the procedure
on the coreboot Lenovo wiki to flash my laptop internally.

I have attached here the coreboot config i used, the clues I used to
write the flashrom patch, the flashrom patch i wrote, and the flashing
log.

My current T60 status is "Bricked, in Bucts 1 configuration"

I guess my next step is to pull my laptop to bits without removing the
CMOS battery and see if the flash chip is indeed the one that I
estimated, and perhaps reflash it with coreboot?  I'm not too sure what
to do next but GNUtoo from #coreboot recommends a poloma clip.  Coreboot
team were very very helpful in trying everything to help me and warned
me right at the start I needed a way to recover.  They were right!

Damien

[Tim Zander]

> My current T60 status is "Bricked, in Bucts 1 configuration"

I'm not sure what you did, but if this was you flashchips.c:
>            .model_id       = SST_SST25VF016B_T60,
>            .probe          = probe_spi_res2,
>            .read           = spi_chip_read,

then things were wrong:

Change the .probe field to probe_spi_res1
Change the .model_id field to the RES1 ID given in the datasheet of the 
flash chip
Change the .write field to spi_chip_write_1

Tim

[Carl-Daniel Hailfinger]

Hi,

Am 17.06.2013 23:25 schrieb Tim Zander:
> Am 17.06.2013 01:23 schrieb Damien Zammit:
> > My current T60 status is "Bricked, in Bucts 1 configuration"
>
> I'm not sure what you did, but if this was you flashchips.c:
> >            .model_id       = SST_SST25VF016B_T60,
> >            .probe          = probe_spi_res2,
> >            .read           = spi_chip_read,
>
> then things were wrong:

Only partially.
> Change the .probe field to probe_spi_res1

No, probe_spi_res2 is correct.
> Change the .model_id field to the RES1 ID given in the datasheet of
> the flash chip

The datasheet is clear on that: The RES ID is 2-byte.
> Change the .write field to spi_chip_write_1

Yes, that one indeed should have been spi_chip_write_1.

I'm sorry we didn't catch the usage of the wrong write function before
you reflashed.

Regards,
Carl-Daniel

[Gerd Hoffmann]

Hi,
> > Change the .write field to spi_chip_write_1
>
> Yes, that one indeed should have been spi_chip_write_1.

Sucessfully flashed coreboot, thanks to patch Damien mail and this
correction.  Yay!

A few questions:

As I understand it the long procedere with bucts and dd'ing around the
top 64k of the image is only needed to deal with the restrictions
applied by the factory bios.  Once running on coreboot I can update to a
newer build with flashrom without any tricks needed.  Correct?

How can I test stuff without risking to lock out myself?  I guess the
fallback mechanism is meant to be used for that?  Having a known-good
build in "fallback" and the freshly coded stuff in "normal"?  Now the
big question is how can I switch the payload to fallback in case the
normal payload doesn't boot so I can't simply run nvramtool for that?

thanks,
  Gerd

[Denis 'GNUtoo' Carikli]

On Fri, 21 Jun 2013 16:07:27 +0200
Gerd Hoffmann  wrote:
> Hi,

Hi,
> > > Change the .write field to spi_chip_write_1
> >
> > Yes, that one indeed should have been spi_chip_write_1.
>
> Sucessfully flashed coreboot, thanks to patch Damien mail and this
> correction.  Yay!
>
> A few questions:
>
> As I understand it the long procedere with bucts and dd'ing around the
> top 64k of the image is only needed to deal with the restrictions
> applied by the factory bios.  Once running on coreboot I can update
> to a newer build with flashrom without any tricks needed.  Correct?

Correct.
> How can I test stuff without risking to lock out myself?  I guess the
> fallback mechanism is meant to be used for that?  Having a known-good
> build in "fallback" and the freshly coded stuff in "normal"?

yes.
> Now the
> big question is how can I switch the payload to fallback in case the
> normal payload doesn't boot so I can't simply run nvramtool for that?

I'm not sure,

The issue is that if you have no way to recover, you really should find
a way to make sure the fallback mecanism work when you need it:
The thing to check is that, when it doesn't reach the payload, and you
power the machine off, it has to load the fallback the next boot.
I'm not sure it works, it should be tested.
However I know how to compile such image...
I already documented it here: http://www.coreboot.org/Fallback_mechanism

The issue is to really be sure that the switch between normal and
fallback occur when you need it...

An easy *and reliable* way to do that would be to do a patch for
coreboot that add a cmos.defaults file (the testing of the patch
requires to disassemble the laptop).

Once that is done an easy way to recover without an external programmer
would be to remove the CMOS battery: once the CMOS battery is removed,
the nvram content would be lost and the default restored(because of the
patch).
The defaults would of course boot on fallback...

The issue is that it still requires to disassemble the laptop in order
to remove that CMOS battery...
However it would be very reliable...

I've tried the default->fallback mecanism long time ago on my X60, when
the cmos.default patch wasn't created yet, I don't remember well becaus
e it was a long time ago, but it seems that it worked when I tested it
but not when I needed it to work...

There are also alternatives to the default/fallback but they are for
the payload only:
The idea is to have a coreboot and a first payload that are known to
work, and make the first payload load another payload.
* I've tested that with SeaBIOS( it's documented in the wiki here:
http://www.coreboot.org/SeaBIOS#Adding_payloads and probably require a
recent enough SeaBIOS).
* I've also tested it with grub as a payload.

Also note that when you select SeaBIOS master in make menuconfig of
coreboot, it will checkout the last revision of SeaBIOS each time...
So if you have a working configuration and you rebuild it later... it's
not guaranteed to work if you select SeaBIOS master in make menuconfig.

Denis.

[ron minnich]

the question about fallback is 'when do I tell the machine that the
normal boot succeeded'? At LANL, we learned the best place: as LATE in
the boot process as possible, long after LInux is up. You want to be
sure, if you set 'booted ok', that it is LINUX that booted ok, not
just coreboot. That's a key piece.

Because if coreboot sets 'booted ok', and then the node doesn't boot,
that's not doing you much good, is it? We learned that the hard way.

So: only linux boot scripts get to set 'normal booted ok', and that
should be the last thing you do
and
many things get to clear 'normal booted ok', including linux, the
payload, and coreboot itself.

But if you do it, of course, you want to always be sure the 'fallback
image' is a good one :-)

ron