Am Montag, den 12.04.2010, 02:35 +0200 schrieb Magnus Alm:
OK, I got a problem now, tested "flashrom -EV", bad idea it seems, now I cant write the BACKUP.ROM back.
Oh, this looks like you *really* have a problem now. I'm sorry I didn't think of this case beforehand, but I seriously doubt that it is possible to fix the situation from within the running system.
The problem on your system (which carldani correctly recognized) is the following. The data flow to the ROM chip is like
Processor --HT--> Southbridge --LPC/FWH--> Embedded Controller --FWH--> Flash chip
The embedded controller uses parts of the flash contents as instructions. There is one magic instruction (or two in your case) that make the EC spin in an idle loop that doesn't access the flash chip. In this configuration, the processor can access the flash chip as it likes to. But this idle loop drops all EC functionality like keyboard, mouse, fan control, brightness control, temperature monitoring and so on, so you should only use it for limited amounts of time. When the processor is finished with updating the flash chip, it sends a magic "exit the idle loop" instruction to the EC.
Now, after you used flashrom -E on your flash chip, the EC program crashes when it tries to resume. On your system, it seemed to have the EC crashed so hard, that it doesn't pass the flash commands from the south bridge to the flash chip. As fan control is done by EC code in some systems, your situation might even cause overheating of the whole system until thermal breakdown.
If your system is not damaged by heat, it is now in a configuration it is directly after manufacturing the board - so there definitely *is* a way to rewrite the flash chip in system, as vendors usually don't pre-program the flash chips before assembling the board. But this way might include special vendor tools in hardware (like test pins contacting the board on special position) or software (like a special protocal over JEDEC pins) we don't have.
As your system is bricked anyway now, you could open it up and try to find the EC (a bigger chip, but not the northbridge, southbridge, graphics chip, LAN chip or audio chip) and check whether there is a usable datasheet for it.
Note: flashrom can never write when the flash chip isn't found automatically.
And that is for a reason. If the flash chip is not found automatically, it means we didn't get the probe command to the chip. In times before we had these SPI firewalling chipsets (you don't have one), this was a clear indication that we also can't get erase or write commands to the chip. So erasing/writing if detection of a known chip fails is generally futile.
I am sorry that I didn't think about the danger beforehands. I will definitely think about a protection mechanism that prevents this happening again before the patch goes into main flashrom.
Regards, Michael Karcher