Breaking out new subject...
> 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.
How would you handle the C code for a particular flash chip?
Would that algorithm have to go into the single "giant" app
that is downloaded?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
