On Mon, 2008-10-06 at 21:37 -0400, Duane Ellis wrote:
> Michael Schwingen wrote:
> > The C code reads its parameters directly from params, and writes its result
> > there.
> Agreed, sounds simple. But I do not think "code-lets" is the right idea.
> It is too simplistic.
>
> Reasoning:
I was thinking along the same lines. This way we write an opcode stream
definition for each flash type which works for all targets (with
external flash). And for each target implementation we provide an
opcode interpreter and a fast buffer transfer mechanism. The target
implementation gets called with the buffer and the opcode stream. It
has to get these transferred to the target and run the target opcode
interpreter.
Some added complexities are multi-chip banks (for example 2x16 or 4x8
chips for 32 bits) and of course error handling, but that should not be
too difficult. We'd need to make the opcodes rich enough to handle word
program, UnlockBypass programming as well as Buffered programming modes
(are there any other programming types?) but again that seems straight
forward. The only looping is status checking which has a small number
of variations (I think) and of course error detection/reporting would be
a part of this.
Given that the buffer transfer and opcode interpreter is managed by the
target implementation, it might even be able to handle strange flash
access mechanisms (e.g SPI or internal flash) transparent to the
algorithm (assuming they are the compatible of course). But that's for
later enhancements...
Does that fit in your thinking?
>
> Most "flash sequences" are simplistic, there are no more then 10 to 20
> commands. Hence, 10 to 20 opcodes.
>
> The idea I had for the "C_Function()" is sort of like this:
>
> There would be an opcode stream, well really a high level command
> stream. See the switch statement below.
>
> The C function would start reading that sequence. One should be able to
> construct a simple byte command sequence to execute for any and all
> flash chips.
>
> Some commands would have an "immediate" value, others would not.
> For example the command 'F' would indicate the "flash chip address is next"
> Following the opcode F would be a byte indicating what parameter it is
> located in.
> Perhaps the ascii 'T' - means perform the data bit X - toggle busy wait.
>
> The idea is - 90% of these are simplistic functions.
> The "function" could be written in assembler, or in C.
> In fact, it could perhaps (for ARM) use the DCC to download data..
>
> The "C" function might look sort of like this:
>
> int
> C_Function( struct table *p )
> {
> void *flashptr;
> int buswidth;
> char *opcode;
>
> opcodes = p->param[0];
>
> for(;;){
> switch( *opcode++ ){
> default:
> return -1; // opcode not supported
> case 0:
> return 0; // success
> case 'B':
> buffer = p->param[ *opcode++ ];
> break;
> case 'F':
> // get flash address.
> flashptr = p->param[*opcode++];
> break;
> case 'w'
> // next byte is 8/16/32 for bus width.
> buswidth = *opcode++;
> break;
> case 'W':
> switch(buswidth){
> case 8:
> ((char *)flashptr) = *opcode++;
> break;
> case 16:
> ((short *)flashptr) = *opcode++;
> break;
> case 32:
> ((long *)flashptr) = *opcode++;
> break;
> }
> case '6':
> /* do Intel D6 toggle read at FLASHPTR address */
> ... [snip]
> ... other snips...
> }
> }
>
>
> _______________________________________________
> Openocd-development mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
