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

[Daniel Jacobowitz <dan@xxxxxxxxxxxxxxxx>]

On Wed, Nov 15, 2006 at 03:57:22PM +0100, David Brown wrote:
> >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.

Yes indeed.  Our flash programming is based on GDB; it works either
from Eclipse or from the GDB command line, and on the command line you
can use GDB command scripts and -batch to automate it.

> 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.

Yes, but it's somewhat limited, and doesn't scale well e.g. to IDEs;
it's our goal to support both command line and IDE development well.

Unlike a lot of people developing board support, CodeSourcery has the
ability and motivation to improve GDB instead of short-circuiting
around it - and in this specific case we have a thorough plan for
access to board specific registers.  Implementation is still in
progress, though!

> >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).

If nothing else, you can probably combine these two plans.  This is not
a general or elegant solution, mind you, just a temporary hack, but the
GDB trick may be useful if you need it.  This is the same principle
many JTAG interfaces use, though they have better ways to do it than
the stack, and this only works once the stack and memory are set up...

# Untested
define set_cacr
set $sp = $sp - 16
set {short}$sp = 0x1111 # movec.l...
set {short}($sp+2) = 0x2222 # ...%d0, %cacr
set {short}($sp+4) = 0x4444 # ret
set $p = (void (*) (int)) $sp
call $p($arg1)
set $sp = $sp + 16
end

-- 
Daniel Jacobowitz
CodeSourcery