Zach Welch wrote: > On Wed, 2009-04-22 at 19:52 +0200, Øyvind Harboe wrote: > >> One annoying problem is that all target hardware is >> not available to all OpenOCD developers. >> >> For development purposes, this could perhaps be >> addressed by creating a JTAG over TCP/IP protocol. >> >> The idea is that OpenOCD adds a TCP/IP server >> that accepts JTAG commands. >> >> Those with target hardware can then make this hardware >> available over the internet. >> >> On the other end an OpenOCD developer uses the >> new "tcipip interface" to connect to the target hardware. >> >> This will of course be dog slow, but it hopefully will beat >> not having the hardware available.... >> >> There is a non-trivial amount of programming that needs >> to be done, but I believe setting up and maintaining the >> test farm would be a bigger problem. Zylin is interested >> in stepping up here and offering the physical space >> / servers required. >> >> I'd expect to make these targets avaiable via SSH & port >> forwarding to OpenOCD developers... >> >> Thoughts? >> > > I love it. Positively love it. > > I have a strong networking background, so I could whip up an example > some free afternoon. I do not see why it would be slow. Even 10Mbit/s > easily gives 50kB/s+ over the wire, and I bet many of us are running at > least 100Mbit/s. I think the JTAG interface will remain the bottleneck > if this runs on a local network. Incidentally, I seem to recall reading > about an official IEEE JTAG-over-ethernet protocol somewhere. > > Of course, you say that you want to do this for remote development over > the internet. Ummm.... I have to reach over and physically reset my > target or JTAG interface on occasion. I love the enthusiasm, but there > are some limits to the power of remote software control. Or do you have > a remote telepresence solution on hand that you failed to mention? > > More practically, this would allow companies to use dumb programmer PCs > on the factory floor that are controlled by a (distantly) remote > station; much easier to secure the proprietary sources from industrial > espionage. That begs me to ask: does anyone here worry about this type > of issue? If you do, would you even be able to tell us about it? ;) > > Nevertheless, this idea allows me to introduce the full potential that > you have just presented to the OpenOCD project: > > Given the cost of a netbook plus USB JTAG dongle, wouldn't these > features undercut the price of ethernet-based JTAG programmer/debuggers > out on the market today? Why not just use this proposed TCP/IP JTAG > layer between a PC and commodity part devices? > > If my reading of this is correct, you are interested in offering your > resources to an endeavor that might cannibalize your sales. Whoops. > Talk about looking the gift horse in the mouth. But if you are still > interested, I think it's a great idea and worth pursuing. It has made > it on The List, and it's not going away without a pay-off. ;) Kidding! >
What he said, but LOUDER. > Rick's points about clean-up and testing do apply, though. I would not > want to start that without a lot of additional low-level grunt work. > No, these are not mutually exclusive or sequentially dependent tasks, so I disagree with the idea that something needs to be done first. The idea of serializing the entire "cable API" into a byte oriented command/reply sequence has some interesting spin off possibilities: 1) The implication of this is that anything can be sent to ANY supported JTAG cable can also be sent over the TCP/IP wire. And once this becomes, true, I would argue that we *could* simply use the same marshalling support as our cable API at some point. The entire cable API becomes something like this *one* function: ERRCODE transact( u8* command, int commandLen, u8* reply, int* replyLen ) 2) The client program no longer needs to be OpenOCD on the other end. Then I could finally put some python code on top of a cable driver for real scripting, not this watered down tcl crap. 3) If you don't like a separate process for your scripting, and don't like tcl, (me stepping forward) you could grab any cable driver and SWIG python right on top of it, in process, by defining only *one* function as the entire language bridge API, plus some hand written marshalling/de-marshalling support. This would be after the cable driver API went to transact(). If I recall the BDM2000 folks have an API that consists of about exactly one function. It wreaks of ioctl() but there is little that is more standard than a sequence of bytes. Dick _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
