Øyvind Harboe wrote on 2009-09-11 09:57:08:
> 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?
The "How to Write your own FLASH Algorithm" document at
http://www.lauterbach.com/manual.html could perhaps
be of interest.
Direct link:
http://www2.lauterbach.com/pdf/flash_app_own_algorithm.pdf
Best regards
Jonas
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
