Reply by Jonathan Kirwan August 20, 20072007-08-20
On Mon, 20 Aug 2007 12:04:18 +0200, Dominic
<Dominic.at.usenet@gmx.com> wrote:

>Jonathan Kirwan wrote: >> I'd still like >> to see some examples that are (1) USB based, (2) support RTCK, (3) are >> well documented for those wishing to write their own software to >> access the full features of the hardware/firmware included, and (4) >> have unfettered gdb servers available for them in source form so that >> they can be compiled on various environments and modified, as needed. > >When I first looked into this topic around 2004 I spend quite some time >searching for open source alternatives to software like macraigor's >ocdremote/ocdcommander and high-end tools like the BDI2000. There were a >few projects but none of them was in a useable state and they're all >unmaintained by now, which is why I started my own project which ended up >being released under the GPL as the OpenOCD. >The OpenOCD may not be perfect for everyone's taste, but it's probably the >best free (as in speech, just so we don't get that argument again...) >solution you can get at this time. >With this as my background I'll comment on your requests: > >(1): There are three USB based JTAG interfaces supported by the OpenOCD >available: >- FT2232 based designs (some readymade devices from commercial vendors, some >free designs that can be built for little money) >- usbprog (http://www.embedded-projects.net/index.php?page_id=165) >- ASIX PRESTO >All of those can be used on any of the supported platforms which include 32 >and 64 bit Windows, Linux, *BSD and Mac OS-X, as long as either >libusb/libftdi or FTDI's binary FTD2XX library is available. > >(2): RTCK isn't supported by any of the designs currently available, but I >don't think this is much of a problem. Just make sure that the JTAG adapter >is set to run at less than 1/6th of the core frequency. You can later >increase the JTAG frequency again after code running on your target enabled >and selected the PLL. >If you think that support for RTCK is really necessary then it wouldn't be >hard to design a USB interface that supports RTCK yourself. > >(3): The FT2232 based designs and the usbprog meet this requirement. A >commercial vendor is hardly going to open up their device's specifications >because that makes it easy to copy the design. There is only limited >complexity in the JTAG interfaces themself, and vendors don't want >counterfeit hardware to be used with their software packages. This became a >problem for Macraigor with their Wiggler, and only a few weeks back someone >posted schematics and firmware for a Keil ULink to the yahoo lpc2000 group. >One exception is isystem's (Boudewijn Dijkstra just reminded me of them with >his post) iF-DEV package, for which they even provide all documents >necessary to build your own, but this comes with some strings attached >(e.g. only non-commercial use). I have to admit that I didn't look too >closely at their offering though, so you'd have to evaluate yourself if >this suits your needs. > >(4): Most/all of the logic required for ARM debugging would have to be part >of that GDB server, because GDB itself isn't concerned with anything >beyond "halt/resume target", "read/write registers" or "read/write memory". >A vendor of non-free software certainly isn't going to open up all that >knowledge to potential competitors. >ARM debugging is documented in the various ARM TRM's, the XScale manuals, >and various bits and pieces around the internet. The tricky part is >probably those bits that are missing, but it's possible to work all these >things out yourself. >The only commercial player in this field that could have an interest in free >debug tools for ARM cores is ARM itself, but they sell both their own >RealView stuff and they own Keil, so it's quite unlikely to expect them to >come up with free software to compete with their own hard- and software. >Chip vendors would have to create software that could be used with their >competitors products as well, so this isn't going to happen either. >A vendor of JTAG debug tools would a) open up his knowledge to competitors >and would b) risk the money he's making from hardware sales, once someone >adds support for other hardware or if someone starts selling counterfeits >of his hardware. > >My point is that the situation isn't going to change because of what one >vendor does, as they have little/no reason to release their stuff to the >public. If you want free tools you'll have to develop them yourself. The >OpenOCD is there as a starting point, but of course you're free to start >over again if you don't like the approach I've taken. Additional JTAG >interfaces can be added quite easily to the OpenOCD, and a solution >consisting of a USB chip + CPLD/small FPGA that includes RTCK support etc. >wouldn't be hard to build. > >Best regards, > >Dominic Rath
Thanks very much, Dominic, for your comments. If nothing else at all occurs here on the topic, this alone makes the recent discussion worth every second it took. I've learned some things and very much enjoyed your perspective. Sincere thanks, Jon
Reply by David Brown August 20, 20072007-08-20
Chris Hills wrote:
> In article <46c962b8$0$3217$8404b019@news.wineasy.se>, David Brown > <david@westcontrol.removethisbit.com> writes >> Boudewijn Dijkstra wrote: >>> Op Sat, 18 Aug 2007 22:09:02 +0200 schreef Jonathan Kirwan >>> <jkirwan@easystreet.com>: >>>> Name a few that are (1) USB based, (2) support RTCK, (3) are well >>>> documented for those wishing to write their own software to access the >>>> full features of the hardware/firmware included, and (4) have >>>> unfettered gdb servers available for them in source form so that they >>>> can be compiled on various environments and modified, as needed. >>> I know one tool vendor that comes very close to your requirements: >>> iSYSTEM. They make several ARM emulators in the range from tens to >>> thousands of euros, and a free (of charge) Windows IDE. Your >>> requirements: >>> 1. Yes. (Also Ethernet.) >>> 2. Yes. (Also scan chain options, idle TCK's and a different speed >>> during init.) >>> 3. Yes. (But Windows API's only.) >>> 4. Not quite. But a GDB server is supported as a plug-in DLL, and >>> with the Windows API you could write your own GDB server. >>> >> >> Abatron (www.abatron.ch) make debugger tools for a variety of >> different devices, and with support for a variety of different >> debuggers. gbd (on Windows or Linux - I don't know about FreeBSD) has >> always been one of their host options. They are not the cheapest >> devices out there, but I've heard nothing but good things about them >> from others (I haven't tried them myself). > > Abatron are very good. (No, I don't sell them :-) However they are > close to the 1000 GBP/1500 EURO/ 2000 USD mark. > > If the OP thinks the Segger SW and Jlink at a third of the price is very > expensive and over priced what will he make of a system that is three > times the cost? Even if it is very good. This is why I did not mention > the Abatron (or any of the other higher end tools.) >
Maybe he'll feel they are worth the price after more investigation (I have no idea of his budgets or requirements). Anyway, this is a public newsgroup - maybe others reading this thread now or in the future (a few people search the archives before posting :-) will appreciate the pointer. So if you have any other similar ideas, feel free to post them too - if nothing else, it will give budget-constrained developers something to dream about :-)
Reply by Dominic August 20, 20072007-08-20
Hans-Bernhard Br&#4294967295;ker wrote:
>> And the license for a library can introduce exceptions to the GPL: >> http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface > > Any author can introduce whatever exceptions to whatever license he > likes. So what has that to do with anything?
The GPL explicitly regulates these exceptions, and specifically states that you may remove those exceptions again when distributing software licensed under the terms of the GPL. This is the case both with additional permissions (e.g. some RTOS granting you the right to distribute the RTOS + your application code without having to open up your application) and additional restrictions (whatever restriction you could come up with). If you don't want to grant this right to your licensees you may choose a modified license, but you wouldn't be able to call it the GNU GPL. Regards, Dominic
Reply by August 20, 20072007-08-20
Frank Peelo wrote:
> Hans-Bernhard Br&#4294967295;ker wrote: >> Chris Hills wrote:
>>> Does this mean that if you link in a GPL library then you have to >>> release the source of the application?
>> Yes.
> But only if the library is licensed under GPL.
What do you mean by "But only"? We were talking about a GPL library.
> And the license for a library can introduce exceptions to the GPL: > http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface
Any author can introduce whatever exceptions to whatever license he likes. So what has that to do with anything?
Reply by Chris Hills August 20, 20072007-08-20
In article <46c962b8$0$3217$8404b019@news.wineasy.se>, David Brown 
<david@westcontrol.removethisbit.com> writes
>Boudewijn Dijkstra wrote: >> Op Sat, 18 Aug 2007 22:09:02 +0200 schreef Jonathan Kirwan >><jkirwan@easystreet.com>: >>> Name a few that are (1) USB based, (2) support RTCK, (3) are well >>> documented for those wishing to write their own software to access the >>> full features of the hardware/firmware included, and (4) have >>> unfettered gdb servers available for them in source form so that they >>> can be compiled on various environments and modified, as needed. >> I know one tool vendor that comes very close to your requirements: >>iSYSTEM. They make several ARM emulators in the range from tens to >>thousands of euros, and a free (of charge) Windows IDE. Your >>requirements: >> 1. Yes. (Also Ethernet.) >> 2. Yes. (Also scan chain options, idle TCK's and a different speed >>during init.) >> 3. Yes. (But Windows API's only.) >> 4. Not quite. But a GDB server is supported as a plug-in DLL, and >>with the Windows API you could write your own GDB server. >> > >Abatron (www.abatron.ch) make debugger tools for a variety of different >devices, and with support for a variety of different debuggers. gbd >(on Windows or Linux - I don't know about FreeBSD) has always been one >of their host options. They are not the cheapest devices out there, >but I've heard nothing but good things about them from others (I >haven't tried them myself).
Abatron are very good. (No, I don't sell them :-) However they are close to the 1000 GBP/1500 EURO/ 2000 USD mark. If the OP thinks the Segger SW and Jlink at a third of the price is very expensive and over priced what will he make of a system that is three times the cost? Even if it is very good. This is why I did not mention the Abatron (or any of the other higher end tools.) -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by David Brown August 20, 20072007-08-20
Boudewijn Dijkstra wrote:
> Op Sat, 18 Aug 2007 22:09:02 +0200 schreef Jonathan Kirwan > <jkirwan@easystreet.com>: >> Name a few that are (1) USB based, (2) support RTCK, (3) are well >> documented for those wishing to write their own software to access the >> full features of the hardware/firmware included, and (4) have >> unfettered gdb servers available for them in source form so that they >> can be compiled on various environments and modified, as needed. > > I know one tool vendor that comes very close to your requirements: > iSYSTEM. They make several ARM emulators in the range from tens to > thousands of euros, and a free (of charge) Windows IDE. Your requirements: > 1. Yes. (Also Ethernet.) > 2. Yes. (Also scan chain options, idle TCK's and a different speed > during init.) > 3. Yes. (But Windows API's only.) > 4. Not quite. But a GDB server is supported as a plug-in DLL, and with > the Windows API you could write your own GDB server. >
Abatron (www.abatron.ch) make debugger tools for a variety of different devices, and with support for a variety of different debuggers. gbd (on Windows or Linux - I don't know about FreeBSD) has always been one of their host options. They are not the cheapest devices out there, but I've heard nothing but good things about them from others (I haven't tried them myself). mvh., David
Reply by David Brown August 20, 20072007-08-20
Paul Curtis wrote:
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message > news:46c94423$0$3192$8404b019@news.wineasy.se... >> John Devereux wrote: > > < snip > > >> It is quite possible, however, for vendors to release GPL'ed versions of >> the libraries (or RTOS, or other code) precisely so that it cannot be used >> for closed source development, while also releasing the same libraries >> under a different license (at a cost) that allows your code to use any >> license. A good example of this is the QT libraries from TrollTech. I >> have no idea whether the same thing applies to Rowley's "hobby" version of >> their ARM compiler - it would certainly be a perfectly good business model >> to do so, and in keeping with the goals of open source and of a commercial >> business. > > I have no problem with customers developing source code with CrossWorks for > their own use and to share with other hobbyists using a Personal License. > MakingThings and the Make Controller is a good example, I think--they > develop their code in CrossWorks and provide it to their customers who can > use CrossWorks or plain GNU tools to rebuild the application. > > The only items that cannot be redistributed are source code and object files > we ship as part of CrossWorks and our Board Support Package sources. These > sources are clearly marked with copyright noticies. > > I must admit that I have not considered a dual license for our source code. >
Am I correct in thinking that the code (for the libraries and the BSPs) is under a single license that says something like "You can use these as you want, but you can't distribute the source or object code unless you purchase a professional license"? Offering the same code under a GPL license as an alternative would let people distribute complete applications, as long as they are entirely GPL'ed. You won't lose many professional customers, as most want to keep their own application source closed, but it would make it easier for the hobby and academic markets which are less concerned about keeping code secret. That may or may not be of interest to you - it's just an idea to consider. There is, of course, a type of professional usage for which there is no problem using the GPL in the target code - the GPL only requires you to make your source code available if you distribute the binaries. If you are using the GPL'ed code entirely within an organisation, then the binaries are never distributed externally, and thus there is no need to give the source code to anyone. I have no idea whether this usage represents enough potentially lost professional license customers for it to be of concern when considering dual licenses. mvh., David
Reply by Dominic August 20, 20072007-08-20
Jonathan Kirwan wrote:
> I'd still like > to see some examples that are (1) USB based, (2) support RTCK, (3) are > well documented for those wishing to write their own software to > access the full features of the hardware/firmware included, and (4) > have unfettered gdb servers available for them in source form so that > they can be compiled on various environments and modified, as needed.
When I first looked into this topic around 2004 I spend quite some time searching for open source alternatives to software like macraigor's ocdremote/ocdcommander and high-end tools like the BDI2000. There were a few projects but none of them was in a useable state and they're all unmaintained by now, which is why I started my own project which ended up being released under the GPL as the OpenOCD. The OpenOCD may not be perfect for everyone's taste, but it's probably the best free (as in speech, just so we don't get that argument again...) solution you can get at this time. With this as my background I'll comment on your requests: (1): There are three USB based JTAG interfaces supported by the OpenOCD available: - FT2232 based designs (some readymade devices from commercial vendors, some free designs that can be built for little money) - usbprog (http://www.embedded-projects.net/index.php?page_id=165) - ASIX PRESTO All of those can be used on any of the supported platforms which include 32 and 64 bit Windows, Linux, *BSD and Mac OS-X, as long as either libusb/libftdi or FTDI's binary FTD2XX library is available. (2): RTCK isn't supported by any of the designs currently available, but I don't think this is much of a problem. Just make sure that the JTAG adapter is set to run at less than 1/6th of the core frequency. You can later increase the JTAG frequency again after code running on your target enabled and selected the PLL. If you think that support for RTCK is really necessary then it wouldn't be hard to design a USB interface that supports RTCK yourself. (3): The FT2232 based designs and the usbprog meet this requirement. A commercial vendor is hardly going to open up their device's specifications because that makes it easy to copy the design. There is only limited complexity in the JTAG interfaces themself, and vendors don't want counterfeit hardware to be used with their software packages. This became a problem for Macraigor with their Wiggler, and only a few weeks back someone posted schematics and firmware for a Keil ULink to the yahoo lpc2000 group. One exception is isystem's (Boudewijn Dijkstra just reminded me of them with his post) iF-DEV package, for which they even provide all documents necessary to build your own, but this comes with some strings attached (e.g. only non-commercial use). I have to admit that I didn't look too closely at their offering though, so you'd have to evaluate yourself if this suits your needs. (4): Most/all of the logic required for ARM debugging would have to be part of that GDB server, because GDB itself isn't concerned with anything beyond "halt/resume target", "read/write registers" or "read/write memory". A vendor of non-free software certainly isn't going to open up all that knowledge to potential competitors. ARM debugging is documented in the various ARM TRM's, the XScale manuals, and various bits and pieces around the internet. The tricky part is probably those bits that are missing, but it's possible to work all these things out yourself. The only commercial player in this field that could have an interest in free debug tools for ARM cores is ARM itself, but they sell both their own RealView stuff and they own Keil, so it's quite unlikely to expect them to come up with free software to compete with their own hard- and software. Chip vendors would have to create software that could be used with their competitors products as well, so this isn't going to happen either. A vendor of JTAG debug tools would a) open up his knowledge to competitors and would b) risk the money he's making from hardware sales, once someone adds support for other hardware or if someone starts selling counterfeits of his hardware. My point is that the situation isn't going to change because of what one vendor does, as they have little/no reason to release their stuff to the public. If you want free tools you'll have to develop them yourself. The OpenOCD is there as a starting point, but of course you're free to start over again if you don't like the approach I've taken. Additional JTAG interfaces can be added quite easily to the OpenOCD, and a solution consisting of a USB chip + CPLD/small FPGA that includes RTCK support etc. wouldn't be hard to build. Best regards, Dominic Rath
Reply by Frank Peelo August 20, 20072007-08-20
Hans-Bernhard Br&#4294967295;ker wrote:
> Chris Hills wrote: > >> In article <13c86o2ejpq04b5@corp.supernews.com>, Paul Curtis >> <plc@rowley.co.uk> writes > > >>> Of course. This is clearly stated as one of the benefits of using >>> our tools. In this way commercial customers can be sure that their >>> application will not be covered by a GPL or LGPL license inherited >>> from the inclusion of GPL/LGPL code in the library they link in. > > >> Does this mean that if you link in a GPL library then you have to >> release the source of the application? > > > Yes.
But only if the library is licensed under GPL. It seems that the LGPL is not the same thing, and GNU don't seem to like it :-) http://www.gnu.org/licenses/why-not-lgpl.html And the license for a library can introduce exceptions to the GPL: http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface
> >> That would mean that you could not use GCC with a GPL licence for >> commercial work. > > > No, it doesn't. Because GCC is a GPLed *program*, not a GPLed library.
In fact, gcc is intended to be usable for commercial, closed-source, proprietary work: http://www.gnu.org/licenses/gpl-faq.html#LibGCCException Frank
Reply by Boudewijn Dijkstra August 20, 20072007-08-20
Op Sat, 18 Aug 2007 22:09:02 +0200 schreef Jonathan Kirwan  
<jkirwan@easystreet.com>:
> Name a few that are (1) USB based, (2) support RTCK, (3) are well > documented for those wishing to write their own software to access the > full features of the hardware/firmware included, and (4) have > unfettered gdb servers available for them in source form so that they > can be compiled on various environments and modified, as needed.
I know one tool vendor that comes very close to your requirements: iSYSTEM. They make several ARM emulators in the range from tens to thousands of euros, and a free (of charge) Windows IDE. Your requirements: 1. Yes. (Also Ethernet.) 2. Yes. (Also scan chain options, idle TCK's and a different speed during init.) 3. Yes. (But Windows API's only.) 4. Not quite. But a GDB server is supported as a plug-in DLL, and with the Windows API you could write your own GDB server. -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/