On 05.06.2009 16:43, Urja Rannikko wrote:
On Fri, Jun 5, 2009 at 17:18, Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@gmx.net wrote:
- appending to a previous write command with a byte
Special case, should not end up in the interface. Either the programmer driver performs auto-erge of write commands or it simply enters a new write command.
The point is here that the buffer management isnt visible outside of the programmer driver. Eg. when the programmers chip_writeb is called, it will check if the address is previous_address+1 and then send the combine.
Looks nice. Where's the problem? Sorry if I am being dense.
- entering a delay command to the buffer (how long could it be? eg. is
16-bit udelay enough?)
Some chips have delays of more than 60 seconds (yes, not ms or us). 32bit udelay is the way to go forward. If your programmer can't handle a given delay length, the driver should either split it into multiple delays upon downloading it to the device or reject enqueuing such a delay.
You mean delays or timeouts? I (@work) only had access to a bit old flashrom source (a webview or "LXR" would be nice, is there?), but
Needs to be done for the new flashrom tree. I'll ping Stefan or Patrick.
there were no calls to myusec_delay bigger than the 10ms used for AT29C020 detect.
We have sleep(1) in some places.
- execute buffer
OK.
- read byte
is missing from your design.
I was listing only commands related to the buffer handling (at the serial protocol level, between the device and the flashrom external programmer driver)
The Cheetah wants read commands to be added to the device buffer...
Anyway, I just sent a patch which adds multi-byte read and write to the external programmer interface. Can you take a look at it?
Regards, Carl-Daniel