Øyvind Harboe wrote:
> Regarding the run_algorithm. This makes me think about
> the refactoring I did for the arm simulation code....
>
> W.r.t. run_algorithm, I was thinking about how much work
> it would be to write a *small* machine code translator
> that would translate generic code in to machine specific
> code... Sounds impossibly hard, but is it really? I haven't
> looked at what's out there.
>
We also talked a while back about the idea of a standardized download to
the target.
The general idea i was taking about at the time is described below.
-Duane.
====
A small say 2K, 100% position independent common block of arm code.
perhaps - an "armv4" based 32bit code (not thumb)
why? Because that would cover all arm7 and arm9 chips.
Perhaps - another for cortexM3
perhaps - another for armv7 - (cortexA8)
Maybe other chips are "fixed address" - but generally ARM code can be made
to be PIC in a very simple way.
When this idea would be bad: Little quick downloads
When this idea would be good: BULK transfers, flash programing, etc.
The idea is this:
Let us assume there is a 4K block (working space) of ram some where.
The code could be 2K, set aside 1K for stack (yes 1K)
And 1K for a download buffer - could be bigger..
Maybe we work with 4K and 4K...
The entry point would be fixed - always at Buffer+0
Set the program counter there, nothing else needs set.
Then, set a SW breakpoint at - a fixed location.
Example: Buffer + 0x10
This would leave a few bytes @ the start for startup code
And might be easier for different chips (ie: non-arm chips).
The target code *RUNS*, sets up the stack and then enters
some type of "for-ever" loop, that looks like this:
*AND* is 100% written in *C* code - not assembler.
some_c_function( void )
{
uint32_t buffer[16];
// this example puts the 4K transfer buffer on the stack
uint32_t download_buffer[ 1024 ];
int result;
// assume result=success
result = 0;
for( ;; ){
// buffer[0] = holds result
buffer[0] = result;
// tell app where transfer buffer is located.
buffer[1] = &download_buffer[0];
buffer[2] = sizeof(download_buffer);
// this hits openocd breakpoint
openocd_syscall( &buffer[0] );
// openocd stuffs parameters in the buffer.
// parameter 0 - is the command.
// parameter 1/2/3 ... /15 are command specific
switch( buffer[0] ){
case CFI_FLASH_ERASE:
// params 1,2,3 are address and length
result= perform_cfi_erase( &buffer[0] );
case HIGH_SPEED_DOWNLOAD:
// on ARM this might use CP15 DCC
result =perform_high_speed_download(
&buffer[0] );
case .. other commands
// break
} // switch
} // forever()
}
======
Why do I suggest C? And the above method...
Because it would work on *ALL* targets!
One only needs to *compile* a small C program.
And little helpers would be very fast.
-Duane.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
