GDB or Insight across ethernet

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

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.

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.

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.

plan to use a cheap s/hand hp printserver (Parallel + rj45

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:

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

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

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.

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

That was me I think...

I was referring to the software here

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.

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

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.

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 :-)

If you can work with Annex terminal servers, I have code that can help.

Regards,

Michael

Productive humans are quick to take up

new methods . Dump the stupid protocol .

I am fast obsoleting the PC . Soon i will

be able to do everything , computer ,

w/o any of the software you are struggling with .

And from the most unlikely sources !

ARM will destroy Intel Corp . Pentiums

will die a fast death , along with all the

h/w it runs on .

I have 10 Ninetendo DS lites .

Software will be written to upgrade them into

super computers .

? They can't do it yet ?

There is nothing to stop them !

The govt has lost control over h/w , it

is easy to get , for the world wide competition

to produce pocket ARM's .

Long ago , Intel was king , for the

For' trade taxes / laws .

No CPU was made outside the USA !

Now , all competitive CPU's are made

outside USA .

As soon as ATMEL tries to up the anty ,

Samsung either takes it up , or shows

ATMEL , it was not a real consumer demand !

All because there are no laws to stop the

competition !

Samsung and ST and Philips dont have to

cut back , on USA trade laws !! ------------------

We proved we could do powerful computing withW95 in 8 megaByte .

So why are we closing the door on Game boxes that have 8MB of SRAM , and GUI and WiFi ?

Another arguement , is the hackers haven't done it yet . This is because you see and hear them hacking the game boxes , because they are gamers . I have been flamed black , by these "insecure" hackers , because im hacking the whole game box , not just games .

I will trash the NDS OpSys , they are trying to SAVE !! I dont like games .

I will trash it and burn a MPE Forth and start the evolution of the ....

2nd generation PDA . ------ 60 GB HDD 1.8" , WiFi SD card slots *4

It will trash all the old BIOS drivers , like ATA HDD and FAT16/32 on SD cards !!

It will have "Thought" transfer , using a true GUI keyboard . Each softkey can send a Thought . Each thought can be understood by all computers and all humans .

Anyone defining a new thought , that is not "thoughtful" , will be widely ignored , their thought , will make that person notorious. Because we are all "connected" by computers today , a good thougt will travel fast .

But the owners of the WWW are clsing doors on us . They dont want us to create a better method , so they try to lock us into ASCII text . But we can simply use some ASCII temporarily. in the interim , to evolve communication .

I am the worlds fastest systems programmer . I am using some ASCII to mean more general and less ambigous thoughts .

I use # to mean anything structured . A line Editor is unstructured , or at least forced bad structure , so i write

Line editor # bad . C/C++ # bad M$ # unproductive .

Forth HLL # powerful .

There can be no arguement . You can not arbitrarily restrict my definition , because it would make it less value .

If you say # is both for Structure and for the common use "number" , then you confuse , and confusion is non-productive .

Thus the objective is to be productive thru unambigous characters , that suffixed , can create powerful ideas .

It is a very exciting form of compression , because once context is established , you can nix many helper words , we often use in English . I can reserve many binary words in my computer to represent strings of these new char's and send only 16 bits and it will display as 1177 English text chars , all perfectly unambigous and precise !

My 16 bits is translated to the 2nd level , then translated to English .

Since the direction is from 1) precise to 2) pricise to 3) less precise ( Text)

It has NO errors !

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

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

Eric

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

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

Chris

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

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 .

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 .

is also on my disapproved venders list .

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 .

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

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.

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