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:
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