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