Help with building gdb with BDM support for the Coldfire

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi all -

   I'm trying to build gdb with bdm support for the Coldfire.  I'm not a linux power user, but know enough to muddle my way through things.  I'm using Fedora 8 (linux 2.6.24).

  I configured gdb 6.7 (--target=m68k-bdm-elf) and gdb seems to work.

  I then followed the README file in m68k-bdm-1.4-pre2 from sourceforge.  It took a while to get the ioperm working, but it is working so far (I can connect to my custom target board at least).

  But it will only work if I run m68k-bdm-elf-gdb as root.  This is how I start:

[root@localhost bin]# ./m68k-bdm-elf-gdb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf".

(gdb) target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0
Remote debugging using | m68k-bdm-gdbserver pipe /dev/bdmcf0
m68k-bdm: architecture 68000 connected to /dev/bdmcf0
m68k-bdm: Coldfire debug module version is 1 (5307/5407(e))
Process /dev/bdmcf0 created; pid = 0
0xb6eb7912 in ?? ()
(gdb)

And this is what I get if I try to use it from my regular account:
[pcmadm@localhost bin]$ ./m68k-bdm-elf-gdb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf".

(gdb) target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0
Remote debugging using | m68k-bdm-gdbserver pipe /dev/bdmcf0
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
m68k-bdm: error: No such device or address
m68k-bdm-gdbserver: Exiting
Remote communication error: Resource temporarily unavailable.
(gdb)

What do I have to change so I can run this from my regular user account?

Thanks in advance.
Mark

coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Markus Franke :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

Mark Giacobbe schrieb:
>   But it will only work if I run m68k-bdm-elf-gdb as root.  

Same problem for me. Would be glad to get a solution for this misbehaviour.

Best regards,
Markus
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mark Giacobbe wrote:
> Hi all -
>
>    I'm trying to build gdb with bdm support for the Coldfire.  I'm not a
> linux power user, but know enough to muddle my way through things.  I'm
> using Fedora 8 (linux 2.6.24).
>
>   I configured gdb 6.7 (--target=m68k-bdm-elf) and gdb seems to work.
>

The configure command does not need the bdm part any more as there is no BDM
patch for GDB. This means '--target=m68k-elf' should work. Then again the bdm
part does not seem to hurt.

>   I then followed the README file in m68k-bdm-1.4-pre2 from
> sourceforge.  It took a while to get the ioperm working, but it is
> working so far (I can connect to my custom target board at least).
>
>   But it will only work if I run m68k-bdm-elf-gdb as root.  This is how
> I start:
>
> [root@localhost bin]# ./m68k-bdm-elf-gdb
> GNU gdb 6.7
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf".
>
> (gdb) target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0
> Remote debugging using | m68k-bdm-gdbserver pipe /dev/bdmcf0
> m68k-bdm: architecture 68000 connected to /dev/bdmcf0
> m68k-bdm: Coldfire debug module version is 1 (5307/5407(e))
> Process /dev/bdmcf0 created; pid = 0
> 0xb6eb7912 in ?? ()
> (gdb)

Great.

>
> And this is what I get if I try to use it from my regular account:
> [pcmadm@localhost bin]$ ./m68k-bdm-elf-gdb
> GNU gdb 6.7
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf".
>
> (gdb) target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0
> Remote debugging using | m68k-bdm-gdbserver pipe /dev/bdmcf0
> trying kernel driver: /dev/bdmcf0
> trying bdm server: localhost:/dev/bdmcf0
> Ignoring packet error, continuing...
> warning: unrecognized item "timeout" in "qSupported" response
> m68k-bdm: error: No such device or address
> m68k-bdm-gdbserver: Exiting
> Remote communication error: Resource temporarily unavailable.
> (gdb)
>
> What do I have to change so I can run this from my regular user account?
>

The ioperm system call requires the program run as root. If you run gdb as a
normal user (which I recommend you do) we need to transfer to a root program
somehow to make the ioperm call. The bdmd server does this. If you look at the
doco (http://bdm.sourceforge.net/doc.html) for "Step 3: Installing the Server"
you will see the steps needed to install the server.

FYI the server is just the same BDM code from the BDM library with a socket
interface and protocol.

It would seem I have introduced a bug in the pre2 release with the handling of
no server present. You should get a different message and not ones relating to
'qSupport'.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Before (see below), I could not use the test of

    telnet localhost bdm

I would get a refused connection.  I found the issue for that.  The bdm file for xinetd.d was incorrect.  I had to change the path to the server.  The included one in the README was incorrect for my system.

I changed it from
service bdm
      {
        socket_type  = stream
        port    = 6543
        wait    = no
        user    = root
        server    = /usr/sbin/bdmd
        server_args  = -n
        log_on_failure  += USERID
        disable    = no
      }

to
service bdm
      {
        socket_type  = stream
        port    = 6543
        wait    = no
        user    = root
        server    = /usr/local/sbin/bdmd
        server_args  = -n
        log_on_failure  += USERID
        disable    = no
      }

for the server I had to add 'local' to the path.

Now telnet works (for both user and root) and gdb works for both user and root.   Also I changed the owner/group for m68k-bdm-elf-gdb, and m68k-gdb-server to user (not sure if this was needed, but I did it anyway).  I did this because I configured/compiled/installed everything as root.

Anyway thanks for your help, so far everything works.

Mark

On Mon, Apr 28, 2008 at 8:52 PM, Chris Johns <chris@...> wrote:
Mark Giacobbe wrote:
Hi all -

  I'm trying to build gdb with bdm support for the Coldfire.  I'm not a linux power user, but know enough to muddle my way through things.  I'm using Fedora 8 (linux 2.6.24).

 I configured gdb 6.7 (--target=m68k-bdm-elf) and gdb seems to work.


The configure command does not need the bdm part any more as there is no BDM patch for GDB. This means '--target=m68k-elf' should work. Then again the bdm part does not seem to hurt.


 I then followed the README file in m68k-bdm-1.4-pre2 from sourceforge.  It took a while to get the ioperm working, but it is working so far (I can connect to my custom target board at least).

 But it will only work if I run m68k-bdm-elf-gdb as root.  This is how I start:

[root@localhost bin]# ./m68k-bdm-elf-gdb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf".

(gdb) target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0
Remote debugging using | m68k-bdm-gdbserver pipe /dev/bdmcf0
m68k-bdm: architecture 68000 connected to /dev/bdmcf0
m68k-bdm: Coldfire debug module version is 1 (5307/5407(e))
Process /dev/bdmcf0 created; pid = 0
0xb6eb7912 in ?? ()
(gdb)

Great.



And this is what I get if I try to use it from my regular account:
[pcmadm@localhost bin]$ ./m68k-bdm-elf-gdb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-bdm-elf".

(gdb) target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0
Remote debugging using | m68k-bdm-gdbserver pipe /dev/bdmcf0
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
m68k-bdm: error: No such device or address
m68k-bdm-gdbserver: Exiting
Remote communication error: Resource temporarily unavailable.
(gdb)

What do I have to change so I can run this from my regular user account?


The ioperm system call requires the program run as root. If you run gdb as a normal user (which I recommend you do) we need to transfer to a root program somehow to make the ioperm call. The bdmd server does this. If you look at the doco (http://bdm.sourceforge.net/doc.html) for "Step 3: Installing the Server" you will see the steps needed to install the server.

FYI the server is just the same BDM code from the BDM library with a socket interface and protocol.

It would seem I have introduced a bug in the pre2 release with the handling of no server present. You should get a different message and not ones relating to 'qSupport'.

Regards
Chris

---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mark Giacobbe wrote:

> Before (see below), I could not use the test of
>
>     telnet localhost bdm
>
> I would get a refused connection.  I found the issue for that.  The bdm
> file for xinetd.d was incorrect.  I had to change the path to the
> server.  The included one in the README was incorrect for my system.
>
> I changed it from
> service bdm
>       {
>         socket_type  = stream
>         port    = 6543
>         wait    = no
>         user    = root
>         server    = /usr/sbin/bdmd
>         server_args  = -n
>         log_on_failure  += USERID
>         disable    = no
>       }
>
> to
> service bdm
>       {
>         socket_type  = stream
>         port    = 6543
>         wait    = no
>         user    = root
>         server    = /usr/local/sbin/bdmd
>         server_args  = -n
>         log_on_failure  += USERID
>         disable    = no
>       }
>
> for the server I had to add 'local' to the path.
>

Interesting. I think the doco should be changed to include local as this is
the default prefix the package should build for. I prefer we build for local
and keep the package out of the operating system paths.

Thanks for the feed back.

> Now telnet works (for both user and root) and gdb works for both user
> and root.   Also I changed the owner/group for m68k-bdm-elf-gdb, and
> m68k-gdb-server to user (not sure if this was needed, but I did it
> anyway).  I did this because I configured/compiled/installed everything
> as root.

You should not need to change the owner/group as the permissions should allow
any user to run the program.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I have another interesting issue.  No matter what address I try to set, all address show the same values.

[pcmadm@localhost bin]$ ./m68k-elf-gdb --command=5307.gdb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-elf".
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
m68k-bdm: architecture 68000 connected to /dev/bdmcf0
m68k-bdm: Coldfire debug module version is 1 (5307/5407(e))
Process /dev/bdmcf0 created; pid = 0
0x4010270a in ?? ()

Resetting uP

Setup internal registers

Setup internal SRAM

Setup Chip Selects

Setup GPIO

Setup SDRAM

     SDRAM refresh
(gdb) d32 0x0 16
0x0:    0xbeaddeed      0x01000100      0x40102708      0x40102708
0x10:   0x40102708      0x40102708      0x40102708      0x40102708
0x20:   0x40102708      0x40102708      0x40102708      0x40102708
0x30:   0x40102708      0x40102708      0x40102708      0x40102708
(gdb) d32 0xb0000000 16
0xb0000000:     0xbeaddeed      0x01000100      0x40102708      0x40102708
0xb0000010:     0x40102708      0x40102708      0x40102708      0x40102708
0xb0000020:     0x40102708      0x40102708      0x40102708      0x40102708
0xb0000030:     0x40102708      0x40102708      0x40102708      0x40102708
(gdb) set32 0xb0000000 0x12345678
(gdb) d32 0xb0000000 16
0xb0000000:     0x12345678      0x01000100      0x40102708      0x40102708
0xb0000010:     0x40102708      0x40102708      0x40102708      0x40102708
0xb0000020:     0x40102708      0x40102708      0x40102708      0x40102708
0xb0000030:     0x40102708      0x40102708      0x40102708      0x40102708
(gdb) d32 0x0 16
0x0:    0x12345678      0x01000100      0x40102708      0x40102708
0x10:   0x40102708      0x40102708      0x40102708      0x40102708
0x20:   0x40102708      0x40102708      0x40102708      0x40102708
0x30:   0x40102708      0x40102708      0x40102708      0x40102708
(gdb)

set32 is
 set *((unsigned long*) $arg0) = $arg1

and d32 is
 x /$arg1w $arg0

Address 0xb0000000 is sdram and address 0x0 is regular sram.

I have taken the chip select configurations from a project/debugger I know works.

One thing I have to ask is when gdb starts it is different from the README.gdbserver file.  The readme shows:

trying kernel driver: /dev/bdmcf0
  trying bdm server: localhost:/dev/bdmcf0
  m68k-bdm: detected MCF5235
  m68k-bdm: architecture CF5235 connected to /dev/bdmcf0
  m68k-bdm: Coldfire debug module version is 0 (5206(e)/5235/5272/5282)
  Process /dev/bdmcf0 created; pid = 0

and my setup shows
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
m68k-bdm: architecture 68000 connected to /dev/bdmcf0
m68k-bdm: Coldfire debug module version is 1 (5307/5407(e))
Process /dev/bdmcf0 created; pid = 0

Is this correct?  That it is showing 68000 architecture?

Any help is greatly appreciated!!

Thanks
Mark


On Thu, May 1, 2008 at 8:39 PM, Chris Johns <chris@...> wrote:
Mark Giacobbe wrote:
Before (see below), I could not use the test of

   telnet localhost bdm

I would get a refused connection.  I found the issue for that.  The bdm file for xinetd.d was incorrect.  I had to change the path to the server.  The included one in the README was incorrect for my system.

I changed it from
service bdm
     {
       socket_type  = stream
       port    = 6543
       wait    = no
       user    = root
       server    = /usr/sbin/bdmd
       server_args  = -n
       log_on_failure  += USERID
       disable    = no
     }

to
service bdm
     {
       socket_type  = stream
       port    = 6543
       wait    = no
       user    = root
       server    = /usr/local/sbin/bdmd
       server_args  = -n
       log_on_failure  += USERID
       disable    = no
     }

for the server I had to add 'local' to the path.


Interesting. I think the doco should be changed to include local as this is the default prefix the package should build for. I prefer we build for local and keep the package out of the operating system paths.

Thanks for the feed back.


Now telnet works (for both user and root) and gdb works for both user and root.   Also I changed the owner/group for m68k-bdm-elf-gdb, and m68k-gdb-server to user (not sure if this was needed, but I did it anyway).  I did this because I configured/compiled/installed everything as root.

You should not need to change the owner/group as the permissions should allow any user to run the program.


Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mark Giacobbe wrote:
>
> Is this correct?  That it is showing 68000 architecture?
>

No it is not correct but that is what the current code has.

Would you be able to add the registers needed and send me a patch ?

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'm sorry, I don't understand your question.  What registers do you want me to add?

Mark

On Mon, May 5, 2008 at 9:52 PM, Chris Johns <chris@...> wrote:
Mark Giacobbe wrote:

Is this correct?  That it is showing 68000 architecture?


No it is not correct but that is what the current code has.

Would you be able to add the registers needed and send me a patch ?


Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mark Giacobbe wrote:
> I'm sorry, I don't understand your question.  What registers do you want
> me to add?
>

Take a look in the top of m68k/gdbserver/m68k-bdm-low.c in the BDM package and
you will see the register mappings for the various devices. The 5307/5407 is
missing. A table with the registers for this device needs to be added and then
an entry added to the m68k_bdm_reg_map table. After that add a little logic in
m68k_bdm_create_inferior. For this device I think the version number of the
debug module is all you need to check. The last part is the XML definition. I
would just copy the closest one and change it. This file needs to be added to
the list in m68k/gdbserver/Makefile.am.

The XML file is sent to GDB and all you need to make sure if the definitions
in the XML match the table in m68k/gdbserver/m68k-bdm-low.c.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hey Chris -
  I made the changes and now when gdb starts I get
[pcmadm@localhost bin]$ ./m68k-elf-gdb --command=5307.gdb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-elf".
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
m68k-bdm: detected MCF5307
m68k-bdm: architecture CF5307 connected to /dev/bdmcf0
m68k-bdm: Coldfire debug module version is 1 (5307/5407(e))
Process /dev/bdmcf0 created; pid = 0
0xb6eb7912 in ?? ()

So it seems the changes were accepted.  But my memory issue is still there.

No matter what memory address I read/write to the values are all the same.  And I can only do unsigned long writes (it seems).  If I try to do a unsigned char, the entire 32 bit address get's the value.

(gdb) d32 0xb0000000 16
0xb0000000:     0xbeaddeed      0x01000100      0xbff559d1      0xb6eb7913
0xb0000010:     0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0xb0000020:     0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0xb0000030:     0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) d32 0x00000000 16
0x0:    0xbeaddeed      0x01000100      0xbff559d1      0xb6eb7913
0x10:   0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0x20:   0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0x30:   0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) set32 0xb0000000 0x12345678
(gdb) d32 0x00000000 16
0x0:    0x12345678      0x01000100      0xbff559d1      0xb6eb7913
0x10:   0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0x20:   0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0x30:   0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) d32 0xb0000000 16
0xb0000000:     0x12345678      0x01000100      0xbff559d1      0xb6eb7913
0xb0000010:     0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0xb0000020:     0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0xb0000030:     0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) set8 0xb0000000 0xaa
(gdb) d32 0xb0000000 16
0xb0000000:     0xaaaaaaaa      0x01000100      0xbff559d1      0xb6eb7913
0xb0000010:     0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0xb0000020:     0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0xb0000030:     0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) Quit
(gdb)

Any other ideas??

Thanks for the help
Mark


On Tue, May 6, 2008 at 7:57 PM, Chris Johns <chris@...> wrote:
Mark Giacobbe wrote:
I'm sorry, I don't understand your question.  What registers do you want me to add?


Take a look in the top of m68k/gdbserver/m68k-bdm-low.c in the BDM package and you will see the register mappings for the various devices. The 5307/5407 is missing. A table with the registers for this device needs to be added and then an entry added to the m68k_bdm_reg_map table. After that add a little logic in m68k_bdm_create_inferior. For this device I think the version number of the debug module is all you need to check. The last part is the XML definition. I would just copy the closest one and change it. This file needs to be added to the list in m68k/gdbserver/Makefile.am.

The XML file is sent to GDB and all you need to make sure if the definitions in the XML match the table in m68k/gdbserver/m68k-bdm-low.c.


Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I may have spoke to soon about my changes working.  Looking deeper, it seems if I do a info all-registers, I get the V4E set, which is probably why none of my changes are really working.

I'm going to keep looking, but if you have any other suggestions or places to look at, I'll be glad to hear them!! :)

I'll try to send my patches for your review to see if I missed anything.

Regards
Mark

On Thu, May 8, 2008 at 9:34 AM, Mark Giacobbe <mcgiacobbe@...> wrote:
Hey Chris -
  I made the changes and now when gdb starts I get

[pcmadm@localhost bin]$ ./m68k-elf-gdb --command=5307.gdb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=m68k-elf".
trying kernel driver: /dev/bdmcf0
trying bdm server: localhost:/dev/bdmcf0
m68k-bdm: detected MCF5307
m68k-bdm: architecture CF5307 connected to /dev/bdmcf0

m68k-bdm: Coldfire debug module version is 1 (5307/5407(e))
Process /dev/bdmcf0 created; pid = 0
0xb6eb7912 in ?? ()

So it seems the changes were accepted.  But my memory issue is still there.

No matter what memory address I read/write to the values are all the same.  And I can only do unsigned long writes (it seems).  If I try to do a unsigned char, the entire 32 bit address get's the value.

(gdb) d32 0xb0000000 16
0xb0000000:     0xbeaddeed      0x01000100      0xbff559d1      0xb6eb7913
0xb0000010:     0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0xb0000020:     0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0xb0000030:     0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) d32 0x00000000 16
0x0:    0xbeaddeed      0x01000100      0xbff559d1      0xb6eb7913
0x10:   0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0x20:   0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0x30:   0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) set32 0xb0000000 0x12345678
(gdb) d32 0x00000000 16
0x0:    0x12345678      0x01000100      0xbff559d1      0xb6eb7913
0x10:   0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0x20:   0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0x30:   0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) d32 0xb0000000 16
0xb0000000:     0x12345678      0x01000100      0xbff559d1      0xb6eb7913
0xb0000010:     0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0xb0000020:     0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0xb0000030:     0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) set8 0xb0000000 0xaa
(gdb) d32 0xb0000000 16
0xb0000000:     0xaaaaaaaa      0x01000100      0xbff559d1      0xb6eb7913
0xb0000010:     0xe23d3498      0x4072b7d4      0xf8d2f259      0xf7fe8c37
0xb0000020:     0xabb859ee      0xbe70cddd      0x3e4be7df      0xdaaf9f34
0xb0000030:     0x5de39431      0x2dd2e5df      0x5b38fddd      0x8fbe22df
(gdb) Quit
(gdb)

Any other ideas??

Thanks for the help
Mark



On Tue, May 6, 2008 at 7:57 PM, Chris Johns <chris@...> wrote:
Mark Giacobbe wrote:
I'm sorry, I don't understand your question.  What registers do you want me to add?


Take a look in the top of m68k/gdbserver/m68k-bdm-low.c in the BDM package and you will see the register mappings for the various devices. The 5307/5407 is missing. A table with the registers for this device needs to be added and then an entry added to the m68k_bdm_reg_map table. After that add a little logic in m68k_bdm_create_inferior. For this device I think the version number of the debug module is all you need to check. The last part is the XML definition. I would just copy the closest one and change it. This file needs to be added to the list in m68k/gdbserver/Makefile.am.

The XML file is sent to GDB and all you need to make sure if the definitions in the XML match the table in m68k/gdbserver/m68k-bdm-low.c.


Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.



coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mark Giacobbe wrote:
> I may have spoke to soon about my changes working.  Looking deeper, it
> seems if I do a info all-registers, I get the V4E set, which is probably
> why none of my changes are really working.
>

Ah ok. Nice observation.

> I'm going to keep looking, but if you have any other suggestions or
> places to look at, I'll be glad to hear them!! :)
>
> I'll try to send my patches for your review to see if I missed anything.
>

Please send the patch to me and I will take a look. It could be something
simple that I forgot to mention.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The observations that I see makes sense.  Since none of the registers are programmed, cs0 will always respond to any memory access, and cs0 is programmed by hardware to always to a 32 bit access.

Here is the patch of my changes.  Please look it over and I'm sure I forgot to change something.

Thanks for your help
Mark

diff -Naur /opt/old/m68k-bdm-1.4-pre2/m68k/autom4te.cache/requests /opt/m68k-bdm-1.4-pre2/m68k/autom4te.cache/requests
--- /opt/old/m68k-bdm-1.4-pre2/m68k/autom4te.cache/requests    2008-03-18 04:04:19.000000000 -0400
+++ /opt/m68k-bdm-1.4-pre2/m68k/autom4te.cache/requests    2008-05-08 09:17:15.000000000 -0400
@@ -82,15 +82,15 @@
                         'configure.ac'
                       ],
                       {
-                        'AM_PROG_F77_C_O' => 1,
                         '_LT_AC_TAGCONFIG' => 1,
-                        'm4_pattern_forbid' => 1,
+                        'AM_PROG_F77_C_O' => 1,
                         'AC_INIT' => 1,
+                        'm4_pattern_forbid' => 1,
                         'AC_CANONICAL_TARGET' => 1,
-                        'AC_CONFIG_LIBOBJ_DIR' => 1,
                         'AC_SUBST' => 1,
-                        'AC_CANONICAL_HOST' => 1,
+                        'AC_CONFIG_LIBOBJ_DIR' => 1,
                         'AC_FC_SRCEXT' => 1,
+                        'AC_CANONICAL_HOST' => 1,
                         'AC_PROG_LIBTOOL' => 1,
                         'AM_INIT_AUTOMAKE' => 1,
                         'AC_CONFIG_SUBDIRS' => 1,
@@ -98,8 +98,8 @@
                         'LT_CONFIG_LTDL_DIR' => 1,
                         'AC_REQUIRE_AUX_FILE' => 1,
                         'AC_CONFIG_LINKS' => 1,
-                        'LT_SUPPORTED_TAG' => 1,
                         'm4_sinclude' => 1,
+                        'LT_SUPPORTED_TAG' => 1,
                         'AM_MAINTAINER_MODE' => 1,
                         'AM_GNU_GETTEXT_INTL_SUBDIR' => 1,
                         '_m4_warn' => 1,
@@ -116,11 +116,11 @@
                         'AH_OUTPUT' => 1,
                         '_AM_SUBST_NOTMAKE' => 1,
                         'AC_CONFIG_AUX_DIR' => 1,
-                        'm4_pattern_allow' => 1,
-                        'AM_PROG_CC_C_O' => 1,
                         'sinclude' => 1,
-                        'AM_CONDITIONAL' => 1,
+                        'AM_PROG_CC_C_O' => 1,
+                        'm4_pattern_allow' => 1,
                         'AC_CANONICAL_SYSTEM' => 1,
+                        'AM_CONDITIONAL' => 1,
                         'AC_CONFIG_HEADERS' => 1,
                         'AC_DEFINE_TRACE_LITERAL' => 1,
                         'm4_include' => 1,
diff -Naur /opt/old/m68k-bdm-1.4-pre2/m68k/gdbserver/m68k-bdm-low.c /opt/m68k-bdm-1.4-pre2/m68k/gdbserver/m68k-bdm-low.c
--- /opt/old/m68k-bdm-1.4-pre2/m68k/gdbserver/m68k-bdm-low.c    2008-02-13 16:05:52.000000000 -0500
+++ /opt/m68k-bdm-1.4-pre2/m68k/gdbserver/m68k-bdm-low.c    2008-05-08 13:38:09.000000000 -0400
@@ -58,6 +58,7 @@
 #define M68K_BDM_MARCH_CF5272     (5)
 #define M68K_BDM_MARCH_CF5282     (6)
 #define M68K_BDM_MARCH_CFV4E      (7)
+#define M68K_BDM_MARCH_CF5307     (8)
 
 /*
  * The CPU labels.
@@ -69,6 +70,7 @@
 #define M68K_BDM_MARCH_CF5235_LABEL    "CF5235"
 #define M68K_BDM_MARCH_CF5272_LABEL    "CF5272"
 #define M68K_BDM_MARCH_CF5282_LABEL    "CF5282"
+#define M68K_BDM_MARCH_CF5307_LABEL    "CF5307"
 #define M68K_BDM_MARCH_CFV4E_LABEL     "CFV4E"
 
 /*
@@ -395,6 +397,38 @@
   { "accext01", M68K_BDM_REG_TYPE_INT32,         40, BDM_REG_CTRL (0x807) },
   { "accext32", M68K_BDM_REG_TYPE_INT32,         41, BDM_REG_CTRL (0x808) }
 };
+/*
+ * 5307 V3 Coldfire Register set
+ */
+static struct m68k_bdm_reg_mapping m68k_bdm_cf5307_reg_map[] = {
+  { "d0",       M68K_BDM_REG_TYPE_INT32,         0,  BDM_REG_D0 },
+  { "d1",       M68K_BDM_REG_TYPE_INT32,         1,  BDM_REG_D1 },
+  { "d2",       M68K_BDM_REG_TYPE_INT32,         2,  BDM_REG_D2 },
+  { "d3",       M68K_BDM_REG_TYPE_INT32,         3,  BDM_REG_D3 },
+  { "d4",       M68K_BDM_REG_TYPE_INT32,         4,  BDM_REG_D4 },
+  { "d5",       M68K_BDM_REG_TYPE_INT32,         5,  BDM_REG_D5 },
+  { "d6",       M68K_BDM_REG_TYPE_INT32,         6,  BDM_REG_D6 },
+  { "d7",       M68K_BDM_REG_TYPE_INT32,         7,  BDM_REG_D7 },
+  { "a0",       M68K_BDM_REG_TYPE_VOID_DATA_PTR, 8,  BDM_REG_A0 },
+  { "a1",       M68K_BDM_REG_TYPE_VOID_DATA_PTR, 9,  BDM_REG_A1 },
+  { "a2",       M68K_BDM_REG_TYPE_VOID_DATA_PTR, 10, BDM_REG_A2 },
+  { "a3",       M68K_BDM_REG_TYPE_VOID_DATA_PTR, 11, BDM_REG_A3 },
+  { "a4",       M68K_BDM_REG_TYPE_VOID_DATA_PTR, 12, BDM_REG_A4 },
+  { "a5",       M68K_BDM_REG_TYPE_VOID_DATA_PTR, 13, BDM_REG_A5 },
+  { "fp",       M68K_BDM_REG_TYPE_VOID_DATA_PTR, 14, BDM_REG_A6 },
+  { "sp",       M68K_BDM_REG_TYPE_VOID_DATA_PTR, 15, BDM_REG_A7 },
+  { "ps",       M68K_BDM_REG_TYPE_INT32,         16, BDM_REG_SR },
+  { "pc",       M68K_BDM_REG_TYPE_INT32,         17, BDM_REG_RPC },
+  { "vbr",      M68K_BDM_REG_TYPE_VOID_DATA_PTR, 18, BDM_REG_CTRL (0x801) },
+  { "cacr",     M68K_BDM_REG_TYPE_INT32,         19, BDM_REG_CTRL (0x002) },
+  { "acr0",     M68K_BDM_REG_TYPE_INT32,         20, BDM_REG_CTRL (0x004) },
+  { "acr1",     M68K_BDM_REG_TYPE_INT32,         21, BDM_REG_CTRL (0x005) },
+  { "rambar",   M68K_BDM_REG_TYPE_INT32,         22, BDM_REG_CTRL (0xc04) },
+  { "mbar",     M68K_BDM_REG_TYPE_INT32,         23, BDM_REG_CTRL (0xc0f) },
+  { "macsr",    M68K_BDM_REG_TYPE_INT32,         24, BDM_REG_CTRL (0x804) },
+  { "mask",     M68K_BDM_REG_TYPE_INT32,         25, BDM_REG_CTRL (0x805) },
+  { "acc",      M68K_BDM_REG_TYPE_INT32,         26, BDM_REG_CTRL (0x806) }
+};
 
 /*
  * V4E Coldfire Register set.
@@ -510,6 +544,8 @@
     m68k_bdm_cf5272_reg_map, M68K_BDM_REG_NUMBER (m68k_bdm_cf5272_reg_map) },
   { "m68k-cf5282.xml",
     m68k_bdm_cf5282_reg_map, M68K_BDM_REG_NUMBER (m68k_bdm_cf5282_reg_map) },
+  { "m68k-cf5307.xml",
+    m68k_bdm_cf5307_reg_map, M68K_BDM_REG_NUMBER (m68k_bdm_cf5307_reg_map) },
   { "m68k-cfv4e.xml",
     m68k_bdm_cfv4e_reg_map, M68K_BDM_REG_NUMBER (m68k_bdm_cfv4e_reg_map) }
 };
@@ -1667,6 +1703,11 @@
         m68k_bdm_cpu_label = M68K_BDM_MARCH_CFV4E_LABEL;
         printf_filtered ("m68k-bdm: detected V4e core\n");
       }
+    else if (m68k_bdm_cf_debug_ver == 1) {
+        m68k_bdm_cpu_type = M68K_BDM_MARCH_CF5307;
+        m68k_bdm_cpu_label = M68K_BDM_MARCH_CF5307_LABEL;
+        printf_filtered ("m68k-bdm: detected MCF5307\n");
+      }
       break;
 
     default:
diff -Naur /opt/old/m68k-bdm-1.4-pre2/m68k/gdbserver/m68k-cf5307.xml /opt/m68k-bdm-1.4-pre2/m68k/gdbserver/m68k-cf5307.xml
--- /opt/old/m68k-bdm-1.4-pre2/m68k/gdbserver/m68k-cf5307.xml    1969-12-31 19:00:00.000000000 -0500
+++ /opt/m68k-bdm-1.4-pre2/m68k/gdbserver/m68k-cf5307.xml    2008-05-08 13:42:18.000000000 -0400
@@ -0,0 +1,25 @@
+<?xml version="1.0"?>
+<!-- Copyright (C) 2007 Free Software Foundation, Inc.
+
+     Copying and distribution of this file, with or without modification,
+     are permitted in any medium without royalty provided the copyright
+     notice and this notice are preserved.  -->
+
+<!DOCTYPE feature SYSTEM "gdb-target.dtd">
+<target>
+  <!-- The 68000 standard registers  -->
+  <xi:include href="m68k-core.xml"/>
+  <!-- This is the name used m68k-tdep.c in GDB. -->
+  <feature name="org.gnu.gdb.coldfire.core">
+    <!-- The 5307 specific registers  -->
+    <reg name="vbr"      bitsize="32" group="system" regnum="18"/>
+    <reg name="cacr"     bitsize="32" group="system" regnum="19"/>
+    <reg name="acr0"     bitsize="32" group="system" regnum="20"/>
+    <reg name="acr1"     bitsize="32" group="system" regnum="21"/>
+    <reg name="rambar"   bitsize="32" group="system" regnum="22"/>
+    <reg name="mbar"     bitsize="32" group="debug"  regnum="23"/>
+    <reg name="macsr"    bitsize="32"                regnum="24"/>
+    <reg name="mask"     bitsize="32"                regnum="25"/>
+    <reg name="acc"      bitsize="32"                regnum="26"/>
+  </feature>
+</target>
diff -Naur /opt/old/m68k-bdm-1.4-pre2/m68k/gdbserver/Makefile.am /opt/m68k-bdm-1.4-pre2/m68k/gdbserver/Makefile.am
--- /opt/old/m68k-bdm-1.4-pre2/m68k/gdbserver/Makefile.am    2008-03-06 05:35:40.000000000 -0500
+++ /opt/m68k-bdm-1.4-pre2/m68k/gdbserver/Makefile.am    2008-05-08 09:15:38.000000000 -0400
@@ -29,7 +29,8 @@
     $(srcdir)/m68k-cf5235.xml \
     $(srcdir)/m68k-cf5272.xml \
     $(srcdir)/m68k-cf5282.xml \
-    $(srcdir)/m68k-cfv4e.xml
+    $(srcdir)/m68k-cfv4e.xml \
+    $(srcdir)/m68k-cf5307.xml
 
 ##
 ## Only way I know of anding in automake.
diff -Naur /opt/old/m68k-bdm-1.4-pre2/m68k/gdbserver/Makefile.in /opt/m68k-bdm-1.4-pre2/m68k/gdbserver/Makefile.in
--- /opt/old/m68k-bdm-1.4-pre2/m68k/gdbserver/Makefile.in    2008-03-18 04:04:18.000000000 -0400
+++ /opt/m68k-bdm-1.4-pre2/m68k/gdbserver/Makefile.in    2008-05-08 09:17:16.000000000 -0400
@@ -198,7 +198,8 @@
     $(srcdir)/m68k-cf5235.xml \
     $(srcdir)/m68k-cf5272.xml \
     $(srcdir)/m68k-cf5282.xml \
-    $(srcdir)/m68k-cfv4e.xml
+    $(srcdir)/m68k-cfv4e.xml \
+    $(srcdir)/m68k-cf5307.xml
 
 @TBLCF_USB_TRUE@TBLCF_USB_LIB = $(top_builddir)/tblcf/libtblcf.a
 @LIBUSB_PATH_TRUE@AM_LDFLAGS = -L@LIBUSB_LIB_DIR@

On Thu, May 8, 2008 at 8:16 PM, Chris Johns <chris@...> wrote:
Mark Giacobbe wrote:
I may have spoke to soon about my changes working.  Looking deeper, it seems if I do a info all-registers, I get the V4E set, which is probably why none of my changes are really working.


Ah ok. Nice observation.


I'm going to keep looking, but if you have any other suggestions or places to look at, I'll be glad to hear them!! :)

I'll try to send my patches for your review to see if I missed anything.


Please send the patch to me and I will take a look. It could be something simple that I forgot to mention.


Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: *****: 5.400000 From3consonants=0.3, DodgySource=2.0, SPF Default Fail=2.5, X-Verify-SMTP present=0.6
X-SpamDetect-Info: ------------- End ASpam results -----------------

Mark Giacobbe wrote:
> The observations that I see makes sense.  Since none of the registers
> are programmed, cs0 will always respond to any memory access, and cs0 is
> programmed by hardware to always to a 32 bit access.
>

Makes sense.

> Here is the patch of my changes.  Please look it over and I'm sure I
> forgot to change something.

Committed to CVS on Sourceforge. Please checkout CVS and test. The ChangeLog is:

2008-05-15 Mark Giacobbe <mcgiacobbe@...>

        * gdbserver/m68k-cf5307.xml: New.

        * gdbserver/Makefile.am: Add m68k-cf5307.xml.

        * gdbserver/m68k-bdm-low.c: Add 5307 support.

2008-05-15 Chris Johns <cjohns@...>

        * README: Fix the TBLCF documentation.

Thanks for the patch.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Chris -

  Did you find anything that I missed?

  And is there a trick to using cvs for sourceforge?  I tried several times, and keep getting:

[pcmadm@localhost ~]$  cvs -d:pserver:anonymous@...:/cvsroot/bdm login
Logging in to :pserver:anonymous@...:2401/cvsroot/bdm
CVS password:
cvs [login aborted]: connect to [bdm.cvs.sourceforge.net]:2401 failed: Connection timed out
[pcmadm@localhost ~]$

I hit "ENTER" for the password.

Thanks
Mark


On Wed, May 14, 2008 at 7:25 PM, Chris Johns <chris@...> wrote:
X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information X-SpamDetect: *****: 5.400000 From3consonants=0.3, DodgySource=2.0, SPF Default Fail=2.5, X-Verify-SMTP present=0.6
X-SpamDetect-Info: ------------- End ASpam results -----------------


Mark Giacobbe wrote:
The observations that I see makes sense.  Since none of the registers are programmed, cs0 will always respond to any memory access, and cs0 is programmed by hardware to always to a 32 bit access.


Makes sense.


Here is the patch of my changes.  Please look it over and I'm sure I forgot to change something.

Committed to CVS on Sourceforge. Please checkout CVS and test. The ChangeLog is:

2008-05-15 Mark Giacobbe <mcgiacobbe@...>

       * gdbserver/m68k-cf5307.xml: New.

       * gdbserver/Makefile.am: Add m68k-cf5307.xml.

       * gdbserver/m68k-bdm-low.c: Add 5307 support.

2008-05-15 Chris Johns <cjohns@...>

       * README: Fix the TBLCF documentation.

Thanks for the patch.


Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information
X-SpamDetect: *****: 5.664000 URL contains username and (optional) password=1.3, From3consonants=0.3, URL contains username=2.9, Uses non-standard port number for HTTP=1.3, X-Verify-SMTP present=0.6, Aspam=-0.8
X-SpamDetect-Info: ------------- End ASpam results -----------------

Mark Giacobbe wrote:
> Hi Chris -
>
>   Did you find anything that I missed?
>

I do not think so. I have not test the 5307 code.

>   And is there a trick to using cvs for sourceforge?  I tried several
> times, and keep getting:
>
> [pcmadm@localhost ~]$  cvs
> -d:pserver:anonymous@...:/cvsroot/bdm login
> Logging in to
> :pserver:anonymous@...:2401/cvsroot/bdm
> <http://pserver:anonymous@...:2401/cvsroot/bdm>
> CVS password:
> cvs [login aborted]: connect to [bdm.cvs.sourceforge.net
> <http://bdm.cvs.sourceforge.net>]:2401 failed: Connection timed out
> [pcmadm@localhost ~]$
>
> I hit "ENTER" for the password.
>

Do you have a firewall blocking this port ?

I have uploaded a tarball of my CVS work area here:

  http://www.rtems.org/ftp/pub/rtems/people/chrisj/bdm/

Can you try this code and let me know how it goes ?

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Well I got your tarball and it seemed to work, but I still couldn't get the memory stuff to work correctly.  So going back and re-re-re-reading the README files, I realized that my gdb script was still of the old version, and I wasn't obvious to me that I had to change my script.  I attached the new gdb script below for everyone's reference.

#
# gdb script for the MCF5307
#

define addresses

echo \nSetup internal registers\n

set $mbar  = 0x10000001
# Needed for the new bdm gdbserver
monitor bdm-ctl-set 0xc0f 0x10000001
set $rsr   = $mbar - 1 + 0x000
set $sypcr = $mbar - 1 + 0x001
set $swivr = $mbar - 1 + 0x002
set $swsr  = $mbar - 1 + 0x003
set $simr  = $mbar - 1 + 0x003
set $par   = $mbar - 1 + 0x004
set $irqpar= $mbar - 1 + 0x006
set $pllcr = $mbar - 1 + 0x008
set $mpark = $mbar - 1 + 0x00c
set $ipr   = $mbar - 1 + 0x040
set $imr   = $mbar - 1 + 0x044

set $icr0  = $mbar - 1 + 0x04c
set $icr1  = $mbar - 1 + 0x04d
set $icr2  = $mbar - 1 + 0x04e
set $icr3  = $mbar - 1 + 0x04f
set $icr4  = $mbar - 1 + 0x050
set $icr5  = $mbar - 1 + 0x051
set $icr6  = $mbar - 1 + 0x052
set $icr7  = $mbar - 1 + 0x053
set $icr8  = $mbar - 1 + 0x054
set $icr9  = $mbar - 1 + 0x055
set $icr10 = $mbar - 1 + 0x056
set $icr11 = $mbar - 1 + 0x057

set $csar0 = $mbar - 1 + 0x080
set $csmr0 = $mbar - 1 + 0x084
set $cscr0 = $mbar - 1 + 0x08a
set $csar1 = $mbar - 1 + 0x08c
set $csmr1 = $mbar - 1 + 0x090
set $cscr1 = $mbar - 1 + 0x096
set $csar2 = $mbar - 1 + 0x098
set $csmr2 = $mbar - 1 + 0x09c
set $cscr2 = $mbar - 1 + 0x0a2
set $csar3 = $mbar - 1 + 0x0a4
set $csmr3 = $mbar - 1 + 0x0a8
set $cscr3 = $mbar - 1 + 0x0ae
set $csar4 = $mbar - 1 + 0x0b0
set $csmr4 = $mbar - 1 + 0x0b4
set $cscr4 = $mbar - 1 + 0x0ba
set $csar5 = $mbar - 1 + 0x0bc
set $csmr5 = $mbar - 1 + 0x0c0
set $cscr5 = $mbar - 1 + 0x0c4
set $csar6 = $mbar - 1 + 0x0c6
set $csmr6 = $mbar - 1 + 0x0d0
set $cscr6 = $mbar - 1 + 0x0d2
set $csar7 = $mbar - 1 + 0x0d4
set $csmr7 = $mbar - 1 + 0x0d8
set $cscr7 = $mbar - 1 + 0x0de

set $dcr   = $mbar - 1 + 0x100
set $dacr0 = $mbar - 1 + 0x108
set $dmr0  = $mbar - 1 + 0x10c
set $dacr1 = $mbar - 1 + 0x110
set $dmr1  = $mbar - 1 + 0x114

set $tmr1  = $mbar - 1 + 0x140
set $trr1  = $mbar - 1 + 0x144
set $tcr1  = $mbar - 1 + 0x148
set $tcn1  = $mbar - 1 + 0x14C
set $ter1  = $mbar - 1 + 0x151
set $tmr2  = $mbar - 1 + 0x180
set $trr2  = $mbar - 1 + 0x184
set $tcr2  = $mbar - 1 + 0x188
set $tcn2  = $mbar - 1 + 0x18C
set $ter2  = $mbar - 1 + 0x191

set $paddr = $mbar - 1 + 0x244
set $padat = $mbar - 1 + 0x248

end

#
#  Setup RAMBAR for the internal SRAM.
#

define setup-sram

echo \nSetup internal SRAM\n

set $rambar  = 0x20000001
# Needed for the new bdm gdbserver
monitor bdm-ctl-set 0xc04 0x20000001
end


#
#       Setup Parallel I/O ports...
#

define setup-pp

echo \nSetup GPIO\n

set *((unsigned short *) $par) = 0x0100
set *((unsigned short *) $paddr) = 0xb0ec
set *((unsigned short *) $padat) = 0x76fd
end


#
#  Setup chip selects...
#

define setup-cs

echo \nSetup Chip Selects\n

# CS1
set *((unsigned short *) $csar1) = 0xA080
set *((unsigned long *) $csmr1)  = 0x00010047
set *((unsigned short *) $cscr1) = 0x1540

# CS2
set *((unsigned short *) $csar2) = 0xA004
set *((unsigned long *) $csmr2)  = 0x00000047
set *((unsigned short *) $cscr2) = 0x2940

# CS3
set *((unsigned short *) $csar3) = 0x0070
set *((unsigned long *) $csmr3)  = 0x00070047
set *((unsigned short *) $cscr3) = 0x0970

# CS4
set *((unsigned short *) $csar4) = 0xA090
set *((unsigned long *) $csmr4)  = 0x00010047
set *((unsigned short *) $cscr4) = 0x1DA0

# CS5
set *((unsigned short *) $csar5) = 0xA000
set *((unsigned long *) $csmr5)  = 0x00010047
set *((unsigned short *) $cscr5) = 0x0D80

# CS6
set *((unsigned short *) $csar6) = 0xA070
set *((unsigned long *) $csmr6)  = 0x00010047
set *((unsigned short *) $cscr6) = 0x0940

# CS7
set *((unsigned short *) $csar7) = 0xA0C0
set *((unsigned long *) $csmr7)  = 0x00030047
set *((unsigned short *) $cscr7) = 0x0980

# CS0
set *((unsigned short *) $csar0) = 0x0000
set *((unsigned long *) $csmr0)  = 0x001f0047
set *((unsigned short *) $cscr0) = 0x0500

end

#
# Set up SDRAM
#
define setup-sdram

echo \nSetup SDRAM\n

# Power up sequence
set *((unsigned short *) $dcr) = 0x8002
set *((unsigned long *) $dacr0) = 0xB0001404
set *((unsigned long *) $dmr0) = 0x01FC0001
# Pre-charge sequence
set *((unsigned long *) $dacr0) = 0xB000140C
set *((unsigned long *) 0xB0000000) = 0xBEADDEED
# Refresh Sequence
echo \n     SDRAM refresh\n
# Mode register init sequence
set *((unsigned long *) $dacr0) = 0xB0009444
set *((unsigned long *) 0xB0000400) = 0xB0009444
set *((unsigned long *) $dacr0) = 0xB0009404

end

#
# Some useful tools
#
define set8
 set *((unsigned char*) $arg0) = $arg1
end

document set8
Set 8bit memory: set8 ADDRESS VALUE
end

define set16
 set *((unsigned short*) $arg0) = $arg1
end

document set16
Set 16bit memory: set16 ADDRESS VALUE
end

define set32
 set *((unsigned long*) $arg0) = $arg1
end

document set32
Set 32bit memory: set32 ADDRESS VALUE
end

define d8
 x /$arg1b $arg0
end

document d8
Dump 8bit memory: d8 ADDRESS LENGTH
end

define d16
 x /$arg1h $arg0
end

document d16
Dump 16bit memory: d16 ADDRESS LENGTH
end

define d32
 x /$arg1w $arg0
end

document d32
Dump 32bit memory: d32 ADDRESS LENGTH
end


#
#       Init the target...
#
target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0

echo\nResetting uP\n
monitor bdm-reset
addresses
setup-sram
setup-cs
setup-pp
setup-sdram

set print pretty
set print asm-demangle
display/i $pc
select-frame 0

So is there any other "gotcha" that I have to look out for in my script?

I will continue testing, but things are looking a lot better then they were.

I am also documenting all of this.  When I am finished, I will post it here, and if you want to Chris, you can include it in the distro for the bdm.

Chris - feel free to include the above script in the distro for the bdm.


Thanks for all of your help!
Mark

On Tue, May 20, 2008 at 2:40 AM, Chris Johns <chris@...> wrote:
X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information X-SpamDetect: *****: 5.664000 URL contains username and (optional) password=1.3, From3consonants=0.3, URL contains username=2.9, Uses non-standard port number for HTTP=1.3, X-Verify-SMTP present=0.6, Aspam=-0.8

X-SpamDetect-Info: ------------- End ASpam results -----------------

Mark Giacobbe wrote:
Hi Chris -

 Did you find anything that I missed?


I do not think so. I have not test the 5307 code.

 And is there a trick to using cvs for sourceforge?  I tried several times, and keep getting:

[pcmadm@localhost ~]$  cvs -d:pserver:anonymous@...:/cvsroot/bdm login
Logging in to :pserver:anonymous@...:2401/cvsroot/bdm <http://pserver:anonymous@...:2401/cvsroot/bdm>
CVS password:
cvs [login aborted]: connect to [bdm.cvs.sourceforge.net <http://bdm.cvs.sourceforge.net>]:2401 failed: Connection timed out

[pcmadm@localhost ~]$

I hit "ENTER" for the password.


Do you have a firewall blocking this port ?

I have uploaded a tarball of my CVS work area here:

 http://www.rtems.org/ftp/pub/rtems/people/chrisj/bdm/

Can you try this code and let me know how it goes ?


Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Mark,

I am starting to suspect the register cache again. I have someone else with a
problem related to this. Looks like I need to fix it. I will see what I can do.

Regards
Chris

Mark Giacobbe wrote:

> Well I got your tarball and it seemed to work, but I still couldn't get
> the memory stuff to work correctly.  So going back and re-re-re-reading
> the README files, I realized that my gdb script was still of the old
> version, and I wasn't obvious to me that I had to change my script.  I
> attached the new gdb script below for everyone's reference.
>
> #
> # gdb script for the MCF5307
> #
>
> define addresses
>
> echo \nSetup internal registers\n
>
> set $mbar  = 0x10000001
> # Needed for the new bdm gdbserver
> monitor bdm-ctl-set 0xc0f 0x10000001
> set $rsr   = $mbar - 1 + 0x000
> set $sypcr = $mbar - 1 + 0x001
> set $swivr = $mbar - 1 + 0x002
> set $swsr  = $mbar - 1 + 0x003
> set $simr  = $mbar - 1 + 0x003
> set $par   = $mbar - 1 + 0x004
> set $irqpar= $mbar - 1 + 0x006
> set $pllcr = $mbar - 1 + 0x008
> set $mpark = $mbar - 1 + 0x00c
> set $ipr   = $mbar - 1 + 0x040
> set $imr   = $mbar - 1 + 0x044
>
> set $icr0  = $mbar - 1 + 0x04c
> set $icr1  = $mbar - 1 + 0x04d
> set $icr2  = $mbar - 1 + 0x04e
> set $icr3  = $mbar - 1 + 0x04f
> set $icr4  = $mbar - 1 + 0x050
> set $icr5  = $mbar - 1 + 0x051
> set $icr6  = $mbar - 1 + 0x052
> set $icr7  = $mbar - 1 + 0x053
> set $icr8  = $mbar - 1 + 0x054
> set $icr9  = $mbar - 1 + 0x055
> set $icr10 = $mbar - 1 + 0x056
> set $icr11 = $mbar - 1 + 0x057
>
> set $csar0 = $mbar - 1 + 0x080
> set $csmr0 = $mbar - 1 + 0x084
> set $cscr0 = $mbar - 1 + 0x08a
> set $csar1 = $mbar - 1 + 0x08c
> set $csmr1 = $mbar - 1 + 0x090
> set $cscr1 = $mbar - 1 + 0x096
> set $csar2 = $mbar - 1 + 0x098
> set $csmr2 = $mbar - 1 + 0x09c
> set $cscr2 = $mbar - 1 + 0x0a2
> set $csar3 = $mbar - 1 + 0x0a4
> set $csmr3 = $mbar - 1 + 0x0a8
> set $cscr3 = $mbar - 1 + 0x0ae
> set $csar4 = $mbar - 1 + 0x0b0
> set $csmr4 = $mbar - 1 + 0x0b4
> set $cscr4 = $mbar - 1 + 0x0ba
> set $csar5 = $mbar - 1 + 0x0bc
> set $csmr5 = $mbar - 1 + 0x0c0
> set $cscr5 = $mbar - 1 + 0x0c4
> set $csar6 = $mbar - 1 + 0x0c6
> set $csmr6 = $mbar - 1 + 0x0d0
> set $cscr6 = $mbar - 1 + 0x0d2
> set $csar7 = $mbar - 1 + 0x0d4
> set $csmr7 = $mbar - 1 + 0x0d8
> set $cscr7 = $mbar - 1 + 0x0de
>
> set $dcr   = $mbar - 1 + 0x100
> set $dacr0 = $mbar - 1 + 0x108
> set $dmr0  = $mbar - 1 + 0x10c
> set $dacr1 = $mbar - 1 + 0x110
> set $dmr1  = $mbar - 1 + 0x114
>
> set $tmr1  = $mbar - 1 + 0x140
> set $trr1  = $mbar - 1 + 0x144
> set $tcr1  = $mbar - 1 + 0x148
> set $tcn1  = $mbar - 1 + 0x14C
> set $ter1  = $mbar - 1 + 0x151
> set $tmr2  = $mbar - 1 + 0x180
> set $trr2  = $mbar - 1 + 0x184
> set $tcr2  = $mbar - 1 + 0x188
> set $tcn2  = $mbar - 1 + 0x18C
> set $ter2  = $mbar - 1 + 0x191
>
> set $paddr = $mbar - 1 + 0x244
> set $padat = $mbar - 1 + 0x248
>
> end
>
> #
> #  Setup RAMBAR for the internal SRAM.
> #
>
> define setup-sram
>
> echo \nSetup internal SRAM\n
>
> set $rambar  = 0x20000001
> # Needed for the new bdm gdbserver
> monitor bdm-ctl-set 0xc04 0x20000001
> end
>
>
> #
> #       Setup Parallel I/O ports...
> #
>
> define setup-pp
>
> echo \nSetup GPIO\n
>
> set *((unsigned short *) $par) = 0x0100
> set *((unsigned short *) $paddr) = 0xb0ec
> set *((unsigned short *) $padat) = 0x76fd
> end
>
>
> #
> #  Setup chip selects...
> #
>
> define setup-cs
>
> echo \nSetup Chip Selects\n
>
> # CS1
> set *((unsigned short *) $csar1) = 0xA080
> set *((unsigned long *) $csmr1)  = 0x00010047
> set *((unsigned short *) $cscr1) = 0x1540
>
> # CS2
> set *((unsigned short *) $csar2) = 0xA004
> set *((unsigned long *) $csmr2)  = 0x00000047
> set *((unsigned short *) $cscr2) = 0x2940
>
> # CS3
> set *((unsigned short *) $csar3) = 0x0070
> set *((unsigned long *) $csmr3)  = 0x00070047
> set *((unsigned short *) $cscr3) = 0x0970
>
> # CS4
> set *((unsigned short *) $csar4) = 0xA090
> set *((unsigned long *) $csmr4)  = 0x00010047
> set *((unsigned short *) $cscr4) = 0x1DA0
>
> # CS5
> set *((unsigned short *) $csar5) = 0xA000
> set *((unsigned long *) $csmr5)  = 0x00010047
> set *((unsigned short *) $cscr5) = 0x0D80
>
> # CS6
> set *((unsigned short *) $csar6) = 0xA070
> set *((unsigned long *) $csmr6)  = 0x00010047
> set *((unsigned short *) $cscr6) = 0x0940
>
> # CS7
> set *((unsigned short *) $csar7) = 0xA0C0
> set *((unsigned long *) $csmr7)  = 0x00030047
> set *((unsigned short *) $cscr7) = 0x0980
>
> # CS0
> set *((unsigned short *) $csar0) = 0x0000
> set *((unsigned long *) $csmr0)  = 0x001f0047
> set *((unsigned short *) $cscr0) = 0x0500
>
> end
>
> #
> # Set up SDRAM
> #
> define setup-sdram
>
> echo \nSetup SDRAM\n
>
> # Power up sequence
> set *((unsigned short *) $dcr) = 0x8002
> set *((unsigned long *) $dacr0) = 0xB0001404
> set *((unsigned long *) $dmr0) = 0x01FC0001
> # Pre-charge sequence
> set *((unsigned long *) $dacr0) = 0xB000140C
> set *((unsigned long *) 0xB0000000) = 0xBEADDEED
> # Refresh Sequence
> echo \n     SDRAM refresh\n
> # Mode register init sequence
> set *((unsigned long *) $dacr0) = 0xB0009444
> set *((unsigned long *) 0xB0000400) = 0xB0009444
> set *((unsigned long *) $dacr0) = 0xB0009404
>
> end
>
> #
> # Some useful tools
> #
> define set8
>  set *((unsigned char*) $arg0) = $arg1
> end
>
> document set8
> Set 8bit memory: set8 ADDRESS VALUE
> end
>
> define set16
>  set *((unsigned short*) $arg0) = $arg1
> end
>
> document set16
> Set 16bit memory: set16 ADDRESS VALUE
> end
>
> define set32
>  set *((unsigned long*) $arg0) = $arg1
> end
>
> document set32
> Set 32bit memory: set32 ADDRESS VALUE
> end
>
> define d8
>  x /$arg1b $arg0
> end
>
> document d8
> Dump 8bit memory: d8 ADDRESS LENGTH
> end
>
> define d16
>  x /$arg1h $arg0
> end
>
> document d16
> Dump 16bit memory: d16 ADDRESS LENGTH
> end
>
> define d32
>  x /$arg1w $arg0
> end
>
> document d32
> Dump 32bit memory: d32 ADDRESS LENGTH
> end
>
>
> #
> #       Init the target...
> #
> target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0
>
> echo\nResetting uP\n
> monitor bdm-reset
> addresses
> setup-sram
> setup-cs
> setup-pp
> setup-sdram
>
> set print pretty
> set print asm-demangle
> display/i $pc
> select-frame 0
>
> So is there any other "gotcha" that I have to look out for in my script?
>
> I will continue testing, but things are looking a lot better then they were.
>
> I am also documenting all of this.  When I am finished, I will post it
> here, and if you want to Chris, you can include it in the distro for the
> bdm.
>
> Chris - feel free to include the above script in the distro for the bdm.
>
>
> Thanks for all of your help!
> Mark
>
> On Tue, May 20, 2008 at 2:40 AM, Chris Johns <chris@...
> <mailto:chris@...>> wrote:
>
>     X-SpamDetect-Info: ------------- Start ASpam results ---------------
>     X-SpamDetect-Info: This message may be spam. This message BODY has
>     been altered to show you the spam information X-SpamDetect: *****:
>     5.664000 URL contains username and (optional) password=1.3,
>     From3consonants=0.3, URL contains username=2.9, Uses non-standard
>     port number for HTTP=1.3, X-Verify-SMTP present=0.6, Aspam=-0.8
>
>     X-SpamDetect-Info: ------------- End ASpam results -----------------
>
>     Mark Giacobbe wrote:
>
>         Hi Chris -
>
>          Did you find anything that I missed?
>
>
>     I do not think so. I have not test the 5307 code.
>
>          And is there a trick to using cvs for sourceforge?  I tried
>         several times, and keep getting:
>
>         [pcmadm@localhost ~]$  cvs
>         -d:pserver:anonymous@...:/cvsroot/bdm login
>         Logging in to
>         :pserver:anonymous@...:2401/cvsroot/bdm
>         <http://pserver:anonymous@...:2401/cvsroot/bdm>
>         <http://pserver:anonymous@...:2401/cvsroot/bdm>
>         CVS password:
>         cvs [login aborted]: connect to [bdm.cvs.sourceforge.net
>         <http://bdm.cvs.sourceforge.net>
>         <http://bdm.cvs.sourceforge.net>]:2401 failed: Connection timed out
>
>         [pcmadm@localhost ~]$
>
>         I hit "ENTER" for the password.
>
>
>     Do you have a firewall blocking this port ?
>
>     I have uploaded a tarball of my CVS work area here:
>
>      http://www.rtems.org/ftp/pub/rtems/people/chrisj/bdm/
>
>     Can you try this code and let me know how it goes ?
>
>
>     Regards
>     Chris
>     ---
>     coldfire@... <mailto:coldfire@...>            
>      Send a post to the list.
>     coldfire-join@... <mailto:coldfire-join@...>      
>      Join the list.
>     coldfire-digest@... <mailto:coldfire-digest@...>  
>      Join the list in digest mode.
>     coldfire-leave@... <mailto:coldfire-leave@...>    
>     Leave the list.
>
>
> coldfire@... Send a post to the list.
> coldfire-join@... Join the list. coldfire-digest@...
> Join the list in digest mode. coldfire-leave@... Leave the list.
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


Re: Help with building gdb with BDM support for the Coldfire

by Mark Giacobbe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Using the attached script, although I am still testing, it seems that my debugging system is working.  My memory issues are gone, and I can access the correct memory locations, with the correct access sizes.

I had to add the
    monitor bdm-ctl-set
command for the mbar and rambar addresses.  The old way of "set $mbar" did not work with the new gdbserver.

Later this week, or beginning of next week, I will download CoLiLo to my target and see if it works.  I will then test the breakpoints, watches, etc.

Thanks for your help
Mark


On Wed, May 21, 2008 at 9:10 PM, Chris Johns <chris@...> wrote:
Hi Mark,

I am starting to suspect the register cache again. I have someone else with a problem related to this. Looks like I need to fix it. I will see what I can do.

Regards
Chris

Mark Giacobbe wrote:
Well I got your tarball and it seemed to work, but I still couldn't get the memory stuff to work correctly.  So going back and re-re-re-reading the README files, I realized that my gdb script was still of the old version, and I wasn't obvious to me that I had to change my script.  I attached the new gdb script below for everyone's reference.

#
# gdb script for the MCF5307
#

define addresses

echo \nSetup internal registers\n

set $mbar  = 0x10000001
# Needed for the new bdm gdbserver
monitor bdm-ctl-set 0xc0f 0x10000001
set $rsr   = $mbar - 1 + 0x000
set $sypcr = $mbar - 1 + 0x001
set $swivr = $mbar - 1 + 0x002
set $swsr  = $mbar - 1 + 0x003
set $simr  = $mbar - 1 + 0x003
set $par   = $mbar - 1 + 0x004
set $irqpar= $mbar - 1 + 0x006
set $pllcr = $mbar - 1 + 0x008
set $mpark = $mbar - 1 + 0x00c
set $ipr   = $mbar - 1 + 0x040
set $imr   = $mbar - 1 + 0x044

set $icr0  = $mbar - 1 + 0x04c
set $icr1  = $mbar - 1 + 0x04d
set $icr2  = $mbar - 1 + 0x04e
set $icr3  = $mbar - 1 + 0x04f
set $icr4  = $mbar - 1 + 0x050
set $icr5  = $mbar - 1 + 0x051
set $icr6  = $mbar - 1 + 0x052
set $icr7  = $mbar - 1 + 0x053
set $icr8  = $mbar - 1 + 0x054
set $icr9  = $mbar - 1 + 0x055
set $icr10 = $mbar - 1 + 0x056
set $icr11 = $mbar - 1 + 0x057

set $csar0 = $mbar - 1 + 0x080
set $csmr0 = $mbar - 1 + 0x084
set $cscr0 = $mbar - 1 + 0x08a
set $csar1 = $mbar - 1 + 0x08c
set $csmr1 = $mbar - 1 + 0x090
set $cscr1 = $mbar - 1 + 0x096
set $csar2 = $mbar - 1 + 0x098
set $csmr2 = $mbar - 1 + 0x09c
set $cscr2 = $mbar - 1 + 0x0a2
set $csar3 = $mbar - 1 + 0x0a4
set $csmr3 = $mbar - 1 + 0x0a8
set $cscr3 = $mbar - 1 + 0x0ae
set $csar4 = $mbar - 1 + 0x0b0
set $csmr4 = $mbar - 1 + 0x0b4
set $cscr4 = $mbar - 1 + 0x0ba
set $csar5 = $mbar - 1 + 0x0bc
set $csmr5 = $mbar - 1 + 0x0c0
set $cscr5 = $mbar - 1 + 0x0c4
set $csar6 = $mbar - 1 + 0x0c6
set $csmr6 = $mbar - 1 + 0x0d0
set $cscr6 = $mbar - 1 + 0x0d2
set $csar7 = $mbar - 1 + 0x0d4
set $csmr7 = $mbar - 1 + 0x0d8
set $cscr7 = $mbar - 1 + 0x0de

set $dcr   = $mbar - 1 + 0x100
set $dacr0 = $mbar - 1 + 0x108
set $dmr0  = $mbar - 1 + 0x10c
set $dacr1 = $mbar - 1 + 0x110
set $dmr1  = $mbar - 1 + 0x114

set $tmr1  = $mbar - 1 + 0x140
set $trr1  = $mbar - 1 + 0x144
set $tcr1  = $mbar - 1 + 0x148
set $tcn1  = $mbar - 1 + 0x14C
set $ter1  = $mbar - 1 + 0x151
set $tmr2  = $mbar - 1 + 0x180
set $trr2  = $mbar - 1 + 0x184
set $tcr2  = $mbar - 1 + 0x188
set $tcn2  = $mbar - 1 + 0x18C
set $ter2  = $mbar - 1 + 0x191

set $paddr = $mbar - 1 + 0x244
set $padat = $mbar - 1 + 0x248

end

#
#  Setup RAMBAR for the internal SRAM.
#

define setup-sram

echo \nSetup internal SRAM\n

set $rambar  = 0x20000001
# Needed for the new bdm gdbserver
monitor bdm-ctl-set 0xc04 0x20000001
end


#
#       Setup Parallel I/O ports...
#

define setup-pp

echo \nSetup GPIO\n

set *((unsigned short *) $par) = 0x0100
set *((unsigned short *) $paddr) = 0xb0ec
set *((unsigned short *) $padat) = 0x76fd
end


#
#  Setup chip selects...
#

define setup-cs

echo \nSetup Chip Selects\n

# CS1
set *((unsigned short *) $csar1) = 0xA080
set *((unsigned long *) $csmr1)  = 0x00010047
set *((unsigned short *) $cscr1) = 0x1540

# CS2
set *((unsigned short *) $csar2) = 0xA004
set *((unsigned long *) $csmr2)  = 0x00000047
set *((unsigned short *) $cscr2) = 0x2940

# CS3
set *((unsigned short *) $csar3) = 0x0070
set *((unsigned long *) $csmr3)  = 0x00070047
set *((unsigned short *) $cscr3) = 0x0970

# CS4
set *((unsigned short *) $csar4) = 0xA090
set *((unsigned long *) $csmr4)  = 0x00010047
set *((unsigned short *) $cscr4) = 0x1DA0

# CS5
set *((unsigned short *) $csar5) = 0xA000
set *((unsigned long *) $csmr5)  = 0x00010047
set *((unsigned short *) $cscr5) = 0x0D80

# CS6
set *((unsigned short *) $csar6) = 0xA070
set *((unsigned long *) $csmr6)  = 0x00010047
set *((unsigned short *) $cscr6) = 0x0940

# CS7
set *((unsigned short *) $csar7) = 0xA0C0
set *((unsigned long *) $csmr7)  = 0x00030047
set *((unsigned short *) $cscr7) = 0x0980

# CS0
set *((unsigned short *) $csar0) = 0x0000
set *((unsigned long *) $csmr0)  = 0x001f0047
set *((unsigned short *) $cscr0) = 0x0500

end

#
# Set up SDRAM
#
define setup-sdram

echo \nSetup SDRAM\n

# Power up sequence
set *((unsigned short *) $dcr) = 0x8002
set *((unsigned long *) $dacr0) = 0xB0001404
set *((unsigned long *) $dmr0) = 0x01FC0001
# Pre-charge sequence
set *((unsigned long *) $dacr0) = 0xB000140C
set *((unsigned long *) 0xB0000000) = 0xBEADDEED
# Refresh Sequence
echo \n     SDRAM refresh\n
# Mode register init sequence
set *((unsigned long *) $dacr0) = 0xB0009444
set *((unsigned long *) 0xB0000400) = 0xB0009444
set *((unsigned long *) $dacr0) = 0xB0009404

end

#
# Some useful tools
#
define set8
 set *((unsigned char*) $arg0) = $arg1
end

document set8
Set 8bit memory: set8 ADDRESS VALUE
end

define set16
 set *((unsigned short*) $arg0) = $arg1
end

document set16
Set 16bit memory: set16 ADDRESS VALUE
end

define set32
 set *((unsigned long*) $arg0) = $arg1
end

document set32
Set 32bit memory: set32 ADDRESS VALUE
end

define d8
 x /$arg1b $arg0
end

document d8
Dump 8bit memory: d8 ADDRESS LENGTH
end

define d16
 x /$arg1h $arg0
end

document d16
Dump 16bit memory: d16 ADDRESS LENGTH
end

define d32
 x /$arg1w $arg0
end

document d32
Dump 32bit memory: d32 ADDRESS LENGTH
end


#
#       Init the target...
#
target remote | m68k-bdm-gdbserver pipe /dev/bdmcf0

echo\nResetting uP\n
monitor bdm-reset
addresses
setup-sram
setup-cs
setup-pp
setup-sdram

set print pretty
set print asm-demangle
display/i $pc
select-frame 0

So is there any other "gotcha" that I have to look out for in my script?

I will continue testing, but things are looking a lot better then they were.

I am also documenting all of this.  When I am finished, I will post it here, and if you want to Chris, you can include it in the distro for the bdm.

Chris - feel free to include the above script in the distro for the bdm.


Thanks for all of your help!
Mark

On Tue, May 20, 2008 at 2:40 AM, Chris Johns <chris@... <mailto:chris@...>> wrote:

   X-SpamDetect-Info: ------------- Start ASpam results ---------------
   X-SpamDetect-Info: This message may be spam. This message BODY has
   been altered to show you the spam information X-SpamDetect: *****:
   5.664000 URL contains username and (optional) password=1.3,
   From3consonants=0.3, URL contains username=2.9, Uses non-standard
   port number for HTTP=1.3, X-Verify-SMTP present=0.6, Aspam=-0.8

   X-SpamDetect-Info: ------------- End ASpam results -----------------

   Mark Giacobbe wrote:

       Hi Chris -

        Did you find anything that I missed?


   I do not think so. I have not test the 5307 code.

        And is there a trick to using cvs for sourceforge?  I tried
       several times, and keep getting:

       [pcmadm@localhost ~]$  cvs
       -d:pserver:anonymous@...:/cvsroot/bdm login
       Logging in to
       :pserver:anonymous@...:2401/cvsroot/bdm
       <http://pserver:anonymous@...:2401/cvsroot/bdm>
       <http://pserver:anonymous@...:2401/cvsroot/bdm>
       CVS password:
       cvs [login aborted]: connect to [bdm.cvs.sourceforge.net
       <http://bdm.cvs.sourceforge.net>
       <http://bdm.cvs.sourceforge.net>]:2401 failed: Connection timed out

       [pcmadm@localhost ~]$

       I hit "ENTER" for the password.


   Do you have a firewall blocking this port ?

   I have uploaded a tarball of my CVS work area here:

    http://www.rtems.org/ftp/pub/rtems/people/chrisj/bdm/

   Can you try this code and let me know how it goes ?


   Regards
   Chris
   ---
   coldfire@... <mailto:coldfire@...>                 Send a post to the list.
   coldfire-join@... <mailto:coldfire-join@...>           Join the list.
   coldfire-digest@... <mailto:coldfire-digest@...>       Join the list in digest mode.
   coldfire-leave@... <mailto:coldfire-leave@...>        Leave the list.



coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.


coldfire@... Send a post to the list. coldfire-join@... Join the list. coldfire-digest@... Join the list in digest mode. coldfire-leave@... Leave the list.

Re: Help with building gdb with BDM support for the Coldfire

by Chris Johns-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mark Giacobbe wrote:
> Using the attached script, although I am still testing, it seems that my
> debugging system is working.  My memory issues are gone, and I can
> access the correct memory locations, with the correct access sizes.
>
> I had to add the
>     monitor bdm-ctl-set
> command for the mbar and rambar addresses.  The old way of "set $mbar"
> did not work with the new gdbserver.

This is the register cache issue. I am currently fixing this while I add 52223
(52235) support. The bdm-ctl-set exposes other issues which you are not seeing.

>
> Later this week, or beginning of next week, I will download CoLiLo to my
> target and see if it works.  I will then test the breakpoints, watches, etc.
>

I should have the register cache issue fixed by then.

Regards
Chris
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

< Prev | 1 - 2 | Next >