GDB or Insight across ethernet

ChrisQuayle wrote:
> David Brown wrote:
> 
>> In the case of the Freescale bdm gdb drivers (they're the ones I know 
>> in most detail), the gdb library (almost) directly accesses the 
>> parallel port.  Off hand, I can't remember if it uses in/out 
>> instructions itself in the latest versions, or goes through ioctl 
>> calls, but it processes every bit individually.  For the bdm, every 
>> transaction is 17 bits, with synchronous writing and reading - that 
>> does not match any general purpose parallel port protocol.  For jtag 
>> connections, you want continuous streams of synchronous bits.  In each 
>> case, you need to set the clock bit, set the data out bit, toggle the 
>> clock bit, read the data in bit, rinse and repeat.  You can't do that 
>> over an Ethernet line in a sensible time frame - the latency is too high.
> 
> 
> Don't know much about bdm, though have used cig packet style adapters 
> for development. 17 bits sounds a bi odd ball, though one could 
> serialise/deserialise in a bit of added hardware to allow connection to 
> a parallel data source. I do see what you mean about ethernet though. 
> Effectively, each clocked bit would require 2 ethernet frames, plus the 
> transition time through the stack at each end, for each frame. As you 
> say, it's probably not viable in throughput terms. Perhaps another 
> appoach might be to add a little hardware, or even a low cost micro to 
> convert serial rs232 or parallel port format to jtag. Does start to get 
> a bit convoluted though and if you do that, you may just as well include 
> the gdb remote server code in the adapter as well.
> 
> Food for thought though and will try to find a way. Network based debug 
> would provide ultimate flexibility in terms of choice of development 
> hardware, os etc...
> 
> Chris

The bit counts in JTAG chains are pretty odd, e.g. 33 and 108 bits
for the basic chains of an ARM7TDMI.

-- 

Tauno Voipio
tauno voipio (at) iki fi

ChrisQuayle wrote:
> David Brown wrote:
> 
>> In the case of the Freescale bdm gdb drivers (they're the ones I know 
>> in most detail), the gdb library (almost) directly accesses the 
>> parallel port.  Off hand, I can't remember if it uses in/out 
>> instructions itself in the latest versions, or goes through ioctl 
>> calls, but it processes every bit individually.  For the bdm, every 
>> transaction is 17 bits, with synchronous writing and reading - that 
>> does not match any general purpose parallel port protocol.  For jtag 
>> connections, you want continuous streams of synchronous bits.  In each 
>> case, you need to set the clock bit, set the data out bit, toggle the 
>> clock bit, read the data in bit, rinse and repeat.  You can't do that 
>> over an Ethernet line in a sensible time frame - the latency is too high.
> 
> Don't know much about bdm, though have used cig packet style adapters 
> for development. 17 bits sounds a bi odd ball, though one could 
> serialise/deserialise in a bit of added hardware to allow connection to 
> a parallel data source. I do see what you mean about ethernet though. 
> Effectively, each clocked bit would require 2 ethernet frames, plus the 
> transition time through the stack at each end, for each frame. As you 
> say, it's probably not viable in throughput terms. Perhaps another 
> appoach might be to add a little hardware, or even a low cost micro to 
> convert serial rs232 or parallel port format to jtag. Does start to get 
> a bit convoluted though and if you do that, you may just as well include 
> the gdb remote server code in the adapter as well.
> 

That's exactly what is done.  If you look at the BDI 2000, for example, 
it can communicate over a LAN in "gdb", and handles the details locally. 
  As an example, consider reading a 32-bit value from memory on a 
ColdFire.  That takes five 17-bit bdm frames.  Each bit takes four 
operations (clock toggle, data out, clock toggle, data in) - you'd be 
talking about 340 Ethernet packets, not including acknowledgements.  In 
reality, you'd be lucky if your download speed were measured in bytes 
per second rather than seconds per byte.  With the gdb protocol, you'd 
send a single "read" command, and get a single data value back.

> Food for thought though and will try to find a way. Network based debug 
> would provide ultimate flexibility in terms of choice of development 
> hardware, os etc...
> 

Absolutely.  The easy way to do this for a one-off is to dedicate a 
small PC as your gdb server.  I've done debugging from my home machine, 
with gdb running there connected to a proxy on my office machine 
connected to the target.

> Chris