GDB or Insight across ethernet

ChrisQuayle wrote:
> msg wrote:
> 
>>
>> 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.
>>

> 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...
> 

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 !

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

> 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

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

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

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

 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

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.

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