On 05.06.2009 16:43, Urja Rannikko wrote: > On Fri, Jun 5, 2009 at 17:18, Carl-Daniel > Hailfinger<[email protected]> 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 -- http://www.hailfinger.org/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
