[flashrom] [PATCH] ICH SPI paranoid error handling

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sun Apr 24 23:20:53 CEST 2011


Hi Michael,

Am 23.04.2011 19:37 schrieb Michael Karcher:
> Am Mittwoch, den 16.03.2011, 23:31 +0100 schrieb Stefan Reinauer:
>    
>>> Reduce SPI cycle timeout from 60 s to 60 ms.
>>>        
> Turned out to be a bad idea in the current code base. We use the preop
> mechanism if it seems to fit, which means we use the ACS (atomic cycle
> sequence) bit in the control register for that.
>
> According to the ICH10 datasheet, the following operations are done
> atomically:
>   - sending the preop
>   - sending the main opcode
>   - polling the status register until WIP (bit 0) is low (!!!)
>
> During all these operations, the SCIP (SPI cycle in progress) bit is
> set.
>
> So if enable write/sector erase is sent as "atomic sequence", the cycle
> is only over after the erase completed, which can easily exceed 60ms.
> See for example this report where exactly that happened:
>
> http://paste.flashrom.org/view.php?id=513
>    

Thank you for the excellent analysis.


> We need to revert the timeout to 60 seconds at least if we use the
> atomic sequence feature of the chipset. Or we need to stop using atomic
> sequences.
>    

Atomic sequences are needed for locked down hardware (no opmenu 
reprograming), so we either use two different code paths for SPI command 
execution on locked down and unlocked hardware, or we indeed increase 
the timeouts again.
What do you think about an exponential timeout increase starting at 1 
us, doubling the per-loop timeout each loop with a cap at 1 s per loop? 
And should we introduce programmer_soft_delay (i.e. sleep instead of 
busywait) while we're at it to allow for CPU load reduction?


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the flashrom mailing list