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.
- 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 there were no calls to myusec_delay bigger than the 10ms used for AT29C020 detect.
- 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)
For SPI, you also need select_chip() and deselect_chip().
I'll have to read more on SPI flash chips someday.
Please make sure that the flashrom buffer format has no dependencies on the programmer buffer format. Since hardware is more difficult to change than software, we definitely want to keep the flashrom buffer design changeable without breaking hardware. 16-bit vs. 32-bit delays could be one such difference.
The point in this was that there would be no buffer on flashrom's side - only on the device memory - although that buffer would be handled by the in-flashrom external programmer driver. I did consider skipping that write-combining so that the device would compress the stream, but then i thought that when using real serial, that would slow down writing manyfold to pass all the addresses to the device (AVR).
Some external programmers (Cheetah, some FT2232 designs) also have their own buffer management. Any buffer management design will have to be compatible with them.
What you want is an explicit execute_buffer() function. Writes and delays don't return anything by default. The programmer driver decides when to issue execute_buffer().
There will be execute buffer command on the AVR, but if (eg.) the AVR (for any reason) cannot process serial data as fast as it can receive serial data to it's serial buffer, then sending more bytes of commands than it's serial buffer to it could cause it to lose data. Eg. you need to be able to ask it that it has processed all the commands given.
Peter wrote:
I think there are two parts to it. One is about the flashrom data model, which has been expanded a little lately but really needs to be very different.
The big problem with a totally different data model is that we can't know for sure if it will work for everything in the future. Our current model was extended when it didn't fit anymore and each time it seemed that the model would be good enough after the change. There's no guarantee that we won't fall into the same trap with a complete redesign.
The timing properties you mention are required for some chips and other chip types have other required property sets.
The challenge here is to create a complete data model.
Agreed. However, the data model needs to be understandable as well.
The second part is to communicate that data from flashrom to satellite entities which all implement the same state machine.
We have two state machines: One in the external flasher driver and one in the external flasher. The only thing we need is translation capability.
The challenge here is to create a state machine which works for abstracting all the different ways we want to reach flash chips.
I wouldnt go and change a lot of things just to find out that the new design has some big flaw...
Then maybe some command to return information about programmer functionality would be good - eg.
- what bus type(s) it supports
The code already does that.
I'm talking about the serial protocol - i knew that flashrom already has support for this information.
Let's add programmer_can_access(struct flashchip *flash) which performs size checking etc so that probe_* can indeed return success even for too big chips. Some SPI controllers need that badly.
Ok.