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

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

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

ChrisQuayle wrote:
> David Brown wrote:
> 
>>
>> Forget printerserver devices - they are made for printers.  Even if 
>> you can bit-bang with them, they will be far too slow in this mode.
>>
>> For many embedded gdb setups, gdb talks to a proxy which handles the 
>> low-level communication with the device.  Sometimes this is done for 
>> the convenience of development (developing debugging the two parts 
>> separately), and sometimes it is done for licensing reasons (e.g., a 
>> closed source debugging stub talking to open source gdb).  In almost 
>> all cases, these two parts can run on different computers.  In this 
>> case, you would run the low-level proxy on a small machine (probably 
>> linux), and talk to it over a tcp/ip port.  For some other gdb types, 
>> there is a separate gdbserver program that can serve the same function 
>> as the stub.
> 
> Not convinced that it would be too slow. Haven't looked at gdb sources 
> or config yet, so you can correct me if i'm wrong, but I think it uses 
> config files or a slip layer to suit the different types of hardware 
> that it talks to, as well as the network. I doubt if gdb directly bit 
> bangs the parallel port for the jtag implementation, but probably works 
> (linux / unix) thorugh a device open(), write() read() etc system call 
> and then has a slip layer to convert the gdb data into a form suitable 
> for the interface that it's talking to. If the jetdirect is in raw 
> unbuffered mode, it's should essentially be a parallel port on the net, 
> so it should be possible to coerce gdb to talk to it. That is,it just 
> copies the data, with no translation.
> 
> Chris

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.

The way to do such remote debugging is to implement a higher level 
protocol, so that the gdb can send a command to read a block of memory 
over the network, and the gdb server interprets the command, handles the 
low-level bit toggling, and returns the result.

There are regular questions about using usb-to-parallel port converters 
in the comp.arch.fpga newsgroup - they don't work (at a realistic speed) 
for the same reasons.

 You can only write software on the target ,
 else you will need to waste time debugging.

  There are no bugs , if you create a
 perfect structure , starting with the ARM
 loader in all low cost mcu's .

    But it seems there must be some incentives
 to do otherwise .
  It is great self esteem , to create a perfect
 system .  First you blend the debugger into
 the loader , so if something changes a
 little , you simply select from a menu ,
 then it boots correctly on the new target ,
  no need to go back to C/C++ src code !
   But for all those struggling Linus's !!
  trying to make bloat , wizardly Unix copies.

  I want a truely "Universal" serial bus ,
  so ill use a USB cable and connectors ,
  but make the "protocol" work in all ways
  low to high !
   First i will bypass the xmit/rcv signals
  directly to a slow circuit , and the protocol
  will look on many GPIO pins for a square
  wave . You simply modulate that square wave
  you are feeding into that pin and the
  s/w can sync to it .
    Old method , was to crash as an excuse .
   Any one with a simple 74HC4538 osc'
  can use 1 , 2 , 4 or 8 lines to talk
  to the cpu , and it does not matter which
  pins you talk thru !
    If loader/booter does not scan any signals
  it scans the normal stuff , like Ethernet
 or proper USB or RS232 or ....
    Notice my protocol is NRZ , and if
 you try to go fast , the kernel will switch
 to RLL , auto-detect !
   Simple , if it sees a symetrical square wave ,
  it assumes no RLL , if it sees big drop outs
  it assumes very slow rates ,
  all auto-detecting .

   Now thats truely  Universal serial !

  BTW , im buying pocket computers ,
  got 10 GameBoxes ( NDS Lites) and
  some   ARM7  EVB's .
     www.armkits.com  was a bad idea !
    aka Embest.com .  Solder shorts across
  the pins on the '2000-B !
   Not one shiny solder connection , all
  crap , and solder flux everywhere .
   I will never do business with Embest
   of China .

     www.sparkfun.com is also
    on my disapproved venders list .



   www.microcontrollershop.com
   is OK , they resell stuff from many
   venders .

   WiFi , LinkSys WRT54G has been
  hacked .
   " DD-WRT"   ver 23 will tame
 my WiFi routers and make them
  work better on these tiny pocket
  ARM's
    To make computers work well ,
  you must tame the h/w from the
 lowest levels .

-------------------------------------------------





> OpenOCD provides this functionality as open source, for Arm targets.
>
> Eric

msg wrote:

> There's a lot you can do with the jetdirects, albeit slowly, in raw
> mode and if you're ambitious, understanding the firmware (68k) could
> permit customization :-)

That suggests that you've done some of this already - please tell. I 
guess the first thing is to get info on the remote command set, but 
google was not particularly helpfull. Have just downloaded a copy of the 
hp print system for linux though, which should have loads of usefull 
info. Reverse engineering the firmware would be a non starter - have 
neither the time nor the required sense of challenge to deal with that.

It's got to be simple to work. For proof of concept, stuff like socket 
pair open to the jetdirect, with test data transfer would verify (or 
not) transparency of data and any wrinkles...

Chris

Jim wrote:
> On Feb 11, 6:36 am, ChrisQuayle <nos...@devnul.co.uk> wrote:
> 
>>Am trying to get a environment going to allow development on > 1
>>networked hosts, perhaps unix, win2k, or even linux, with networked
>>target hardware. Am late to the arm party, but am considering several
>>arm variants, as well as coldfire. The arm targets all seem to be jtag,
>>with wiggler interface to parallel port and to get this networked, plan
>>to use a cheap s/hand hp printserver (Parallel + rj45 network) to
>>provide the bridge between the net and jtag wiggler. Don't want to go
>>the embedded linux route, as the target hardware won't have networking
>>or other resources to support it. I also don't necessarily want any
>>monitor software on the target. The hardware may be minimal and jtag
>>will be fine.
>>
>>Question is, has this or something similar been done already and if so,
>>where ?. Also, how easy would it be to modify the gdb sources to suit
>>this setup ?. The hp printservers generally use port 9001 or similar and
>>they are bidirectional, so should ideal for the task and are very low
>>cost s/hand. Overall, am trying to get an development environment
>>together to last at least 3-5 years, so am prepared to spend some time
>>getting it right...
>>
>>Chris
> 
> 
> Chris,
> 
> Netburner has an Insight based debugging capability over Ethernet.  I
> used it with their Coldfire 5272 based product around a year ago.  It
> worked well.
> 
> Jim
> 

Thanks, but it does mean spending cash, which of course is always in 
short supply :-)...

Chris

David Brown wrote:

> 
> Forget printerserver devices - they are made for printers.  Even if you 
> can bit-bang with them, they will be far too slow in this mode.
> 
> For many embedded gdb setups, gdb talks to a proxy which handles the 
> low-level communication with the device.  Sometimes this is done for the 
> convenience of development (developing debugging the two parts 
> separately), and sometimes it is done for licensing reasons (e.g., a 
> closed source debugging stub talking to open source gdb).  In almost all 
> cases, these two parts can run on different computers.  In this case, 
> you would run the low-level proxy on a small machine (probably linux), 
> and talk to it over a tcp/ip port.  For some other gdb types, there is a 
> separate gdbserver program that can serve the same function as the stub.

Not convinced that it would be too slow. Haven't looked at gdb sources 
or config yet, so you can correct me if i'm wrong, but I think it uses 
config files or a slip layer to suit the different types of hardware 
that it talks to, as well as the network. I doubt if gdb directly bit 
bangs the parallel port for the jtag implementation, but probably works 
(linux / unix) thorugh a device open(), write() read() etc system call 
and then has a slip layer to convert the gdb data into a form suitable 
for the interface that it's talking to. If the jetdirect is in raw 
unbuffered mode, it's should essentially be a parallel port on the net, 
so it should be possible to coerce gdb to talk to it. That is,it just 
copies the data, with no translation.

Chris

> The OCDRemote program runs on linux or windows, turning the machine it
> is running on into a sort of jtag  "server" that gdb can connect to
> via the network (or locally too of course).

OpenOCD provides this functionality as open source, for Arm targets.

Eric

On Feb 11, 6:36 am, ChrisQuayle <nos...@devnul.co.uk> wrote:
> Am trying to get a environment going to allow development on > 1
> networked hosts, perhaps unix, win2k, or even linux, with networked
> target hardware. Am late to the arm party, but am considering several
> arm variants, as well as coldfire. The arm targets all seem to be jtag,
> with wiggler interface to parallel port and to get this networked, plan
> to use a cheap s/hand hp printserver (Parallel + rj45 network) to
> provide the bridge between the net and jtag wiggler. Don't want to go
> the embedded linux route, as the target hardware won't have networking
> or other resources to support it. I also don't necessarily want any
> monitor software on the target. The hardware may be minimal and jtag
> will be fine.
>
> Question is, has this or something similar been done already and if so,
> where ?. Also, how easy would it be to modify the gdb sources to suit
> this setup ?. The hp printservers generally use port 9001 or similar and
> they are bidirectional, so should ideal for the task and are very low
> cost s/hand. Overall, am trying to get an development environment
> together to last at least 3-5 years, so am prepared to spend some time
> getting it right...
>
> Chris

Chris,

Netburner has an Insight based debugging capability over Ethernet.  I
used it with their Coldfire 5272 based product around a year ago.  It
worked well.

Jim