On Fri, 21 Jun 2013 16:07:27 +0200 Gerd Hoffmann kraxel@redhat.com 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.