Re: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board
- To: Daniel Jacobowitz <dan@xxxxxxxxxxxxxxxx>
- Subject: Re: [coldfire-gnu-discuss] Using m68k-elf-cfpe-stub with our own board
- From: David Brown <david@xxxxxxxxxxxxxxx>
- Date: Wed, 15 Nov 2006 16:52:32 +0100
Daniel Jacobowitz wrote:
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.
That would be fine for me. I use gdb scripts and batch programming on
other cards - it's easy to combine card test and programming setups for
production use with gdb scripts.
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!
Sometimes short-cuts are easiest, and sometimes it is best to spend the
time and effort doing a full job to make life easier later. I use gcc
toolchains on a range of targets, and it is often annoying that embedded
target features like interrupts or debugging peculiarities are different
for every target instead of having a common solution. Since there is a
perfectly workable hack for this issue (putting the code on the stack is
a nice idea), I have no problems with waiting for you guys to implement
a more complete solution.
mvh.,
David
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