EmbeddedRelated.com
Forums

GDB or Insight across ethernet

Started by ChrisQuayle February 11, 2007
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
ChrisQuayle <nospam@devnul.co.uk> writes:

> 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...
Nice idea if it works. I would not have thought that the printservers would allow the fine degree of control of the port pins likely to be used by the wiggler. But I have no direct knowledge of this. The BDI2000 product, for example, is an ethernet connected jtag interface which does what you want out of the box. It is expensive. If you have an old laptop or something, you could use the freely downloadable McCraigor (sp?) software to run the wiggler or raven compatible. This would then appear on the network and can be connected to via gdb from any other machine. -- John Devereux
On Feb 11, 7:36 am, ChrisQuayle <nos...@devnul.co.uk> wrote:

> this setup ?. The hp printservers generally use port 9001 or similar and
The print servers are exactly that, though - print servers, no? They don't let you bit-bang the remote end with virtual I/O ports, which is what you'd need to do to get them supported transparently by existing debugger software on the PC side. I do not think you can do this project in exactly the manner you're describing, because of timing issues if nothing else; I think you will need to have custom firmware running on the "print server" end, implementing the JTAG scan on the parallel side and remote Ethernet debugging protocol on the Ethernet side. At this point there is no reason to use a print server and parallel JTAG dongle for the job - you might as well just wire a JTAG header direct to the pins of the micro. All that is inside the cheapo parallel JTAG bit-bangers is a little level shifting/buffering/isolation. Standalone "JTAG on one end, Ethernet on the other" debuggers do exist, e.g. from Macraigor.
ChrisQuayle wrote:

> to use a cheap s/hand hp printserver (Parallel + rj45 network) to > provide the bridge between the net and jtag wiggler.
Not likely to work --- these things only serve printer service protocols like SMB or LPD, not some generic "port pin via ethernet" protocol. The cheap ones wouldn't do management protocols either. > Don't want to go
> the embedded linux route, as the target hardware won't have networking > or other resources to support it.
Why embed Linux on the target hardware? Embed it on a cheap used PC with a parallel port that you can put close to the target system, and you're all set.
John Devereux wrote:
> ChrisQuayle <nospam@devnul.co.uk> writes: > > >>Am trying to get a environment going to allow development on > 1 >>networked hosts,
<snip> plan to use a cheap s/hand hp printserver (Parallel + rj45
>>network) to provide the bridge between the net and jtag wiggler.
I do this sort of thing all the time both on serial and parallel port terminal servers, my i8096 ICE demo is doing right now at: http://www.cybertheque.org/homebrew/hmi-200 You can telnet to the JetDirect boxes at 9001 using a raw protocol and I have written handlers that do this so this idea ought to work for you. Regards, Michael
larwe wrote:
> On Feb 11, 7:36 am, ChrisQuayle <nos...@devnul.co.uk> wrote: > > >>this setup ?. The hp printservers generally use port 9001 or similar and > > > The print servers are exactly that, though - print servers, no? They > don't let you bit-bang the remote end with virtual I/O ports, which is > what you'd need to do to get them supported transparently by existing > debugger software on the PC side. >
Depends on the terminal server (print server); some have ioctls to permit low-level control of certain lines and bit-banging the data lines is easy enough. Regards, Michael
msg wrote:
> John Devereux wrote: > >> ChrisQuayle <nospam@devnul.co.uk> writes: >> >> >>> Am trying to get a environment going to allow development on > 1 >>> networked hosts, > > > <snip> > > plan to use a cheap s/hand hp printserver (Parallel + rj45 > >>> network) to provide the bridge between the net and jtag wiggler. > > > I do this sort of thing all the time both on serial and parallel
Are there any good web site that explain how to do this. Or do I need years of playing with all the open source GDB and Linux sources before a mere mortal(*) can understand how to do this. donald (*) Mere mortal is a WINxxx user.
> port terminal servers, my i8096 ICE demo is doing right now > at: > > http://www.cybertheque.org/homebrew/hmi-200 > > You can telnet to the JetDirect boxes at 9001 using a raw > protocol and I have written handlers that do this so this idea > ought to work for you. > > Regards, > > Michael
msg wrote:
> larwe wrote: > >> On Feb 11, 7:36 am, ChrisQuayle <nos...@devnul.co.uk> wrote: >> >> >>> this setup ?. The hp printservers generally use port 9001 or similar and >> >> >> >> The print servers are exactly that, though - print servers, no? They >> don't let you bit-bang the remote end with virtual I/O ports, which is >> what you'd need to do to get them supported transparently by existing >> debugger software on the PC side. >> > > Depends on the terminal server (print server); some have ioctls to > permit low-level control of certain lines and bit-banging the data > lines is easy enough. > > Regards, > > Michael
Thanks for all the replies, particularly the one about using an old laptop. Run a very stripped down linux or similar ?. Still like the idea of jetdirect though. Have a couple around the lab here doing nothing and they need a raw / transparent mode for postscript, so it should be possible. A bit of test code, a few sessions with tcpdump and will report back with results... Chris
ChrisQuayle <nospam@devnul.co.uk> writes:

> msg wrote: >> larwe wrote: >> >>> On Feb 11, 7:36 am, ChrisQuayle <nos...@devnul.co.uk> wrote: >>> >>> >>>> this setup ?. The hp printservers generally use port 9001 or similar and >>> >>> >>> >>> The print servers are exactly that, though - print servers, no? They >>> don't let you bit-bang the remote end with virtual I/O ports, which is >>> what you'd need to do to get them supported transparently by existing >>> debugger software on the PC side. >>> >> >> Depends on the terminal server (print server); some have ioctls to >> permit low-level control of certain lines and bit-banging the data >> lines is easy enough. >> >> Regards, >> >> Michael > > Thanks for all the replies, particularly the one about using an old > laptop. Run a very stripped down linux or similar ?.
That was me I think... I was referring to the software here <http://www.macraigor.com/full_gnu.htm> 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). There may well be open source equivalents now, not sure of the current state of the art here cause I now have the Abatron BDI2000 which has it all built in.
> Still like the idea of jetdirect though. Have a couple around the > lab here doing nothing and they need a raw / transparent mode for > postscript, so it should be possible.
Another idea would be to use one of the tiny linux distributions that can run on "hacked" routers/printservers, and an open source jtag "server" if such exists. You would basically have an equivalent to the Abatron at 1/10 the price. Not a job for the faint-hearted though! -- John Devereux
ChrisQuayle 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
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.