[coreboot] Bricked Lenovo T60
Denis 'GNUtoo' Carikli
GNUtoo at no-log.org
Fri Jun 21 17:30:10 CEST 2013
On Fri, 21 Jun 2013 16:07:27 +0200
Gerd Hoffmann <kraxel at redhat.com> wrote:
> >> 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?
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
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.
More information about the coreboot