Re: [Openocd-development] How to handle cross target algorithms
duane> When this idea would be bad: Little quick downloads david> Depends how little... duane> When this idea would be good: BULK transfers, flash programing, etc. [snip] david> However, another way of looking at it: you suggest david> a limited and standardized kind of "debug monitor" Sort of, but not exactly - I'm saying a more "limited standardized" kind of "algo" for more complex things. - and yes exactly with a *STANDARD* command set. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to handle cross target algorithms
duane> [ describing a method to do cross target stuff with ]
duane> [ a 'quaint' little C program ]
oyvind> How would you handle the C code for a particular flash chip?
oyvind> Would that algorithm have to go into the single "giant" app
oyvind> that is downloaded?
The general idea is this:
We could easily create a fairly generic "run_helper" code.
That would be quite re-usable across platforms.
Today - we have complex solutions in each chip.
(ie: Run inner,and run outer, etc).
It would generally be come:
load_this_standard_helper( &task_specific_helper );
while( !done ){
address = get_standard_buffer_address();
len = get_standard_buffer_length();
download_to_buffer( address, length, mydata );
success= run_standard_helper( opcode_to_perfom );
if( !success ){
issue_error_messages();
}
}
The point is, today - the above are *complex* for every target,
The above approach would help 'standardize' the method of doing this.
Nothing says it must be *one*giant* app in fact that might be bad.
But maybe there is a "chip specific helper" a specific target might use.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to handle cross target algorithms
Here is another approach: http://www.ecoscentric.com/ecospro/doc.cgi/html/ecospro-ref/ecoflash.html -- Ø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
Re: [Openocd-development] How to handle cross target algorithms
Ø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
[Openocd-development] How to handle cross target algorithms
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
