Am Mittwoch, den 16.06.2010, 21:41 +0100 schrieb Andrew Goodbody:
On 16/06/2010 15:56, Michael Karcher wrote:
In shared flash environments, a short sleep between polls of the status register might be very useful. I don't see a big timing impact of a 10us sleep on flashrom, but it will greatly reduce SPI load.
No, I don't think so, at least not because of the shared environment. Generally (always?) in a shared environment you first have to tell the other device to completely stop accessing the flash.
Hmm, you are right for raw SPI access. For the LPC->SPI translation in many ECs (which we were not talking about here), there is hardware arbitration that coordinates flash access from the LPC bust and flash access from the EC core.
Once you start any operation other than read then you cannot have anything else access that flash device or else one or the other will get corrupted results eg ID instead of code fetch.
For SPI this is not the case. A read ID command always returns the ID and a read data command always returns data. For SPI it would be important to not interrupt between WREN and the program instruction, but as you already stated at the beginning: During flashing, the EC system is shut down so no interfering action will happen.
So the best thing to do is to complete all operations as quickly as possible and then signal the shared accesses to resume.
But the point on excessive CPU load still stands. A programmer_delay(10) of cause will also cause excessive CPU load, as it is busy waiting. So we should have the cases - no delay - short delay (give up timeslices) - long delay (several 10s of ms)
Regards, Michae Karcher