Hi,
I carefully followed the instructions by Peter Stuge: http://comments.gmane.org/gmane.linux.bios/69354
Used latest git flashrom and coreboot with Thinkpad X60s 1702WNQ. Got this error:
pierce# ../flashrom/flashrom -p internal:laptop=force_I_want_a_brick -w build/coreboot.rom flashrom v0.9.5.2-r1523 on Linux 2.6.32-5-686 (i686), built with libpci 3.1.7, GCC 4.4.5, little endian flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK. ======================================================================== WARNING! You seem to be running flashrom on an unsupported laptop. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See http://www.flashrom.org/Laptops for details.
If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Proceeding anyway because user forced us to. Found chipset "Intel ICH7M". Enabling flash write... WARNING: SPI Configuration Lockdown activated. OK. Found Macronix flash chip "MX25L1605" (2048 kB, SPI) at physical address 0xffe00000. Note: If the following flash access fails, try -p internal:mainboard=<vendor>:<mainboard>. Reading old flash chip contents... done. Erasing and writing flash chip... spi_block_erase_20 failed during command execution at address 0x0 Reading current flash chip contents... done. spi_block_erase_52 failed during command execution at address 0x0 Reading current flash chip contents... done. Transaction error! spi_block_erase_d8 failed during command execution at address 0x1f0000 Reading current flash chip contents... done. spi_chip_erase_60 failed during command execution Reading current flash chip contents... done. spi_chip_erase_c7 failed during command execution FAILED! Uh oh. Erase/write failed. Checking if anything changed. Your flash chip is in an unknown state. Get help on IRC at irc.freenode.net (channel #flashrom) or mail flashrom@flashrom.org with FAILED: your board name in the subject line! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF!
Where should I start fixing the problem? The computer is running.
Thanks a lot :) Motiejus
Hi!
Motiejus Jakštys wrote:
I carefully followed the instructions by Peter Stuge: http://comments.gmane.org/gmane.linux.bios/69354
..
Erasing and writing flash chip... spi_block_erase_20 failed during command execution at address 0x0 Reading current flash chip contents... done. spi_block_erase_52 failed during command execution at address 0x0
The above are OK. flashrom tries different erase commands and the 0x20 and 0x52 fail. (But then 0xd8 is tried and that succeeds.)
Reading current flash chip contents... done. Transaction error!
I'm not sure why this Transaction error is printed, but it's not critical.
spi_block_erase_d8 failed during command execution at address 0x1f0000
This looks bad but it is actually an indication of success. This means that your flash chip was erased and written by flashrom up until the last 64kb, which always remains write protected with the factory BIOS.
Your flash chip is in an unknown state.
This is not really true. We know that your flash chip has been erased and written with the first 2048-64=1984 kb of coreboot.rom.
DO NOT REBOOT OR POWEROFF!
Where should I start fixing the problem? The computer is running.
If bucts shows this output:
# ./bucts bucts utility version '2' Using LPC bridge 8086:27b9 at 0000:1f.00 Current BUC.TS=1 - 64kb address ranges at 0xFFFE0000 and 0xFFFF0000 are swapped
..the important part being Current BUC.TS=1 on the last line, and you've followed the steps carefully, then you should reboot now and let your machine run coreboot for the first time! :)
There is one comment to make, the dd commands I wrote in that email can not be copypasted into the shell, the sizeof() part in particular requires manually inserting the size of the coreboot.rom file into the command. If you didn't do this then please go back into the coreboot directory, rm -rf build, and start over with the dd commands on a freshly built coreboot.rom file.
//Peter
On Tue, Apr 24, 2012 at 06:56:14PM +0200, Peter Stuge wrote:
Hi!
..the important part being Current BUC.TS=1 on the last line, and you've followed the steps carefully, then you should reboot now and let your machine run coreboot for the first time! :)
Hi, indeed it worked! Computer is now booted from SeaBios. :)
There is one comment to make, the dd commands I wrote in that email can not be copypasted into the shell, the sizeof() part in particular requires manually inserting the size of the coreboot.rom file into the command. If you didn't do this then please go back into the coreboot directory, rm -rf build, and start over with the dd commands on a freshly built coreboot.rom file.
Besides these changes, there is another one.. A typo:
Instead of:
then run dd if=coreboot.rom bs=1 \ skip=$[sizeof(coreboot.rom) - 0x10000] count=64k | hexdump
Should be: then run dd if=coreboot.rom bs=1 \ skip=$[sizeof(coreboot.rom) - 0x20000] count=64k | hexdump
However, there are two caveats:
1) major one. There is silent squeeking which is heard from the fan slot. It gives me head pain after seconds. The only way to stop it seems to be to give processor some activity (when I start programs, use dd or cpuburn it stops. Immediately when activity finishes the sound is heard once again).
1) booting Linux from USB stick takes for ever. (loading kernel and initrd takes >10 minutes). However, USB performance is fine when booted from hard drive.
I suspect these things are SeaBios related and I should write there?
Thanks again, Motiejus
Motiejus Jakštys wrote:
indeed it worked! Computer is now booted from SeaBios. :)
Great! Please make sure to also follow the remaining steps, in particular to re-set BUC.TS back to 0, and it's also good to flash a new coreboot.rom.
An unpatched flashrom should succeed without any errors when the machine runs coreboot.
Instead of:
then run dd if=coreboot.rom bs=1 \ skip=$[sizeof(coreboot.rom) - 0x10000] count=64k | hexdump
Should be: then run dd if=coreboot.rom bs=1 \ skip=$[sizeof(coreboot.rom) - 0x20000] count=64k | hexdump
Ah yes to verify that the copying was successful. Thank you!
However, there are two caveats:
- major one. There is silent squeeking which is heard from the fan
slot. It gives me head pain after seconds. The only way to stop it seems to be to give processor some activity (when I start programs, use dd or cpuburn it stops. Immediately when activity finishes the sound is heard once again).
I blame this on poor quality of the power supply electronics in the laptop.
When the processor switches between different performance states the power supply generates an audible noise.
Because the CPU switches very frequently between different performance states the audible noise is heard constantly, except when the CPU remains fully used.
The workaround I use is to add idle=halt to the kernel command line. This means that power consumption is higher than otherwise, but to me it is most important that the machine is silent.
I have a 2.0 GHz CPU, but I must limit this to 996 MHz in order to not have the machine overheat during use. This is the same for me regardless of which firmware is used, happens both with factory BIOS and coreboot+SeaBIOS.
In my start scripts I have:
cd /sys/devices/system/cpu/cpu0/cpufreq && { echo userspace > scaling_governor echo 996000 > scaling_max_freq }
This of course helps compensate for the shorter battery runtime with idle=halt.
Now, there is also a possibility that coreboot can do something to work around this situation, similarly to what the factory BIOS obviously does, since the noise is not present there, but this has not been researched.
I have experienced the same issue with factory BIOS on an X40, when the machine was old. This confirms that the components used in the power supply have worn out.
- booting Linux from USB stick takes for ever. (loading kernel and
initrd takes >10 minutes). However, USB performance is fine when booted from hard drive.
This is a SeaBIOS issue. Recommend to post about this on the SeaBIOS mailing list.
I'm glad to hear that it works for you!
//Peter
On Tue, Apr 24, 2012 at 10:30:24PM +0200, Peter Stuge wrote:
Motiejus Jakštys wrote:
indeed it worked! Computer is now booted from SeaBios. :)
Great! Please make sure to also follow the remaining steps, in particular to re-set BUC.TS back to 0, and it's also good to flash a new coreboot.rom.
An unpatched flashrom should succeed without any errors when the machine runs coreboot.
Yes, it flashed fine. There is still a minor disturbance, though: tp_smapi does not recognize my TP. But whatever, I can live with that.
Because the CPU switches very frequently between different performance states the audible noise is heard constantly, except when the CPU remains fully used.
I have a 2.0 GHz CPU, but I must limit this to 996 MHz in order to not have the machine overheat during use. This is the same for me regardless of which firmware is used, happens both with factory BIOS and coreboot+SeaBIOS.
In my start scripts I have:
cd /sys/devices/system/cpu/cpu0/cpufreq && { echo userspace > scaling_governor echo 996000 > scaling_max_freq }
This of course helps compensate for the shorter battery runtime with idle=halt.
Slightly off-topic, but please forgive us. This worked for me: processor.max_cstate=2 in kernel boot line (Squeeze). From [1].
Now, there is also a possibility that coreboot can do something to work around this situation, similarly to what the factory BIOS obviously does, since the noise is not present there, but this has not been researched.
Probably power saving was disabled in original BIOS. I got this computer used and somehow didn't check it, was too hurry to flash to coreboot.
I'm glad to hear that it works for you!
Thanks a lot for your help. :)
Motiejus
[1]: http://www.thinkwiki.org/wiki/Talk:Problem_with_high_pitch_noises
Moving over to the coreboot mailing list.
Motiejus Jakštys wrote:
Yes, it flashed fine. There is still a minor disturbance, though: tp_smapi does not recognize my TP. But whatever, I can live with that.
Could you send some logs showing this failure? I don't recall seeing it, but I also haven't actively tried to use tp_smapi on my machine.
idle=halt.
Slightly off-topic, but please forgive us. This worked for me: processor.max_cstate=2 in kernel boot line (Squeeze). From [1].
Yes, that also works, but I found that I could still hear noise with that setting, so I went with idle=halt.
Now, there is also a possibility that coreboot can do something to work around this situation, similarly to what the factory BIOS obviously does, since the noise is not present there, but this has not been researched.
Probably power saving was disabled in original BIOS. I got this computer used and somehow didn't check it, was too hurry to flash to coreboot.
I somehow think the power saving has too big impact on battery life to have been disabled, but oh well.
I'm glad to hear that it works for you!
Thanks a lot for your help. :)
You're welcome, but thank Sven instead, he did the port and pointed out the flashrom trick! :)
//Peter
On Tue, Apr 24, 2012 at 11:34:23PM +0200, Peter Stuge wrote:
Motiejus Jakštys wrote:
Yes, it flashed fine. There is still a minor disturbance, though: tp_smapi does not recognize my TP. But whatever, I can live with that.
Could you send some logs showing this failure? I don't recall seeing it, but I also haven't actively tried to use tp_smapi on my machine.
# modprobe tp_smapi FATAL: Error inserting tp_smapi (/lib/modules/2.6.32-5-686/updates/dkms/tp_smapi.ko): No such device
and in dmesg: [ 1833.552687] thinkpad_ec: no ThinkPad embedded controller!
According to ThinkWiki[1], I should upgrade my BIOS. I gave up here. I wonder are there any gotchas if I run Linux as BIOS as a Payload? Quite scary. It is so weird to think about a computer without BIOS.
Now, there is also a possibility that coreboot can do something to work around this situation, similarly to what the factory BIOS obviously does, since the noise is not present there, but this has not been researched.
Probably power saving was disabled in original BIOS. I got this computer used and somehow didn't check it, was too hurry to flash to coreboot.
I somehow think the power saving has too big impact on battery life to have been disabled, but oh well.
Well, I can revert to my old bios and see what was there for real. Would it make sense?
Besides, what exactly is your TP model?
I'm glad to hear that it works for you!
Thanks a lot for your help. :)
You're welcome, but thank Sven instead, he did the port and pointed out the flashrom trick! :)
Thanks Sven!
This community is awesome.
Motiejus
-
Motiejus Jakštys -
Peter Stuge