[flashrom] [RFC] Kill --force
c-d.hailfinger.devel.2006 at gmx.net
Tue Apr 13 02:04:38 CEST 2010
On 12.04.2010 23:18, Michael Karcher wrote:
> Am Montag, den 12.04.2010, 21:18 +0200 schrieb Carl-Daniel Hailfinger:
>> You can recover with a soldering iron and an external flasher (a $10
>> used mainboard with parallel flash on ebay might suffice).
> Correct. Although I am afraid that he would have to solder/desolder TSOP
> which is the most common flash chip outline used in laptops. Desoldering
> TSOP is probably easier with a hot-air blower (needs at least 250°C,
> typical hair-dryers probably are not enough).
You're the electronics expert, so I'll simply agree with you.
>> The fact that pure write worked for you was just luck. Really.
> Huh, why that? It's the same thing the vendor tool does. Is it pure luck
> on that tool, too? As long as you don't reenable the EC while there is
> no valid code, everything *should* be fine. Of course you will brick the
> system if you write something into the flash that is *not* valid
> resumable EC code.
We erase everything, then we write everything. IIRC the vendor tool
doesn't erase the EC region unless it changed. If flashrom fails in the
middle of erase (after it erased the EC region), the laptop is bricked
because flashrom aborts. If flashrom can erase the whole chip, but fails
to write the complete EC region, the machine is bricked as well because
Did I overlook anything?
>> This problem is fundamentally unsolvable on a technical level, and needs
>> to be addressed (and hopefully solved) as a social problem.
> Still I think it might be a good idea to block -E on shared-flash
> systems. As shared-flash systems generally need a board-enable to
> stop/restart the EC, it would be no problem to set a flag from that
> procedure that invalid flash contents will brick the system.
How do you handle failing erase (as part of a write)? If we quit
flashrom, the registered shutdown hook will be called and the machine
will be a brick afterwards. Not calling the shutdown hook in such cases
is a really dangerous thing to do as well because the EC remains stopped.
> Of course, for the general aspect of flashrom being able to brick
> systems, you are right that we definitely can not catch every corner
> case that would brick a system, but one could still catch the most
> prominent cases.
True. I just fear that such a mechanism may quickly become unwieldy.
Side note: If we know that flash chip probe kills a given EC, could we
probe for it and simply abort before flash chip probe?
More information about the flashrom