Could you (or someone) reissue that in the form of a patch?

Comments below on one file that needs tweaking yet.

On Monday 29 June 2009, Marcel Jost wrote:
> # script for luminary lm3s9b92
> 
> if { [info exists CHIPNAME] } { 
>    set  _CHIPNAME $CHIPNAME    
> } else {         
>    set  _CHIPNAME lm3s9b92
> }
> 
> if { [info exists ENDIAN] } {   
>    set  _ENDIAN $ENDIAN    
> } else {         
>   # this defaults to a little endian
>    set  _ENDIAN little
> }
> 
> if { [info exists CPUTAPID ] } {
>    set _CPUTAPID $CPUTAPID
> } else {
>   # force an error till we get a good number
>    set _CPUTAPID 0x4ba00477

I believe that must be a "good number", so the comment should go.


> }
> 
> # jtag speed
> jtag_khz 500
> 
> jtag_nsrst_delay 100
> jtag_ntrst_delay 100
> 
> #LM3S6918 Evaluation Board has only srst
> reset_config srst_only

Those four things belong in *board-specific* config file,
not this CPU-generic one.  And this is NOT the '6918 EVB,
it's a '9b92 board...


> #jtag scan chain
> jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0xf -expected-id 
> $_CPUTAPID
> 
> # the luminary variant causes a software reset rather than asserting SRST
> # this stops the debug registers from being cleared
> # this will be fixed in later revisions of silicon

Is this still an issue with this almost-the-latest silicon?

I thought that issue was specific to the first generation
silicon ("Sandstorm"), and maybe the first spins of the
second generation stuff.  The '9b92 is fourth gen...


> set _TARGETNAME [format "%s.cpu" $_CHIPNAME]

Just "set _TARGETNAME $_CHIPNAME.cpu" suffices.  ;)


> target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position 
> $_TARGETNAME -variant lm3s
> 
> # 4k working area at base of ram
> $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x20000000 
> -work-area-size 0x4000 -work-area-backup 0
> 
> #flash configuration
> flash bank stellaris 0 0 0 0 0
> 
> gdb_memory_map     enable


_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to