On 05.06.2009 15:44, Urja Rannikko wrote:
I'm essentially replying to two mails at once now ...
On Fri, Jun 5, 2009 at 15:17, Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@gmx.net wrote:
The buffer management would be performed by the programmer driver. So if your programmer can execute (or buffer) 1024 bytes of commands/address/data, make sure flashrom accumulates no more than 1024 bytes in its internal buffer before flushing its buffer to the device.
One of the most important design considerations is to make buffer management optional. On-board programming doesn't need it (and would be slowed down by it), lots of external programmers don't need it either.
Actually this got me to thinking of the protocol and buffer storage format again. There would be commands to:
- query buffer size (so different devices can support different
amounts of buffer)
OK.
- initialize/clear buffer
Maybe two separate functions for this.
- entering a write command to the buffer (with data and address)
OK.
- 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.
- 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.
- execute buffer
OK.
- read byte is missing from your design.
For SPI, you also need select_chip() and deselect_chip().
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.
Some external programmers (Cheetah, some FT2232 designs) also have their own buffer management. Any buffer management design will have to be compatible with them.
A write command with data and address would be if it's a single byte, 6 bytes on buffer - 1 byte op, 1 byte len, 3 byte addr, 1 byte data, but continuation with append data to buffer would be the minimalist 1 byte per byte, unless it's already 256 bytes of data inserted (encoded as 0-byte write) - then it would create a new write command. A delay would take 3 bytes on the buffer, 1 byte op, 2 byte delay value(?).
This would allow for the programmer driver to feed the data to the device during flashrom execution, and upon the first read perform the execute buffer command. I think that with this format the AVR's SRAM is enough for this to work with all the parallel chips with 256 byte or less page size, propably even 512. (1 byte op, 1 byte len (0), 3 byte addr, 256 byte data = 261 bytes)
And here i'm a bit worried about flow control - or actually the lack of it in my hardware. Making each command immediately return an "OK" byte - and waiting for it makes it way too slow, so I'm thinking of by default making those "add write/delay command to buffer" commands return nothing and adding a NOP command that returns a byte and a command that returns the size of the serial buffer on the device, so that the programmer driver can send n bytes of commands in a stream, then send NOP, then wait for answer, then again send n bytes.
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().
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.
You think of this a bit more abstract than i usually do, but basically i agree.
Continuing on the protocol - it would need (ofcourse) also an n-byte read, I'm thinking that it could even be with 24-bit n so that the device could be instructed to read the entire chip in a single operation.
That's what I wrote about the chip_readn function.
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.
- if parallel, how many address lines it has attached to the chip socket
- actually offtopic, but i think it would be good for external
programmers to have the ability to report the size of chip they support (eg 128k for the 3C905B) and for flashrom to issue a warning in case a bigger chip is detected (dont bail - it's still of some use for some purposes where you dont for example need the lower half of an 256k chip).
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.
I think that LPC and FWH can be operated over the same read/write/delay protocol as parallel, but i dont know how different SPI chips are and what extensions (if any) using them would need.
And in reality my programmer supports only parallel (at the moment), so that will be my priority - but i hope i can make a protocol that suits any chip type well.
For SPI, the design is necessarily different, but I'll submit a driver for the TotalPhase Cheetah SPI programmer soon.
Regards, Carl-Daniel