[coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board

[David Brown]

Nathan Sidwell wrote:
> 
>> It turns out that you can get the Code Worrier user's guide from 
>> without downloading the whole lot, from:
>>
>> http://www.freescale.com/files/soft_dev_tools/doc/user_guide/COLDFIREUG.pdf 
>>
> 
> Glad you found that.  We were unable to get permission to distribute 
> those config files.
> 

You have my permission to distribute my posted example cfg file, if that 
is of any use!  Of course, with your new version just round the corner, 
I suppose it would not affect many people.

> Our upcoming update to the tools has implemented a much better xml based 
> initialization scheme, which we have fully documented.  It specifies 
> both board initialization and board memory maps.
> 

I guess you need that for your support for flash programming as well, so 
that makes sense.  I hope your flash programming utilities support 
command-line access, rather than forcing the use of a gui (as 
Freescale's flash program does, as far as I can see) - I like to have a 
"burn" make target during development.

>> I'd still like to know how to change cpu-space registers from with 
>> gdb, if anyone has any ideas - for some processors, it is important to 
>> be able to do things like turn caching on and off while debugging.
> 
> This is not possible with the current gdb -- the bdm.sourceforge.net 
> patches have not been contributed to FSF gdb.  That said, control 
> register access from gdb is on our todo list, but won't be available in 
> the near term.
> 

I suppose the trouble with using the bdm.sourceforge.net patches is that 
the copyright has not been transferred to the FSF, so that it could 
never become an official part of the gdb tree?

On other gdb + proxy setups I have used, the "monitor" command is used 
to pass commands directly to the proxy program, and as far as I know 
this is done without changes to gdb.  The msp430 proxy program, for 
example, handles commands like "monitor erase" to erase the 
microcontroller's flash.  That would perhaps be an easier route to add 
functionality than implementing bdm specific commands in gdb.

> In the meantime you could include a function of the form
> 
> void set_cache_debug (unsigned v) {
>   __asm__ __volatile__ ("movec.l %0,%/cacr" :: "r" (v) : "memory");
> }
> 
> in your application and use it from gdb with
> 
> (gdb) call set_cache_debug(0xWHATEVER)
> 

Yes, that's what I had planned to do (although I had thought of setting 
up such functions from within my .gdbinit file rather than in the 
program being debugged).  At the moment, the card I am working on has a 
MCF5213, and I don't need to write to any cpu space registers after the 
initial setup.  I'll need it later for further work on an MCF5234 card, 
but that will be some time in the future.

> 
> nathan
>