Jesper Skov wrote: > > >>>>> "Rolf" == Rolf Fiedler <Rolf.Fiedler at Ferrari.DE> writes: > > Rolf> Hi there, > > Rolf> currently we are looking for a solution to debug gcc generated > Rolf> code on the PPC405GP target. All debuggers I have found so far > Rolf> are hosted on Win9x/NT. This is sub-optimal, since our > Rolf> tool-chain is hosted on linux. > > Rolf> I know that I can use gdb with a gdb-server running on the > Rolf> target, however I prefer access to the JTAG debug port of the > Rolf> PPC405GP. The Macraigor Wiggler devices support JTAG debugging > > I don't think this would work (or at least not easily). When you > access the target through a wiggler it's at a very low level (on the > CPU, basically - you don't communicate with software in the > target). You are right here, very low level... I need so send a bitstream containing commands and register values etc. It has been done for a number of gdb targets (CPU32, Coldfire, MPC8xx).
There a different types of gdb targets - remote targets that communicate the gdb remote protocol with a gdbserver AND "native" remote targets that have the ability to control the target (via hardware) directly. I have done a gdb target for Motorolas coldfire processors using BDM on the parallel port. gdb talks with a linux kernel driver that toggles the bits in the parallel-port dongle that start/stop/control the CPU. > For debugging an application you need to communicate with gdbserver - > ethernet is the optimal solution, if your board has > ethernet. Otherwise you have to use serial. this is plain wrong. I do not have to use gdbserver, gdbserver is just one possiblity. How can I use the hardware breakpoints in the debug-hardware on the target or have breakpoints in ROM when I use a low-tech debug approach like gdbserver? You are right about ethernet being optimal, but only in one domain. If you have the hardware up and running an are a software type of guy that has to develop firmware, then the improved download speeds of the ethernet/ gdbserver solution make you forget about the reduced debugging capabilities. > You may be able to make the wiggler work as a regular serial > connection, but I don't see what you gain by that over using a > standard ethernet/serial connection (except if the only interface on > the board is the wiggler one). It would be not very smart to reduce the wiggler to a regular serial connection, since I have more features then I can address with the gdb remote protocol. The advantages are: - no software on the target (bootstrapping) - use of 4 hw address and 2 hw data breakpoints (try to use a watchpoint with gdbserver and you'll learn what performance really means :-) -- +-----------------+-------------------------------------------------+ | _____ | Rolf Fiedler (Electronic Design Engineer) | | / ___/ | Ferrari electronic AG | | / _/ | phone: +49 3328 4559 0 fax: +49 3328 4559 60 | | /_/e/r/r/a/r/i/ | <http://www.Ferrari.DE> | | electronic AG | <mailto:Rolf.Fiedler at Ferrari.DE> | +-----------------+-------------------------------------------------+ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
