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

[David Brown]

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
>