Re: [Openocd-development] FT2232 & Windows - summary of options
On Mon, Jun 22, 2009 at 10:30 PM, Duane Ellis wrote: > All - I believe - I am not sure - that the primary benefit of > "libft2xxx" is as follows: > > (a) It is measurably faster. > > That just requires "work" to make it faster. > > (b) It works on more platforms, ie: Win7, WinVista, because drivers > exist for those platforms. > > This is tough/hard, nobody on this list is a "windows driver developer". > Grrr. Such is life. > > (c) Nobody was offering a universal "libusb" - type "INF" files for > windows. > I bet you missed the d) option, which I personally would have placed above a) - it is dual serial port support, in particular - RS232 besides JTAG. This is very important to me (I believe at least one more developer is using serial and JTAG). I could live with decreased download speed, maybe would agree to somewhat slower debugging stepping speed, but I just won't bother to install libusb & co. if I loose RS232 (currently ARM-USB-OCD adapter is also the only serial port on my notebook). Regards, Audrius > Looks like Freddie Chopin is working on that :-) Perhaps - we could > have a "contrib" folder with a *binary* libusb0.sys file > and associated "INF" files that references *ALL* ftdi based dongles > - (The VID/PID list is in the source file...) > That *INF* file and matching SYS file should be deliverable with > OpenOCD. > > (d) There is another choice - "WinUSB" > > http://msdn.microsoft.com/en-us/library/aa476426.aspx > > As I understand, it is a a multi-(windoze)-platform solution that > exposes the USB device, functionally in the same manor and style as > "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control > commands. > > I believe there is the only open question that needs to be asked and > answered. > > The MS-WinUSB driver - did not *ship* with WinXP, but is available as a > "co-install" for WinXP. > > As I understand (I have not confirmed, and I do not know all the details > of it), the driver and associated OS-libraries/headers are *PRESENT* on > Vista, and I presume Win7 (with appropriate dev tools installed), > therefore it functionally *SHIPS* with the operating system, and as such > it sould fall under the standard operating system component exception to > the GPL. > > This solution is - by design - something that can be added to WinXP (the > co-install solution). I think of it sort of like this: "The old system > only supplied a CDROM (read-only) driver" - later - new systems come > with CD-WRITER (and today, we have CD-RW) - the *new* os does not > require an upgrade, the *old* os has an upgrade path to make the > CD-WRITER (and now CD-RW) work. > > I should - as a user of that old system - install the OS update - and be > able to make use of that GPL software. > > All is not rosy and perfect, "WinUSB" would require an INF file that > *points* to the driver - much like the work that Freddy is working > towards with a universal libusb inf file > > Agree? > > -Duane. > > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
> Today's OpenOCD handles both services (and more). > If you split out "Smart JTAG", would OpenOCD be > the split-out part ... or the target level service? > > I'd lean towards the latter. My motivation for a low level JTAG over TCP/IP is that it would enable OpenOCD maintainers to run OpenOCD on their development PCs using remote access to a target. This used to be a significant problem for OpenOCD, but I'm not so sure it's that big a deal anymore. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Monday 22 June 2009, Rick Altherr wrote: > > On Jun 22, 2009, at 7:56 PM, David Brownell wrote: > > > I would like my mailbox to stop getting filled with "how can > > we circumvent this software license" crap too. Just stop; if > > the license bothers you, work to change it not circumvent it. > > (Or start your own project with a proprietary license.) > > > > Certain People were on the verge of getting blacklisted... > > > > In your personal mailbox or from the list? I certainly hope not the > latter. Right, my mailbox. I don't manage the list. > There were at least 3 separate threads going and it was > getting difficult to keep track of what options were reasonable/valid/ > popular. I highly doubt the intent was solely to defeat the GPL, Certain People were clearly advocating just ignoring the license. That's crap that nobody should put up with for free software. It's not like we're the RIAA and trying to change license terms (remove "fair use") while ripping off the actual creators, purely to benefit vampiric middlemen. It's simple: code has licence G, follow it, QED. > but > rather to provide an option that doesn't create undue hardship for > either users or developers. Not everyone is an expert on the GPL and > so those who understand why a given option can't be used to comply > with the GPL should explain those reasons to those suggesting the > option. This *has* been explained. The issue wasn't lack of explanation. It was unwillingness to *accept* the explanation ... combined with not presenting a viable alternative. Some folk clearly haven't bothered to read any of the references supplied, much less the license in the source files. Such unwillingness does not indicate an honest disagreement. IMO it shows dishonesty. > While I understand the difficulties in resolving this problem, there > has been a prevailing feeling that the few staunch GPL supporters have > been quick to say No to options without explaining in full _why_ it > won't work. I've felt that the GPL supporters have even acted with > hostility to anyone proposing ideas that don't happen to meet all the > requirements. Those requirements being ... either (a) conform to the current license, or (b) change it. Why should anyone tolerate proposals to violate (a) without (b)? Seriously. It's easy to have a constructive conversation within the scope of (a) and (b). The problem was folk that refused (a) without accepting that the consequence was (b). Loudly. Repeatedly. There's a separate conversation along the lines of "but I thought the license was *really* X not GPL". OK, I can hear that, and not get upset, but in fact there's no real question about what the license is. There's no exception listed anywhere. This is why one reads and understands licences *before* contributing. And that is compatible with the D2XX stuff being purely for personal use, which frankly is what most folk on *THIS* list are doing. Anyone developer who builds the source tree is in personal-use territory. > Education, not exasperation, is the course to be > taken. And before someone is quick to point out that explanations > were provided, yes, some were. When the same proposals were made > again, however, rarely was a reference to the earlier explanation > provided. How many times should one need to repeat "A is A" before people stop asking "Are you sure it's not B instead?" or saying "No matter what proof you give, I believe it's B". Ideally, once is enough. Maybe two or three times. But more than that and the conclusion may seem to be that you are faced with someone who is intent on being unreasonable, not addressing the problem, and just wants to flame. At that point, it's more than reasonable to tune those people out. They're just wasting your time and energy. Fortunately there *ARE* people here who are intent on getting a good solution for the Windows users, and there has been progress on that front. (As well as improved recognition that long term solutions probably require changes there, in part because of code stagnation.) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Jun 22, 2009, at 7:56 PM, David Brownell wrote: On Monday 22 June 2009, Zach Welch wrote: So, notably absent from this list are any type of "wrapper" library. Several contributors oppose this as an option, particularly as these suggestions appear to derive exclusively from the present desire to circumvent the GPL distribution restrictions. For these reasons, I hope the community will stop considering such solutions. I would like my mailbox to stop getting filled with "how can we circumvent this software license" crap too. Just stop; if the license bothers you, work to change it not circumvent it. (Or start your own project with a proprietary license.) Certain People were on the verge of getting blacklisted... In your personal mailbox or from the list? I certainly hope not the latter. There were at least 3 separate threads going and it was getting difficult to keep track of what options were reasonable/valid/ popular. I highly doubt the intent was solely to defeat the GPL, but rather to provide an option that doesn't create undue hardship for either users or developers. Not everyone is an expert on the GPL and so those who understand why a given option can't be used to comply with the GPL should explain those reasons to those suggesting the option. While I understand the difficulties in resolving this problem, there has been a prevailing feeling that the few staunch GPL supporters have been quick to say No to options without explaining in full _why_ it won't work. I've felt that the GPL supporters have even acted with hostility to anyone proposing ideas that don't happen to meet all the requirements. Education, not exasperation, is the course to be taken. And before someone is quick to point out that explanations were provided, yes, some were. When the same proposals were made again, however, rarely was a reference to the earlier explanation provided. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [SERIES 0/4] Whitespace Cleaning
On Monday 22 June 2009, Zach Welch wrote: > > yea, truthfully - compliance with this is all over the map... it does > > vary quite a bit. > > Yup, but these patches will bring almost all operator whitespace issues > into compliance; only a handful of operators will remain to fix later. And there's time to perform manual fixups too. Sad but true: automatic tools generally don't do that good a job of addressing whitespace issues. Somehow they don' yet have "taste". ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Tue, Jun 23, 2009 at 10:37 AM, David Brownell wrote: > On Sunday 21 June 2009, Xiaofan Chen wrote: >> > As an aside, has anyone had the opportunity to try OpenOCD with an >> > FT2232H-based dongle? I believe high-speed USB should almost eliminate >> > latency effects due to going from 1 ms-based frames to 125 us-based >> > microframes. >> > >> >> Not sure here. The blocking I/O will render the benefits of high speed >> USB much less effective. >> >> David Brownell is the real USB expert in the list. He may answer better, >> at least on the Linux side since he is one of the leading Linux usb >> developers. > > I responded to that a while back. The round-trip latency may > well go down with Linux-USB host side drivers. > This makes me think there is a solution for performance on the Linux side, a kernel driver which supports the D2XX similar interface will solve quite some issues. Maybe libftdi+libusb will not be necessary in that case. It seems that there are some work on that front in the Linux usb mailing list. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Tue, Jun 23, 2009 at 11:00 AM, David Brownell wrote: > On Monday 22 June 2009, Duane Ellis wrote: >> (d) There is another choice - "WinUSB" >> >> http://msdn.microsoft.com/en-us/library/aa476426.aspx >> >> As I understand, it is a a multi-(windoze)-platform solution that >> exposes the USB device, functionally in the same manor and style as >> "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control >> commands. >> >> ... >> >> As I understand (I have not confirmed, and I do not know all the details >> of it), the driver and associated OS-libraries/headers are *PRESENT* on >> Vista, and I presume Win7 (with appropriate dev tools installed), >> therefore it functionally *SHIPS* with the operating system, and as such >> it sould fall under the standard operating system component exception to >> the GPL. > > I'd agree. As Xiaofan pointed out, this may be a good > back-end for libusb ... the libftdi-over-libusb stack > might become "the normal solution" on all platforms. > > Later. Someday. When it works. ;) > I've asked the question. http://www.nabble.com/libusb-win32-1.0-schedule-td24143552.html A lot of Germans will go for holiday in June/July time frame (I used to work for Pepperl+Fuchs, a German company). So maybe we have to wait for the answer. Or wait for the real codes. ;-) -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [SERIES 0/4] Whitespace Cleaning
On Mon, 2009-06-22 at 21:24 -0400, Duane Ellis wrote:
> Zach Welch wrote:
> > There have been no objections to these series of patches, so I intend to
> > regenerate and apply them soon.
> >
> There is one thing I do not like - not exactly what you are talking
> about here.. I'd rather my voice be heard...
>
> In general, I think a general "white space cleanup" is nice... and a
> good thing... "Janitor work" - glad you are doing it...
>
> that said, please - I don't want to see us head down the road where
> issues like the ones I out line below come up.
>
> ==
>
> The general statement is this:
>
> What I do *NOT* like and I find it terribly hard to read - is
> utterly *DENSE* code - that is almost *devoid* of white space in both
> the x & y dimensions. Often, white space is there for a reason - and
> "cleanup tools" - are a tad bit too helpful.
I believe that I have been using whitespace appropriately; while I may
have made the code denser in terms its total number of lines, I think
that my changes have been slowly improving the "readability density".
> I've been burned by them before!
>
> ==
> Examples include
> ==
>
> (a) multiple 'format specifiers' to a printf() like function - counting
> function parameters to find 'argument 12' - is daunting.
>
> A specific example: *this* 258 char long printf() statement.
>
> printed = snprintf(buf, buf_size, "protection_fields: %i, prot_reg_addr:
> 0x%x, factory pre-programmed: %i, user programmable: %i\n",
> pri_ext->num_protection_fields, pri_ext->prot_reg_addr, 1 <<
> pri_ext->fact_prot_reg_size, 1 << pri_ext->user_prot_reg_size);
>
> Imagine that - 258 bytes - and that one does not need the format
> specifiers! Wow!
>
> At some point, a *single*column* of parameters, one per line... is much
> better!
> Might not fit some style guide... but please - line length > 150 is sort
> of absurd.
I updated the Style Guide to recommend < 80 columns. Almost any code
will be more readable if factored to fit into such dimensions, so you
are preaching to the choir.
> What I talk about adds white space all over the function call - but
> improves readablity.
All of the patches in these series add whitespace, except for the last
that removes it at end of lines, after '(', and before ')'.
>
> Collapsed IF statements
> ==
>
> (b) - Collapsing if() statements that - just - in the end make the
> statement *longer* on the line..
>
> Example (bad, 127 char line of code, example from "cfi.c")
>
> if((retval = target_write_memory(target, flash_address(bank, 0,
> pri_ext->_unlock2), bank->bus_width, 1, command)) != ERROR_OK)
> {
> return retval;
> }
>
> Example (rewrite-good, use a temp variable, to kill line length)
>
> { uint32_t adr;
> adr = flash_address(bank, 0, pri_ext->_unlock2)
> retval = target_write_memory(target, adr, bank->bus_width, 1,
> command);
> }
> if( retval != ERROR_OK)
> {
> return retval;
> }
I am with you here except for all of the curly braces; those are nearly
superfluous. I think they make the code more "dense" than it should be.
Otherwise, you are right in saying that such lines should be broken out
into separate "do it" and "check it" statements.
> ==
> White space removal in initialized data, or function calls.
> ==
>
> (c) Often, a *LONG* table of data is created, and great pain is taken to
> *ALIGN* commas, parens, and other elements of the data such that things
> line up in a nice neat tabular format,while the whitespace does not meet
> "style guide rules" it is there for other reasons - improved readability
> and comprehension..
I skipped commas for this reason. I saw that it would disrupt more than
it helps.
> yea, truthfully - compliance with this is all over the map... it does
> vary quite a bit.
Yup, but these patches will bring almost all operator whitespace issues
into compliance; only a handful of operators will remain to fix later.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Monday 22 June 2009, Duane Ellis wrote: > (d) There is another choice - "WinUSB" > > http://msdn.microsoft.com/en-us/library/aa476426.aspx > > As I understand, it is a a multi-(windoze)-platform solution that > exposes the USB device, functionally in the same manor and style as > "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control > commands. > > ... > > As I understand (I have not confirmed, and I do not know all the details > of it), the driver and associated OS-libraries/headers are *PRESENT* on > Vista, and I presume Win7 (with appropriate dev tools installed), > therefore it functionally *SHIPS* with the operating system, and as such > it sould fall under the standard operating system component exception to > the GPL. I'd agree. As Xiofan pointed out, this may be a good back-end for libusb ... the libftdi-over-libusb stack might become "the normal solution" on all platforms. Later. Someday. When it works. ;) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Monday 22 June 2009, Zach Welch wrote: > So, notably absent from this list are any type of "wrapper" library. > Several contributors oppose this as an option, particularly as these > suggestions appear to derive exclusively from the present desire to > circumvent the GPL distribution restrictions. For these reasons, I hope > the community will stop considering such solutions. I would like my mailbox to stop getting filled with "how can we circumvent this software license" crap too. Just stop; if the license bothers you, work to change it not circumvent it. (Or start your own project with a proprietary license.) Certain People were on the verge of getting blacklisted... > Please let me know if this summary is factual incorrect or incomplete. Summary seemed fair to me. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Monday 22 June 2009, Zach Welch wrote: > Actually, I see no reason that it cannot be GPL too. ... > > Either way, I would consider adding it to the > repository in the tools/ directory, if that turns out to be a reasonable > plan of action for all. What do you think about that? One caution: mixing licenses in one repository can be trouble. Worth avoiding if possible. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Tue, Jun 23, 2009 at 10:45 AM, Alain Mouette wrote: > > Xiaofan Chen escreveu: >> >> Can you use usb serial port if you use Linux? If not, maybe the >> FTDI driver has some extra ways to make the com port. > > Yes, it works great :) > > there is only a small glitch that when you restart OpenOCD, the second > serial port gets reset, loosin it's baudrate. > > There is somthing about a kernel reser in the libftdxx driver about a config > to avoid that, but I didn't have time to test. > I see. Thanks for the reply. Which JTAG debugger are you using? Do you have "lsusb -vvv" output from that? In the JTAGkey case, it seems to have two JTAG channels and one serial port. And it seems to have only two interfaces in the USB configurations. This kind of confused me. Does both JTAG channels work at the same time with the serial port? -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Monday 22 June 2009, Harald Kipp wrote: > We either need a written GPL exception explicitly granted by all > contributors As I pointed out when I raised the issue. In fact I even went and provided a list of 50 developers who would need to be agreeing to add such an exception. > or a clear statement of at least one of them, that they > don't want this simply because they are in the position to say so. > Without "I wouldn't have contributed if...". I believe there *have* been such statements, several times. The "I wouldn't have contributed..." is simply pointing out that they *looked* at the license before contributing. It's an attempt to forestall the annoying claims by some folk that the license already had some kind of exception. > P.S.: This discussion about free software reminds me of > Brian: "Excuse me. Are you the Judean People's Front?" > Reg: "Fuck off! We're the People's Front of Judea." Reminds me more of a two-year old arguing. You will notice that *NOBODY* who promotes the idea of adding an "exception" has actually bellied up to the bar and started to do the legwork to get developers to agree to such a licence change. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Sunday 21 June 2009, Xiaofan Chen wrote: > > As an aside, has anyone had the opportunity to try OpenOCD with an > > FT2232H-based dongle? I believe high-speed USB should almost eliminate > > latency effects due to going from 1 ms-based frames to 125 us-based > > microframes. > > > > Not sure here. The blocking I/O will render the benefits of high speed > USB much less effective. > > David Brownell is the real USB expert in the list. He may answer better, > at least on the Linux side since he is one of the leading Linux usb > developers. I responded to that a while back. The round-trip latency may well go down with Linux-USB host side drivers. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Monday 22 June 2009, Zach Welch wrote: > On Mon, 2009-06-22 at 19:59 +0200, Dominic wrote: > > > > Øyvind mentioned the idea of wrapping the JTAG API in TCP/IP. Aside > > from performance implications I think this would require some > > significant development efforts with little immediate benefits. Even > > worse, it would encourage other JTAG interface vendors to implement > > their JTAG interface layer as a binary only driver that talks to the > > OpenOCD via TCP/IP layer, too. FTDI doesn't see themselves as a JTAG interface vendor though, and that's part of the problem. :( Getting more driver support wouldn't be entirely bad, would it? Most of those JTAG adapter vendors are just ignoring OpenOCD right now. Maybe they talk to GDB through a proprietary GDB server engine; maybe they don't talk GDB at all. We could be presenting a choice between getting GNU tools support by either (a) writing proprietary JTAG engine *AND* proprietary GDB server engine; or (b) writing proprietary JTAG engine but *REUSING* OpenOCD GDB server engine. Anyone switching to (b) would necessarily start improving the OpenOCD code. And they'd likely realize that adding Linux support -- instead of being Windows-only -- became much easier. That's in addition to (c) propietary JTAG engine plus proprietary non-GNU tools Vendors now in category (c) that provide such OpenOCD engines seem like incremental wins too. But if any of them do so, I'd be (pleasantly) surprised. > I am opposed to this as > well, for the same reasons. This is why I did > not suggest it until someone else suggested it. I want to see libusb > and libfdti fixed, I think *everyone* wants to see those get fixed. "How" is open; Duane's WinUSB note was interesting. > and I do not want to open the door to more binary > drivers. If I were to implement the TCP/IP interface without pay, I > would release it under the GPL to prevent this situation from ever > occurring. At this point, I am tempted to implement it simply in order > to close this back door to binary drivers. It wouldn't work that way at all. As soon as there's a well defined protocol, it could be re-implemented without using your code. There are two ways to take that reality. One is the Microsoft way: as a threat, to be responded to by ensuring the protocol is always changing and abysmally documented, so that interop using anyone else's code tends to be weak in critical areas. The other is the IETF/Internet way, to be responded to by making sure the protocol is well-documented, well-behaving, and evolves cleanly. This is how we got HTTP and SSL, not to mention TCP in the first place. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf fileforwindows/libusb-win32
On Tue, Jun 23, 2009 at 6:01 AM, Duane Ellis wrote: > Freddie, > > I want to understand what you are working on. > > I believe there are 3 or 4 things needed to make OpenOCD work with a > "universal inf file" for LibUSB really work. > > I think of it this way: > > (a) We have a simple "text file" - with 4 columns. > > Column 1 - Vendor ID > Column 2 - Product ID > Column 3 - Product Root Device Type, ie: ft2232 - or - other > Column 4 - "Human Friendly Name". > > (b) Perhaps that text file supports "#" comments. > > (c) Question: Given the above, how hard would it be to create a > *SIMPLE* perl, shell, awk, whatever script to create a generic LibUSB > "windows inf" file - that *LIST* *ALL* items listed in the simple text > file. I do not use perl. But I think the above is not that difficult for the programmers here. It is not that necessary though. The INF file generated by libusb-win32 is very easy to understand and the modification is not that bad even with Notepad. ;-) > (d) If the above is simple - and I believe it is - then "packagers" of > OpenOCD *could* - then package "LibUSB0.sys" with the INF file.. and the > more general problem would be solved. The libusb0.dll file is also necessary. I think the cat file is necessary as well. > (d) In effect, a packager *could* only need to "copy" a pre-built > "libusb0.sys" file into the same directory as the "generic > openocd-libusb.inf" file above. > > *THEN* - a "prebuilt cygwin" user (or mingw user) *could* - re-install > the "usb driver" for their dongle - and specify the 'openocd-libusb.inf' > file instead of the default one that came with/from the dongle vendor. > As experienced by Gene Smith and I, sometimes Windows will not allow this INF file to be installed. In that case, I used the command line installation method. But Gene Smith mentioned that it may not survive the reboot. I had not such problem under XP and Vista 32bit. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Monday 22 June 2009, Øyvind Harboe wrote: > My favourite is to introduce a serialized protocol for JTAG that > can work over TCP/IP, pipes, even fn calls... Such a thing would be useful for a more functional USB interface to JTAG adapters. Consider some microcontroller using a (high speed!) USB interface and accepting those serialized JTAG messages. TMS transitions; shift this data in, return (or discard) the data shifted out; and some GPIO-ish commands for SRST and TRST. That'd be the bare minimum. Such a protocol should also provide two more things: - The immediately-useful one would be offloaded polling. As in: issue this command; if F(result) do this else do that; continue for more commands. And the "do..." would involve reporting some data back. Yes, that involves limited programmability... - The less-immediately-useful one would be collecting such data for non-JTAG signals, in support of debug instrumentation and event triggering. EMU0/EMU1/... on TI's JTAG connectors. Or, more fully documented, ARM or Nexus trace connectors. Another way to think of this is as an *OPEN* protocol for talking with JTAG adapters. A soft one, which could more easily evolve over time (e.g. to deal with the upcoming 2-wire JTAG flavors.) The FT2232 is one vendor-specific flavor of "open" ... and this thread highlights problems derived from that vendor. Downside: current tools vendors might prefer to have closed protocols there, as aids to vendor lockin. It's easier to sell "Our Adapter(s) + Our Software = $". > This has been discussed before and could be *very* useful > for other stuff, including remote access to targets for debug > purposes... > > OpenOCD would itself also implement this as a server > to forwarding it to the underlying driver, acting as the server. That's a second model though. Draw a line, if you will, between a "smart JTAG" level server, and a target level service which understands how to single step ARM9TDMI versus Cortex-M3, etc; or provides good boundary scan debugging/diagnostic tools; etc. Today's OpenOCD handles both services (and more). If you split out "Smart JTAG", would OpenOCD be the split-out part ... or the target level service? I'd lean towards the latter. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Tue, Jun 23, 2009 at 3:30 AM, Duane Ellis wrote: > All - I believe - I am not sure - that the primary benefit of > "libft2xxx" is as follows: > > (a) It is measurably faster. > > That just requires "work" to make it faster. > > (b) It works on more platforms, ie: Win7, WinVista, because drivers > exist for those platforms. > > This is tough/hard, nobody on this list is a "windows driver developer". > Grrr. Such is life. There are not many people who is a Windows driver developer (very few) and is willing to contribute to open source projects (even fewer). As of now, libusb-win32+libftdi is not the solution for 64bit Windows users (Vista 64 bit and Windows 7 64bit). FTD2XX is the solution for them (through private build). I frequent the libusb-win32 mailing list along with libusb mailing list. So I am familiar with the situations. But I am not a USB expert and I can not help coding. > (c) Nobody was offering a universal "libusb" - type "INF" files for > windows. > > Looks like Freddie Chopin is working on that :-) Perhaps - we could > have a "contrib" folder with a *binary* libusb0.sys file > and associated "INF" files that references *ALL* ftdi based dongles > - (The VID/PID list is in the source file...) > That *INF* file and matching SYS file should be deliverable with > OpenOCD. This is possible. But as Gene Smith tried, due to the fact Windows will tend to favor the WHQL driver, there can be complications even for XP/Vista 32bit. Again, FTD2XX is the better solution for all the Windows users. That being said, I believe many Windows users can get the it working if we package it nicely and with good instructions. The universal INF helps. > (d) There is another choice - "WinUSB" > > http://msdn.microsoft.com/en-us/library/aa476426.aspx > > As I understand, it is a a multi-(windoze)-platform solution that > exposes the USB device, functionally in the same manor and style as > "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control > commands. It only Works under XP and Vista (32bit or 64bit). Windows 2003 is basically XP enhanced. Windows XP64 bit has actually the same kernel as Windows 2003 64bit. WinUSB does not work for Windows 2000 users. FTD2xx works for Windows 2000 users. libusb-win32 works from Windows 98SE/Win ME to Win2k to XP/Vista (32bit). It actually works under XP 64bit as well. > I believe there is the only open question that needs to be asked and > answered. > > The MS-WinUSB driver - did not *ship* with WinXP, but is available as a > "co-install" for WinXP. > > As I understand (I have not confirmed, and I do not know all the details > of it), the driver and associated OS-libraries/headers are *PRESENT* on > Vista, and I presume Win7 (with appropriate dev tools installed), > therefore it functionally *SHIPS* with the operating system, and as such > it sould fall under the standard operating system component exception to > the GPL. WinUSB is present on Vista. I am using Vista 32 bit and I know it. It should be included in Windows 7 as well. > This solution is - by design - something that can be added to WinXP (the > co-install solution). I think of it sort of like this: "The old system > only supplied a CDROM (read-only) driver" - later - new systems come > with CD-WRITER (and today, we have CD-RW) - the *new* os does not > require an upgrade, the *old* os has an upgrade path to make the > CD-WRITER (and now CD-RW) work. > > I should - as a user of that old system - install the OS update - and be > able to make use of that GPL software. I am not a lawyer but I believe this should be the case. WinUSB is from Microsoft and is part of the WDK. But again, who knows the GPL well enough to confirm this? Many Linux users are enjoying the proprietary driver (especially ATI/Nvidia) even though this is a gray area. > All is not rosy and perfect, "WinUSB" would require an INF file that > *points* to the driver - much like the work that Freddy is working > towards with a universal libusb inf file Stephan Meyer (libusb-win32) user see WinUSB as the possible solution for 64bit Windows as well. That is why he added the WinUSB backend to libusb-win32 1.0 development branch. Unfortunately it is not working yet. The libusb-win32 WinUSB backend simplifies the use of WinUSB. If you are going this route, you may want to help Stephan finishing on the libusb-win32 WinUSB backend. That may be faster than building a new WinUSB backend for OpenOCD. All in all, even though I think FTD2xx is the better solution for Windows users (no matter 32bit or 64bit), there could be some packaged solution (with libusb-win32+libftdi) for Windows 32bit users. This can be the official binary which is compatible with GPL (with some limits). The build kit idea for FTD2xx is also another solution. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berl
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Joseph Kuss wrote: > To All, > > I am using openOCD 0.1.0, GDB 6.8 and Eclipse Ganymede > > For the Eagle100 board, using LM3S6918: > > I can download my program into flash ok > I can start/continue the program, > I just can not get breakpoints to work. > > Please Help. If I need to send this message in a different format or to > a different person or group, please let me know. > (a) Try your program in *RAM*, see if breakpoints work there, this rules out RAM vrs FLASH breakpoint problems. (b) Where are the breakpoints being placed? Flash or RAM? (c) GDB often tries to keep track of your earlier breakpoints - how many do you have active? With Insight (GDB-TK) one often must cleanup and delete the cached list of break points when code changes, otherwise they get put in rather strange places. (d) Enable the "debug log level 3" - what does the log tell you when you set a break point and run (read the openocd manual about this) (e) Where did you get OpenOCD from? Did you build it, or did you download a pre-built version? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Mon, Jun 22, 2009 at 11:55 PM, Gene Smith wrote: >> Have you tried the following method? >> >> Run cmd.exe as admin (under Vista) and >> D:\libusb-win32-device-bin-0.1.12.1\bin>c:\windows\sys tem32\rundll32 >> libusb0.dll,usb_install_driver_np_rundll olimex.inf >> > > Unfortunately, at least on my XP setup, this does not survive a reboot. > When I plug in USB after a reboot, it asks me again to install the > proprietary olimex drivers from CD and the libusb-win32 driver does not > appear in hardware mgr. If I redo the above command libusb driver comes > back and XP stops asking me to install drivers on usb pull/plug (until > the next reboot). That is a bit strange. > As I mentioned before, installing the libusb driver with the "update > driver" right click dialogs never works for me. If it did, maybe it > would be permanent? In my experiences, both will be permanent if they work. For me the console version always works. The manual method sometime does not work. Take note the major reason is that the FTDI driver is WHQL. Windows will favor the WHQL driver over other alternative 3rd party driver. This is a significant disadvantage of using libusb-win32 for any device which has already a built-in driver (say HID or USB mass storage or similar) or a 3rd party WHQL driver. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Mon, Jun 22, 2009 at 11:16 PM, Gene Smith wrote: > Xiaofan Chen wrote: >> >> No. By using libusb-win32 device driver as the driver for >> the Olimex device instead of FTDI driver, you will lost the >> serial port. > > Maybe I was not understanding. I think you are really saying that there > is *no way* to have the serial port *and* the jtag running together on > windows with the free drivers. (This is also the impression I got from > reading all the GPL discussions.) I thought you were originally > explaining a way to have both. I am not exactly sure how the extra USB serial port is implemented. Take note that I do not have a real hardware for testing right now. Right now the conclusion from those who tried is that the USB serial port will be gone. Can you use usb serial port if you use Linux? If not, maybe the FTDI driver has some extra ways to make the com port. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [SERIES 0/4] Whitespace Cleaning
Zach Welch wrote:
> There have been no objections to these series of patches, so I intend to
> regenerate and apply them soon.
>
There is one thing I do not like - not exactly what you are talking
about here.. I'd rather my voice be heard...
In general, I think a general "white space cleanup" is nice... and a
good thing... "Janitor work" - glad you are doing it...
that said, please - I don't want to see us head down the road where
issues like the ones I out line below come up.
==
The general statement is this:
What I do *NOT* like and I find it terribly hard to read - is
utterly *DENSE* code - that is almost *devoid* of white space in both
the x & y dimensions. Often, white space is there for a reason - and
"cleanup tools" - are a tad bit too helpful.
I've been burned by them before!
==
Examples include
==
(a) multiple 'format specifiers' to a printf() like function - counting
function parameters to find 'argument 12' - is daunting.
A specific example: *this* 258 char long printf() statement.
printed = snprintf(buf, buf_size, "protection_fields: %i, prot_reg_addr:
0x%x, factory pre-programmed: %i, user programmable: %i\n",
pri_ext->num_protection_fields, pri_ext->prot_reg_addr, 1 <<
pri_ext->fact_prot_reg_size, 1 << pri_ext->user_prot_reg_size);
Imagine that - 258 bytes - and that one does not need the format
specifiers! Wow!
At some point, a *single*column* of parameters, one per line... is much
better!
Might not fit some style guide... but please - line length > 150 is sort
of absurd.
What I talk about adds white space all over the function call - but
improves readablity.
Collapsed IF statements
==
(b) - Collapsing if() statements that - just - in the end make the
statement *longer* on the line..
Example (bad, 127 char line of code, example from "cfi.c")
if((retval = target_write_memory(target, flash_address(bank, 0,
pri_ext->_unlock2), bank->bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
Example (rewrite-good, use a temp variable, to kill line length)
{ uint32_t adr;
adr = flash_address(bank, 0, pri_ext->_unlock2)
retval = target_write_memory(target, adr, bank->bus_width, 1,
command);
}
if( retval != ERROR_OK)
{
return retval;
}
==
White space removal in initialized data, or function calls.
==
(c) Often, a *LONG* table of data is created, and great pain is taken to
*ALIGN* commas, parens, and other elements of the data such that things
line up in a nice neat tabular format,while the whitespace does not meet
"style guide rules" it is there for other reasons - improved readability
and comprehension..
yea, truthfully - compliance with this is all over the map... it does
vary quite a bit.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [SERIES 0/4] Whitespace Cleaning
On Wed, 2009-06-17 at 21:52 -0700, Zach Welch wrote: > The following chain of patch series performs tree-wide whitespace > clean-up, using systematic search and replacement (i.e. sed). > It must be applied on top of the last series that changes the types. > > The patches in these series have been reviewed to ensure there are no > adverse affects. Some operators have been skipped for now, because > they may be used in both binary and unary contexts (e.g. +, -, *, &), > so their resulting patches will not be usable without more work. > > After this chain has been applied, other automatic steps can perform > additional clean-up without having to touch as many lines in the tree. > > = There have been no objections to these series of patches, so I intend to regenerate and apply them soon. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Tue, 2009-06-23 at 02:31 +0300, Yusuf Caglar AKYUZ wrote: > Zach Welch wrote: > > Actually, I see no reason that it cannot be GPL too. It's "only" a > > build tool; it will not be linking to either OpenOCD or FTD2XX, right? > > The full GPL would prevent others from creating proprietary versions of > > your tool, which may or may not be what you desire personally; however, > > your license does not impact the licenses of what the tool builds. This > > is why the "build kit loophole" works: they are totally separate works. > > Otherwise, a GPL package manager could only build/install GPL packages! > > > > Of course, a tool that includes _necessary_ build scripts or components > > for building OpenOCD would be forced to be GPL (see the license), but > > that is not what we are talking about. Developers have everything they > > need to compile everything by hand; you are adding a high-level helper > > script that ties it all together for users, so it is not "necessary". > > > > I hope that others will step forward and correct me if I am wrong on the > > details, but I hope this generally helps clarify these particular > > licensing details. Either way, I would consider adding it to the > > repository in the tools/ directory, if that turns out to be a reasonable > > plan of action for all. What do you think about that? > > > > I'm not an OpenOCD user under Windows but a tool like this is not > hard to implement so I'm willing to integrate further suggestions > from Windows users. When this is a complete solution, I guess it > will help to include this in tools dir. I think any solution that starts to show signs of success will be worth putting into the tree, so others can submit patches to improve it directly. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Alain Mouette wrote: > Yusuf Caglar AKYUZ escreveu: >>> Out of sheer curiosity: how will your Qt wrapper be licensed? :) :) >>> >> Whichever license is appropriate, both for OpenOCD and FTD2XX. LGPL >> may be? > > The Qt licence is strict GPL, so it cannot be anything else... > No, not anymore. Please see http://www.qtsoftware.com/downloads. Thanks, Caglar > Alain > > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Yusuf Caglar AKYUZ escreveu: >> >> Out of sheer curiosity: how will your Qt wrapper be licensed? :) :) >> > > Whichever license is appropriate, both for OpenOCD and FTD2XX. LGPL > may be? The Qt licence is strict GPL, so it cannot be anything else... Alain ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Hi Zach, Zach Welch escreveu: > > With OpenOCD linked to the FTD2XX driver inside the image? > > That would be a GPL violation too. > > Seriously. There are no legal shortcuts here. I understand your point of view, but my heart is split in two... 1) by enforcing the GPL you surely are incentivating further developpement of libftdi. It would even be faster if so much energy spent on rant could be directed to libftdi study :) 2) by not distributing with ftdxx, interest in OpenOCD will be lower and quite a few interesting contributors (with funds) will not be atracted here :( But one thing is cristal clear: the rules were set from the begining... Cheers, Alain ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Michael Fischer escreveu: > > In this case we give the user the possibility to make a private > build in a easy way. That is not the case at the moment. I sent a message in 2009jun16 called "Compiling dificulties" because as a reasonably experienced Linux user/programer, it took me 3 days to complile OpenOCD. I pointed out 3 majot problems that if solved would have taken me only 1/2 hour... Unfornunatly that message deserved no answer :( :( Alain PS: jus in the spirit of not being a PITA, I repeat most of that message here: --- As my small contribution, I am making this summary so that it can possibly be improuved. svn version 2218, Ubuntu 8.04 1) When configure was checking for libftdxx, I had a bad time finding where it should go and what it should be named. The expected path/file could be included in the error message, it would have saved a lot of trouble. The exact name is also an issue, when compililing libftd2xx.so is used, but when run, libftd2xx.so.0 is used. This could be possibly a problem somewhere. 2) after I started compiling, I had an error because "makeinfo" was missing. I supose that this should be checked by configure. It also would help to say that it is part of "texinfo" 3) without the option --enable-maintainer-mode it does not compile to the end, this is probably a bug, otherwise the option would not have existed. I agree that there is a message from .bootstrap, but it does not show when repeating the command, so I missed it ;-) Thanks for all :) Alain Mouette ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Jun 22, 2009, at 4:16 PM, Zach Welch wrote: Actually, I see no reason that it cannot be GPL too. It's "only" a build tool; it will not be linking to either OpenOCD or FTD2XX, right? The full GPL would prevent others from creating proprietary versions of your tool, which may or may not be what you desire personally; however, your license does not impact the licenses of what the tool builds. This is why the "build kit loophole" works: they are totally separate works. Otherwise, a GPL package manager could only build/install GPL packages! Don't give the FSF any ideas. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Zach Welch wrote: > Actually, I see no reason that it cannot be GPL too. It's "only" a > build tool; it will not be linking to either OpenOCD or FTD2XX, right? > The full GPL would prevent others from creating proprietary versions of > your tool, which may or may not be what you desire personally; however, > your license does not impact the licenses of what the tool builds. This > is why the "build kit loophole" works: they are totally separate works. > Otherwise, a GPL package manager could only build/install GPL packages! > > Of course, a tool that includes _necessary_ build scripts or components > for building OpenOCD would be forced to be GPL (see the license), but > that is not what we are talking about. Developers have everything they > need to compile everything by hand; you are adding a high-level helper > script that ties it all together for users, so it is not "necessary". > > I hope that others will step forward and correct me if I am wrong on the > details, but I hope this generally helps clarify these particular > licensing details. Either way, I would consider adding it to the > repository in the tools/ directory, if that turns out to be a reasonable > plan of action for all. What do you think about that? > I'm not an OpenOCD user under Windows but a tool like this is not hard to implement so I'm willing to integrate further suggestions from Windows users. When this is a complete solution, I guess it will help to include this in tools dir. Thanks, Caglar > Cheers, > > Zach > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Tue, 2009-06-23 at 01:50 +0300, Yusuf Caglar AKYUZ wrote: > Zach Welch wrote: > > On Tue, 2009-06-23 at 01:36 +0300, Yusuf Caglar AKYUZ wrote: > >> Zach Welch wrote: > >>> Hi all, > >>> > >>> I will try to summarize the OpenOCD license situation for the community: > >>> > >>> - OpenOCD is licensed under the GPL -- without exceptions. > >>> - Binaries linking to FTD2XX may NOT be distributed. > >>> - Neither static nor shared, direct nor indirect. > >>> - There will be no future exceptions to this rule. > >>> - Past "violations" will not be pursued, but we expect compliance now. > >>> > >>> The "best for open source" solution will be to remedy all deficiencies > >>> in libusb and libftdi, even if that takes more time and labor. This > >>> will provide a fully open source solution for users, which should be > >>> preferred by the community of maintainers, contributors, and vendors. > >>> Conversely, preference to the proprietary driver as a long-term solution > >>> undermines the free software community and the freedoms of its users. > >>> > >>> Until an open software solution manifests itself, there appear to be two > >>> acceptable (if hard) workarounds to distribute binaries to end-users: > >>> > >>> 1) A "build kit" can be distributed that compiles the source code from > >>> scratch on the machine of each user that wants to use the closed FTD2XX > >>> driver. This solution can be developed in time for the 0.2.0 release. > >>> Is someone already working on one and will share it with the community? > >>> > >> I'm currently trying this approach. I'm trying to build latest SVN > >> head and preparing a simple wrapper GUI based on Qt, though it is a > >> little bit slow on my Windows XP virtual machine. > > > > Excellent!! You will be praised highly for delivering such a solution, > > so please keep the community apprised of your progress. > > > > Out of sheer curiosity: how will your Qt wrapper be licensed? :) :) > > > > Whichever license is appropriate, both for OpenOCD and FTD2XX. LGPL > may be? Actually, I see no reason that it cannot be GPL too. It's "only" a build tool; it will not be linking to either OpenOCD or FTD2XX, right? The full GPL would prevent others from creating proprietary versions of your tool, which may or may not be what you desire personally; however, your license does not impact the licenses of what the tool builds. This is why the "build kit loophole" works: they are totally separate works. Otherwise, a GPL package manager could only build/install GPL packages! Of course, a tool that includes _necessary_ build scripts or components for building OpenOCD would be forced to be GPL (see the license), but that is not what we are talking about. Developers have everything they need to compile everything by hand; you are adding a high-level helper script that ties it all together for users, so it is not "necessary". I hope that others will step forward and correct me if I am wrong on the details, but I hope this generally helps clarify these particular licensing details. Either way, I would consider adding it to the repository in the tools/ directory, if that turns out to be a reasonable plan of action for all. What do you think about that? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Zach Welch wrote: > On Tue, 2009-06-23 at 01:36 +0300, Yusuf Caglar AKYUZ wrote: >> Zach Welch wrote: >>> Hi all, >>> >>> I will try to summarize the OpenOCD license situation for the community: >>> >>> - OpenOCD is licensed under the GPL -- without exceptions. >>> - Binaries linking to FTD2XX may NOT be distributed. >>> - Neither static nor shared, direct nor indirect. >>> - There will be no future exceptions to this rule. >>> - Past "violations" will not be pursued, but we expect compliance now. >>> >>> The "best for open source" solution will be to remedy all deficiencies >>> in libusb and libftdi, even if that takes more time and labor. This >>> will provide a fully open source solution for users, which should be >>> preferred by the community of maintainers, contributors, and vendors. >>> Conversely, preference to the proprietary driver as a long-term solution >>> undermines the free software community and the freedoms of its users. >>> >>> Until an open software solution manifests itself, there appear to be two >>> acceptable (if hard) workarounds to distribute binaries to end-users: >>> >>> 1) A "build kit" can be distributed that compiles the source code from >>> scratch on the machine of each user that wants to use the closed FTD2XX >>> driver. This solution can be developed in time for the 0.2.0 release. >>> Is someone already working on one and will share it with the community? >>> >> I'm currently trying this approach. I'm trying to build latest SVN >> head and preparing a simple wrapper GUI based on Qt, though it is a >> little bit slow on my Windows XP virtual machine. > > Excellent!! You will be praised highly for delivering such a solution, > so please keep the community apprised of your progress. > > Out of sheer curiosity: how will your Qt wrapper be licensed? :) :) > Whichever license is appropriate, both for OpenOCD and FTD2XX. LGPL may be? Regards, Caglar > Thanks, > > Zach > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/2] openocd.texi - move JIM-Tcl chapter earlier
On Mon, 2009-06-22 at 14:45 -0700, David Brownell wrote: > Move the short chapter about JIM-Tcl earlier, so that we > can reasonably assume it's been introduced before we start > presenting things that presume such an introduction. > Plus a few minor typo-level fixes. > --- > doc/openocd.texi | 88 - > 1 file changed, 48 insertions(+), 40 deletions(-) > Committed. I have wanted to move this chapter for months, for the exact same reason that you give. When I read the manual for the first time, I was confused temporarily by forward references that should now be resolved by these changes, so I am glad to see you made them. :) Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
On Tue, 2009-06-23 at 01:36 +0300, Yusuf Caglar AKYUZ wrote: > Zach Welch wrote: > > Hi all, > > > > I will try to summarize the OpenOCD license situation for the community: > > > > - OpenOCD is licensed under the GPL -- without exceptions. > > - Binaries linking to FTD2XX may NOT be distributed. > > - Neither static nor shared, direct nor indirect. > > - There will be no future exceptions to this rule. > > - Past "violations" will not be pursued, but we expect compliance now. > > > > The "best for open source" solution will be to remedy all deficiencies > > in libusb and libftdi, even if that takes more time and labor. This > > will provide a fully open source solution for users, which should be > > preferred by the community of maintainers, contributors, and vendors. > > Conversely, preference to the proprietary driver as a long-term solution > > undermines the free software community and the freedoms of its users. > > > > Until an open software solution manifests itself, there appear to be two > > acceptable (if hard) workarounds to distribute binaries to end-users: > > > > 1) A "build kit" can be distributed that compiles the source code from > > scratch on the machine of each user that wants to use the closed FTD2XX > > driver. This solution can be developed in time for the 0.2.0 release. > > Is someone already working on one and will share it with the community? > > > > I'm currently trying this approach. I'm trying to build latest SVN > head and preparing a simple wrapper GUI based on Qt, though it is a > little bit slow on my Windows XP virtual machine. Excellent!! You will be praised highly for delivering such a solution, so please keep the community apprised of your progress. Out of sheer curiosity: how will your Qt wrapper be licensed? :) :) Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Zach Welch wrote: > Hi all, > > I will try to summarize the OpenOCD license situation for the community: > > - OpenOCD is licensed under the GPL -- without exceptions. > - Binaries linking to FTD2XX may NOT be distributed. > - Neither static nor shared, direct nor indirect. > - There will be no future exceptions to this rule. > - Past "violations" will not be pursued, but we expect compliance now. > > The "best for open source" solution will be to remedy all deficiencies > in libusb and libftdi, even if that takes more time and labor. This > will provide a fully open source solution for users, which should be > preferred by the community of maintainers, contributors, and vendors. > Conversely, preference to the proprietary driver as a long-term solution > undermines the free software community and the freedoms of its users. > > Until an open software solution manifests itself, there appear to be two > acceptable (if hard) workarounds to distribute binaries to end-users: > > 1) A "build kit" can be distributed that compiles the source code from > scratch on the machine of each user that wants to use the closed FTD2XX > driver. This solution can be developed in time for the 0.2.0 release. > Is someone already working on one and will share it with the community? > I'm currently trying this approach. I'm trying to build latest SVN head and preparing a simple wrapper GUI based on Qt, though it is a little bit slow on my Windows XP virtual machine. Regards, Caglar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD, the GPL, and FTD2XX
Hi all, I will try to summarize the OpenOCD license situation for the community: - OpenOCD is licensed under the GPL -- without exceptions. - Binaries linking to FTD2XX may NOT be distributed. - Neither static nor shared, direct nor indirect. - There will be no future exceptions to this rule. - Past "violations" will not be pursued, but we expect compliance now. The "best for open source" solution will be to remedy all deficiencies in libusb and libftdi, even if that takes more time and labor. This will provide a fully open source solution for users, which should be preferred by the community of maintainers, contributors, and vendors. Conversely, preference to the proprietary driver as a long-term solution undermines the free software community and the freedoms of its users. Until an open software solution manifests itself, there appear to be two acceptable (if hard) workarounds to distribute binaries to end-users: 1) A "build kit" can be distributed that compiles the source code from scratch on the machine of each user that wants to use the closed FTD2XX driver. This solution can be developed in time for the 0.2.0 release. Is someone already working on one and will share it with the community? 2) A "socket interface driver" that provides generic JTAG driver support can be distributed, to which a completely separate FTD2XX driver can be connected (from its own independent process space). That binary driver could use a small "socket driver" library to manage connections and exchange messages with OpenOCD, but such re-use would be possible if and only if that library is licensed under the LGPL (or similar terms). This could be developed for 0.3.0 or later releases; however, an open source driver solution should be considered the higher priority, because sockets will introduce unavoidable performance penalties. The existing maintainers and contributors have expressed willingness to accept these two solutions to work around the "limitations" of the GPL, so these pass our "GPL filters". It will be less work to implement one of these technical solutions than to continue debating solutions that fall into legal gray areas. Solutions that violate the GPL should not be given further consideration. So, notably absent from this list are any type of "wrapper" library. Several contributors oppose this as an option, particularly as these suggestions appear to derive exclusively from the present desire to circumvent the GPL distribution restrictions. For these reasons, I hope the community will stop considering such solutions. Please let me know if this summary is factual incorrect or incomplete. Sincerely, Zach Welch Corvallis, OR ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf fileforwindows/libusb-win32
Freddie, I want to understand what you are working on. I believe there are 3 or 4 things needed to make OpenOCD work with a "universal inf file" for LibUSB really work. I think of it this way: (a) We have a simple "text file" - with 4 columns. Column 1 - Vendor ID Column 2 - Product ID Column 3 - Product Root Device Type, ie: ft2232 - or - other Column 4 - "Human Friendly Name". (b) Perhaps that text file supports "#" comments. (c) Question: Given the above, how hard would it be to create a *SIMPLE* perl, shell, awk, whatever script to create a generic LibUSB "windows inf" file - that *LIST* *ALL* items listed in the simple text file. (d) If the above is simple - and I believe it is - then "packagers" of OpenOCD *could* - then package "LibUSB0.sys" with the INF file.. and the more general problem would be solved. (d) In effect, a packager *could* only need to "copy" a pre-built "libusb0.sys" file into the same directory as the "generic openocd-libusb.inf" file above. *THEN* - a "prebuilt cygwin" user (or mingw user) *could* - re-install the "usb driver" for their dongle - and specify the 'openocd-libusb.inf' file instead of the default one that came with/from the dongle vendor. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 2/2] openocd.texi - move JIM-Tcl chapter earlier
Move the short chapter about JIM-Tcl earlier, so that we
can reasonably assume it's been introduced before we start
presenting things that presume such an introduction.
Plus a few minor typo-level fixes.
---
doc/openocd.texi | 88 -
1 file changed, 48 insertions(+), 40 deletions(-)
Move the short chapter about JIM-Tcl earlier, so that we
can reasonably assume it's been introduced before we start
presenting things that presume such an introduction.
Plus a few minor typo-level fixes.
---
doc/openocd.texi | 88 -
1 file changed, 48 insertions(+), 40 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -63,10 +63,10 @@ Free Documentation License''.
* Developers:: OpenOCD Developers
* Building OpenOCD:: Building OpenOCD From SVN
* JTAG Hardware Dongles::JTAG Hardware Dongles
+* About JIM-Tcl::About JIM-Tcl
* Running:: Running OpenOCD
* OpenOCD Project Setup::OpenOCD Project Setup
* Config File Guidelines:: Config File Guidelines
-* About JIM-Tcl::About JIM-Tcl
* Daemon Configuration:: Daemon Configuration
* Interface - Dongle Configuration:: Interface - Dongle Configuration
* Reset Configuration:: Reset Configuration
@@ -659,6 +659,50 @@ FlashLINK JTAG programing cable for PSD
@end itemize
+...@node About JIM-Tcl
+...@chapter About JIM-Tcl
+...@cindex JIM Tcl
+...@cindex tcl
+
+OpenOCD includes a small ``Tcl Interpreter'' known as JIM-Tcl.
+This programming language provides a simple and extensible
+command interpreter.
+
+All commands presented in this Guide are extensions to JIM-Tcl.
+You can use them as simple commands, without needing to learn
+much of anything about Tcl.
+Alternatively, can write Tcl programs with them.
+
+You can learn more about JIM at its website, @url{http://jim.berlios.de}.
+
+...@itemize @bullet
+...@item @b{JIM vs. Tcl}
+...@* JIM-TCL is a stripped down version of the well known Tcl language,
+which can be found here: @url{http://www.tcl.tk}. JIM-Tcl has far
+fewer features. JIM-Tcl is a single .C file and a single .H file and
+implements the basic Tcl command set. In contrast: Tcl 8.6 is a
+4.2 MB .zip file containing 1540 files.
+
+...@item @b{Missing Features}
+...@* Our practice has been: Add/clone the real Tcl feature if/when
+needed. We welcome JIM Tcl improvements, not bloat.
+
+...@item @b{Scripts}
+...@* OpenOCD configuration scripts are JIM Tcl Scripts. OpenOCD's
+command interpreter today is a mixture of (newer)
+JIM-Tcl commands, and (older) the orginal command interpreter.
+
+...@item @b{Commands}
+...@* At the OpenOCD telnet command line (or via the GDB mon command) one
+can type a Tcl for() loop, set variables, etc.
+
+...@item @b{Historical Note}
+...@* JIM-Tcl was introduced to OpenOCD in spring 2008.
+
+...@item @b{Need a crash course in Tcl?}
+...@*@xref{Tcl Crash Course}.
+...@end itemize
+
@node Running
@chapter Running
@cindex command line options
@@ -693,7 +737,7 @@ clients (Telnet, GDB, Other).
If you are having problems, you can enable internal debug messages via
the ``-d'' option.
-Also it is possible to interleave commands w/config scripts using the
+Also it is possible to interleave JIM-Tcl commands w/config scripts using the
@option{-c} command line switch.
To enable debug output (when reporting problems or working on OpenOCD
@@ -808,7 +852,7 @@ single directory for your work with a gi
When you start OpenOCD from that directory,
it searches there first for configuration files
and for code you upload to the target board.
-It is also be the natural place to write files,
+It is also the natural place to write files,
such as log files and data you download from the board.
@section Configuration Basics
@@ -848,7 +892,7 @@ openocd -f interface/signalyzer.cfg \
You could wrap such long command lines in shell scripts,
each supporting a different development task.
-One might re-flash the board with specific firmware version.
+One might re-flash the board with a specific firmware version.
Another might set up a particular debugging or run-time environment.
Here we will focus on the simpler solution: one user config
@@ -1456,42 +1500,6 @@ Examples:
@item pxa270 - again - CS0 flash - it goes in the board file.
@end itemize
-...@node About JIM-Tcl
-...@chapter About JIM-Tcl
-...@cindex JIM Tcl
-...@cindex tcl
-
-OpenOCD includes a small ``TCL Interpreter'' known as JIM-TCL. You can
-learn more about JIM here: @url{http://jim.berlios.de}
-
-...@itemize @bullet
-...@item @b{JIM vs. Tcl}
-...@* JIM-TCL is a stripped down version of the well known Tcl language,
-which can be found here: @url{http://www.tcl.tk}. JIM-Tcl has far
-fewer features. JIM-Tcl is a single .C file and a single .H file and
-impliments the basic Tcl command set along. In con
[Openocd-development] [patch 1/2] openocd.texi - board+target configfile updates
This should be my last significant update of the User's Guide for
this release. Mostly it's a rework of the config file chapter's
presentation of board and target config files.
- Give the new path for scripts!
- Move board-config material out of the target-config section
- Add more board-config info, notably for reset-init events
- Link out of the board-config section to NAND, NOR, and Reset chapters
- Emphasize target input vs. output naming conventions
- Other textual improvements
Plus some other updates, like adding my copyright (now that I've
basically rewritten much of this).
---
doc/openocd.texi | 357 ++---
1 file changed, 232 insertions(+), 125 deletions(-)
This should be my last significant update of the User's Guide for
this release. Mostly it's a rework of the config file chapter's
presentation of board and target config files.
- Give the new path for scripts!
- Move board-config material out of the target-config section
- Add more board-config info, notably for reset-init events
- Link out of the board-config section to NAND, NOR, and Reset chapters
- Emphasize target input vs. output naming conventions
- Other textual improvements
Plus some other updates, like adding my copyright (now that I've
basically rewritten much of this).
---
doc/openocd.texi | 357 ++---
1 file changed, 232 insertions(+), 125 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -23,6 +23,7 @@ of the Open On-Chip Debugger (OpenOCD).
@item Copyright @copyright{} 2007-2008 Spencer Oliver @email{spen@@spen-soft.co.uk}
@item Copyright @copyright{} 2008 Oyvind Harboe @email{oyvind.harboe@@zylin.com}
@item Copyright @copyright{} 2008 Duane Ellis @email{openocd@@duaneellis.com}
+...@item Copyright @copyright{} 2009 David Brownell
@end itemize
@quotation
@@ -943,6 +944,10 @@ its @command{xscale vector_catch} siblin
during some debug sessions, but don't make everyone use that either.
Keep those kinds of debugging aids in your user config file.
+TCP/IP port configuration is another example of something which
+is environment-specific, and should only appear in
+a user config file. @xref{TCP/IP Ports}.
+
@section Project-Specific Utilities
A few project-specific utility
@@ -1015,21 +1020,21 @@ including developers and integrators of
needs to get a new board working smoothly.
It provides guidelines for creating those files.
-You should find the following directories under @t{$(INSTALLDIR)/lib/openocd} :
+You should find the following directories under @t{$(INSTALLDIR)/scripts}:
@itemize @bullet
-...@item @b{interface}
-...@*think JTAG Dongle. Files that configure the JTAG dongle go here.
-...@item @b{board}
-...@* Think Circuit Board, PWA, PCB, they go by many names. Board files
-contain initialization items that are specific to a board - for
-example: The SDRAM initialization sequence for the board, or the type
-of external flash and what address it is found at. Any initialization
+...@item @file{interface} ...
+think JTAG Dongle. Files that configure JTAG adapters go here.
+...@item @file{board} ...
+think Circuit Board, PWA, PCB, they go by many names. Board files
+contain initialization items that are specific to a board. For
+example, the SDRAM initialization sequence for the board, or the type
+of external flash and what address it uses. Any initialization
sequence to enable that external flash or SDRAM should be found in the
-board file. Boards may also contain multiple targets, i.e.: Two CPUs, or
+board file. Boards may also contain multiple targets: two CPUs; or
a CPU and an FPGA or CPLD.
-...@item @b{target}
-...@* Think chip. The ``target'' directory represents the JTAG TAPs
+...@item @file{target} ...
+think chip. The ``target'' directory represents the JTAG TAPs
on a chip
which OpenOCD should control, not a board. Two common types of targets
are ARM chips and FPGA or CPLD chips.
@@ -1045,7 +1050,7 @@ commands specific to their situation.
@section Interface Config Files
The user config file
-should be able to source one of these files via a command like this:
+should be able to source one of these files with a command like this:
@example
source [find interface/FOOBAR.cfg]
@@ -1060,179 +1065,250 @@ A separate chapter gives information abo
Read the OpenOCD source code if you have a new kind of hardware interface
and need to provide a driver for it.
-Interface files should be found in @t{$(INSTALLDIR)/lib/openocd/interface}
-
@section Board Config Files
@cindex config file, board
@cindex board config file
The user config file
-should be able to source one of these files via a command like this:
+should be able to source one of these files with a command like this:
@example
source [find board/FOOBAR.cfg]
@end example
-The board config file should contain one or more @command{source [find
-target/FOO.cfg]} statements along with any board spe
Re: [Openocd-development] FT2232 & Windows - summary of options
>> Øyvind mentioned the idea of wrapping the JTAG API in TCP/IP. Aside >> from performance implications I think this would require some >> significant development efforts with little immediate benefits. Even >> worse, it would encourage other JTAG interface vendors to implement >> their JTAG interface layer as a binary only driver that talks to the >> OpenOCD via TCP/IP layer, too. > >I am opposed to this as well, for the same reasons. This is why I did >not suggest it until someone else suggested it. I want to see libusb >and libfdti fixed, and I do not want to open the door to more binary >drivers. If I were to implement the TCP/IP interface without pay, I >would release it under the GPL to prevent this situation from ever >occurring. At this point, I am tempted to implement it simply in order >to close this back door to binary drivers. Zach, This sounds very contraproductive to me. You have been doing a lot of great work but if the maintainers of OpenOCD are not open for solutions that just work in a real world you'll find that people (JTAG dongle manufacturors for starters) will start to fork OpenOCD in seperate projects which results in various versions. That would be a waste of your efforts. I really fail to see the real world problem when mixing open and closed source parts. If you contribute to an open source project you know someone will make money with the software you wrote but didn't get paid for. So be it. Perhaps the best way is to link against the closed source driver until there is an open source alternative that works just as well. Closed source drivers are going to be a problem anyhow since getting a 64 bit Windows driver signed is not free. It is also becoming easier to write software that runs on both Linux and Windows. Therefore it is very likely that more open source projects will run into similar problems. So 'closing the door' may actually backfire in worse ways than you can imagine now. Maybe the GPL license has expired. Many bigger projects are published under other licenses like BSD, Mozilla, etc or even have dual licensing like MySQL. GPL 3 has seen a lot of debate before being finalized. Those are the real signs on the wall! Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
All - I believe - I am not sure - that the primary benefit of "libft2xxx" is as follows: (a) It is measurably faster. That just requires "work" to make it faster. (b) It works on more platforms, ie: Win7, WinVista, because drivers exist for those platforms. This is tough/hard, nobody on this list is a "windows driver developer". Grrr. Such is life. (c) Nobody was offering a universal "libusb" - type "INF" files for windows. Looks like Freddie Chopin is working on that :-) Perhaps - we could have a "contrib" folder with a *binary* libusb0.sys file and associated "INF" files that references *ALL* ftdi based dongles - (The VID/PID list is in the source file...) That *INF* file and matching SYS file should be deliverable with OpenOCD. (d) There is another choice - "WinUSB" http://msdn.microsoft.com/en-us/library/aa476426.aspx As I understand, it is a a multi-(windoze)-platform solution that exposes the USB device, functionally in the same manor and style as "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control commands. I believe there is the only open question that needs to be asked and answered. The MS-WinUSB driver - did not *ship* with WinXP, but is available as a "co-install" for WinXP. As I understand (I have not confirmed, and I do not know all the details of it), the driver and associated OS-libraries/headers are *PRESENT* on Vista, and I presume Win7 (with appropriate dev tools installed), therefore it functionally *SHIPS* with the operating system, and as such it sould fall under the standard operating system component exception to the GPL. This solution is - by design - something that can be added to WinXP (the co-install solution). I think of it sort of like this: "The old system only supplied a CDROM (read-only) driver" - later - new systems come with CD-WRITER (and today, we have CD-RW) - the *new* os does not require an upgrade, the *old* os has an upgrade path to make the CD-WRITER (and now CD-RW) work. I should - as a user of that old system - install the OS update - and be able to make use of that GPL software. All is not rosy and perfect, "WinUSB" would require an INF file that *points* to the driver - much like the work that Freddy is working towards with a universal libusb inf file Agree? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] target/ti_dm365.cfg
On Mon, Jun 22, 2009 at 8:25 PM, David Brownell wrote: > On Monday 22 June 2009, Ųyvind Harboe wrote: >> Committed. > > It's wrongly using DOS-style line endings ... Fixed. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
> Øyvind mentioned the idea of wrapping the JTAG API in TCP/IP. Aside from > performance implications I think this would require some significant > development efforts with little immediate benefits. Even worse, it would > encourage other JTAG interface vendors to implement their JTAG interface > layer as a binary only driver that talks to the OpenOCD via TCP/IP layer, > too. Just to be clear: my motivation for JTAG over TCP/IP has nothing to do with USB. I'm interested in it for the purposes of making targets available for testing remotely. Also one of the neat things of OpenOCD is that it has a clever scheme to avoid killing performance with long roundtrips, so performance of JTAG over TCP/IP should actually be usable if not great. I thought the USB discussion could somehow bring about JTAG over TCP/IP indirectly, which would be nice. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Add config for CS351x CPUs
On Sunday 21 June 2009, Øyvind Harboe wrote: > Committed. It's wrongly using DOS-style line endings ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] target/ti_dm365.cfg
On Monday 22 June 2009, Øyvind Harboe wrote: > Committed. It's wrongly using DOS-style line endings ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Mon, 2009-06-22 at 19:59 +0200, Dominic wrote: > Hi List, > > > > there has been some speculation about my original intents so I thought > I might chime in here. > > > > I'm all in favor of enforcing the GPL where it achieves anything for > the user. In case of FTD2XX I decided to go the pragmatic way instead > of the idealist's way. > > > > Why do we want to link against compatibly licensed libraries only? > Because we want to ensure the user's freedom to use our software and > his hardware on whatever platform he sees fit. Back then there was > libftdi, which allowed FTD2XX based interfaces to be used on Linux, > *BSD and so on. And we had FTD2XX which allowed the FTD2XX based > interface to be used on Windows, and which offered a significant > performance improvement on Linux (this has been solved? I remember > reading something about it on the list...). My point of view was that > we weren't restricting a user's freedom by allowing the use of FTD2XX. > Instead it made the OpenOCD accessible to a much greater audience. As > long as libftdi /could/ be made to do the same thing that FTD2XX does, > using information publicly available, I don't see an immediate need to > enforce seemingly arbitrary restrictions over our users. > > > > I wasn't aware of the possibility or need for license exceptions, and > I thought (IANAL... how I hate that acronym...) that if anyone, it > would take me to enforce the GPL terms. As I had no intend to enforce > the GPL over someone who linked against FTD2XX I figured everything > would be fine (I think I explicitly wrote that to Michael Fischer some > years ago). This may not have been the wisest of decisions but that's > how it is or rather was. Thank you for providing clarification of your original intention; however, you have only confirmed what was already clear: there has never been a formal exception to the GPL. Any arrangements were made informally and without modifying the GPL license itself. Even if your exception was published in a public forum, you will have a difficult time defending that it applies -- since the license was never modified in the tree. Øyvind Harboe, David Brownell, and myself are against any exceptions, so there can be no exception added to the license for the contributions that we have made. Your clarification appears to have no legal bearing on license for the current trunk: OpenOCD is pure GPL, and it always has been since it was created. > Øyvind mentioned the idea of wrapping the JTAG API in TCP/IP. Aside > from performance implications I think this would require some > significant development efforts with little immediate benefits. Even > worse, it would encourage other JTAG interface vendors to implement > their JTAG interface layer as a binary only driver that talks to the > OpenOCD via TCP/IP layer, too. I am opposed to this as well, for the same reasons. This is why I did not suggest it until someone else suggested it. I want to see libusb and libfdti fixed, and I do not want to open the door to more binary drivers. If I were to implement the TCP/IP interface without pay, I would release it under the GPL to prevent this situation from ever occurring. At this point, I am tempted to implement it simply in order to close this back door to binary drivers. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
Hi List, there has been some speculation about my original intents so I thought I might chime in here. I'm all in favor of enforcing the GPL where it achieves anything for the user. In case of FTD2XX I decided to go the pragmatic way instead of the idealist's way. Why do we want to link against compatibly licensed libraries only? Because we want to ensure the user's freedom to use our software and his hardware on whatever platform he sees fit. Back then there was libftdi, which allowed FTD2XX based interfaces to be used on Linux, *BSD and so on. And we had FTD2XX which allowed the FTD2XX based interface to be used on Windows, and which offered a significant performance improvement on Linux (this has been solved? I remember reading something about it on the list...). My point of view was that we weren't restricting a user's freedom by allowing the use of FTD2XX. Instead it made the OpenOCD accessible to a much greater audience. As long as libftdi /could/ be made to do the same thing that FTD2XX does, using information publicly available, I don't see an immediate need to enforce seemingly arbitrary restrictions over our users. I wasn't aware of the possibility or need for license exceptions, and I thought (IANAL... how I hate that acronym...) that if anyone, it would take me to enforce the GPL terms. As I had no intend to enforce the GPL over someone who linked against FTD2XX I figured everything would be fine (I think I explicitly wrote that to Michael Fischer some years ago). This may not have been the wisest of decisions but that's how it is or rather was. Øyvind mentioned the idea of wrapping the JTAG API in TCP/IP. Aside from performance implications I think this would require some significant development efforts with little immediate benefits. Even worse, it would encourage other JTAG interface vendors to implement their JTAG interface layer as a binary only driver that talks to the OpenOCD via TCP/IP layer, too. Best Regards, Dominic ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
Xiaofan Chen pisze:
In this case, I think you do not need the master entry. Please
try it again with the master entry deleted.
The master entry (the one without &MI00 and &MI01) is not necessary.
I attach a changed driver file.
4\/3!!
[Version]
Signature = "$Chicago$"
provider = %manufacturer%
DriverVer = 03/20/2007,0.1.12.1
CatalogFile = libusb-win32_ft2232_driver.cat
CatalogFile.NT = libusb-win32_ft2232_driver.cat
Class = LibUsbDevices
ClassGUID = {EB781AAF-9C70-4523-A5DF-642A87ECA567}
[ClassInstall]
AddReg=libusb_class_install_add_reg
[ClassInstall32]
AddReg=libusb_class_install_add_reg
[libusb_class_install_add_reg]
HKR"LibUSB-Win32 Devices"
HKR,,Icon,,"-20"
[Manufacturer]
%manufacturer%=Devices,NT
;--
; Files
;--
[SourceDisksNames]
1 = "Libusb-Win32 Driver Installation Disk",,
[SourceDisksFiles]
libusb0.sys = 1,,
libusb0.dll = 1,,
[DestinationDirs]
libusb_files_sys = 10,system32\drivers
libusb_files_dll = 10,system32
[libusb_files_sys]
libusb0.sys
[libusb_files_dll]
libusb0.dll
;--
; Device driver
;--
[LIBUSB_DEV]
CopyFiles = libusb_files_sys, libusb_files_dll
AddReg= libusb_add_reg
[LIBUSB_DEV.NT]
CopyFiles = libusb_files_sys, libusb_files_dll
[LIBUSB_DEV.HW]
DelReg = libusb_del_reg_hw
AddReg = libusb_add_reg_hw
[LIBUSB_DEV.NT.HW]
DelReg = libusb_del_reg_hw
AddReg = libusb_add_reg_hw
[LIBUSB_DEV.NT.Services]
AddService = libusb0, 0x0002, libusb_add_service
[libusb_add_reg]
HKR,,DevLoader,,*ntkern
HKR,,NTMPDriver,,libusb0.sys
; Older versions of this .inf file installed filter drivers. They are not
; needed any more and must be removed
[libusb_del_reg_hw]
HKR,,LowerFilters
HKR,,UpperFilters
; Device properties
[libusb_add_reg_hw]
HKR,,SurpriseRemovalOK, 0x00010001, 1
;--
; Services
;--
[libusb_add_service]
DisplayName= "LibUsb-Win32 - Kernel Driver 03/20/2007, 0.1.12.1"
ServiceType= 1
StartType = 3
ErrorControl = 0
ServiceBinary = %12%\libusb0.sys
;--
; Devices
;--
[Devices]
"FTDI FT2232 (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_6001&MI_00
"FTDI FT2232 (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_6001&MI_01
"Amontec JTAGkey (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_00
"Amontec JTAGkey (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_01
"egnite Turtelizer 2 (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_bdc8&MI_00
"egnite Turtelizer 2 (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_bdc8&MI_01
[Devices.NT]
"FTDI FT2232 (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_6001&MI_00
"FTDI FT2232 (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_6001&MI_01
"Amontec JTAGkey (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_00
"Amontec JTAGkey (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_01
"egnite Turtelizer 2 (Channel A)"=LIBUSB_DEV, USB\VID_0403&PID_bdc8&MI_00
"egnite Turtelizer 2 (Channel B)"=LIBUSB_DEV, USB\VID_0403&PID_bdc8&MI_01
;--
; Strings
;--
[Strings]
manufacturer = "Various"
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Mon, 2009-06-22 at 19:19 +0200, Harald Kipp wrote: > Øyvind Harboe wrote: > > On Mon, Jun 22, 2009 at 5:47 PM, Michael > > Schwingen wrote: > >> Harald Kipp wrote: > >>> This is easier to implement than what I suggested: Building an > >>> intermediate LGPL'ed DLL which links OpenOCD with FTD2XX. > >>> > >> I don't see how that solves the GPL problem: as soon as the FTD2XX > >> library is linked into openocd, it is not OK to distribute - having an > >> intermediate do the linking does not change the legal status, IMHO - but > >> IANAL. > > > > I'm not a GPL expert, but this still sounds like trying to circumvent the > > license problem and is no different than LoadLibrary() vs. implicit > > LoadLibrary(). > > Sorry for those convoluted language constructions. We Germans love to > create complicated sentences, although they typically lead to confusion. > > Simple version: > > 1. Someone creates a dummy FTD2XX library, published under LGPL. This > library does not contain any FTDI-code, just dummies which contain the > same entry names, but always return errors. > > 2. This library can be distributed with the OpenOCD executable, enabled > for FT2232 support. OpenOCD will run flawlessly, but of course not work > with Turtelizer 2 or similar hardware. It will work with other adapters. > > 3. The user can replace this dummy with the original libraries, > downloadable from FTDI's website. Now OpenOCD will work with FT2232 > based adapters. I believe this would be illegal circumvention of the GPL. For these kinds of machinations to be acceptable, the "dummy" library needs to actually function in a comparable manner; that would mean implementing a full wrapper for libftdi using the FTD2XX APIs. Otherwise, you would be distributing a binary version of OpenOCD for the express purpose of it being linked to the proprietary FTD2XX drivers. You really would not be doing anything different, and I would object strenuously to this approach. I seriously doubt it would be legal. As far as I am concerned, you are looking for a way to maintain your status quo, and I understand your desire to do so. Honestly, any form of working dummy library pisses me off, but there may be nothing that I can do about it (assuming it was done properly). Well, I suppose that I can state that I would never commit it to the repository myself. Regardless, your unwillingness to contribute to a good solution -- one that would be acceptable to its major contributors -- undermines my perception of your open source integrity and that of your business. Be advised: I am starting to visualize torches and pitchforks. I am actually surprised that no one has posted links to these threads on a popular aggregation site; this kind of situation is chum in the water for real GPL sharks. You will quickly find that I am very reasonable when compared to such extremists. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
David Brownell wrote: > On Monday 22 June 2009, Harald Kipp wrote: >> 1. Someone creates a dummy FTD2XX library, published under LGPL. This >> library does not contain any FTDI-code, just dummies which contain the >> same entry names, but always return errors. > > This is a transparent attempt to circumvent the GPL terms. > Among other things, it has no purpose *EXCEPT* to be an > aid in such circumvention. Do you mean this violates GPL? If yes, which part excatly? Harald P.S. Btw. pacbell net still rejects email from our company server, claiming that we are spamming. I can ensure you we are not. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] cleanup board/hitex_stm32-performancestick.cfg
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] target/ti_dm365.cfg
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf fileforwindows/libusb-win32
Gene Smith pisze:
> How do I add olimex-arm-usb-ocd device to this inf? And once I have
> added it, how do you install the driver so it remains permanent (i.e.,
> survives a winXP reboot)?
Just copy the entries for Turtelizer of JTAGkey and change the
description and VID/PID combinations. Add that to [Devices] and
[Devices.NT] group
"Amontec JTAGkey ( Channel A )"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_00
"Amontec JTAGkey ( Channel B )"=LIBUSB_DEV, USB\VID_0403&PID_cff8&MI_01
Change the name: "Amontec JTAGkey ...", VID (here 0403) and PID (here cff8).
I have Windows 2003 Server Ent.Ed. so that info may not work for XP, but
there is a way to force some drivers when Windows prefers some other.
Gerenally the first question is Auto-install or manual install - of
course manual. Than you can give some path for SEARCHING or select the
other option ("don't search, I'll select myself" - or sth like that).
Than a list of preferred (past) drivers will show up, you select "From
disk" and seek the .inf file - this way I'm able to force any driver
that matches the device.
Maybe this will help you. Don't care too much about the "names" of
options / buttons I wrote above - I have Polish OS version, so I'm
trying to translate that to English.
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Monday 22 June 2009, Harald Kipp wrote: > 1. Someone creates a dummy FTD2XX library, published under LGPL. This > library does not contain any FTDI-code, just dummies which contain the > same entry names, but always return errors. This is a transparent attempt to circumvent the GPL terms. Among other things, it has no purpose *EXCEPT* to be an aid in such circumvention. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Mon, Jun 22, 2009 at 7:19 PM, Harald Kipp wrote: > Øyvind Harboe wrote: >> On Mon, Jun 22, 2009 at 5:47 PM, Michael >> Schwingen wrote: >>> Harald Kipp wrote: This is easier to implement than what I suggested: Building an intermediate LGPL'ed DLL which links OpenOCD with FTD2XX. >>> I don't see how that solves the GPL problem: as soon as the FTD2XX >>> library is linked into openocd, it is not OK to distribute - having an >>> intermediate do the linking does not change the legal status, IMHO - but >>> IANAL. >> >> I'm not a GPL expert, but this still sounds like trying to circumvent the >> license problem and is no different than LoadLibrary() vs. implicit >> LoadLibrary(). > > Sorry for those convoluted language constructions. We Germans love to > create complicated sentences, although they typically lead to confusion. > > Simple version: > > 1. Someone creates a dummy FTD2XX library, published under LGPL. This > library does not contain any FTDI-code, just dummies which contain the > same entry names, but always return errors. > > 2. This library can be distributed with the OpenOCD executable, enabled > for FT2232 support. OpenOCD will run flawlessly, but of course not work > with Turtelizer 2 or similar hardware. It will work with other adapters. > > 3. The user can replace this dummy with the original libraries, > downloadable from FTDI's website. Now OpenOCD will work with FT2232 > based adapters. I am not convinced this is robust license wiseand also I'm against it as a maintainer. I want to see a *generic* API to support *all* types of JTAG interface over any transport. This is the "JTAG over TCP/IP" scheme that can be generalized to work over any transport: TCP/IP, pipes, function calls, pigeons :-) I believe this will fly from a license point of view + give us lots of other benefits. It's not that hard to do, it's just work. Zach is aching for it, but he'd like to have fair compensation for his time to do so. Not unreasonable. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] target/ti_dm365.cfg
Target config file for newish DM365 chip. Think of this as
an improved DM355, integrating much better HD video support,
Ethernet, and other goodies.
---
tcl/target/ti_dm365.cfg | 97 ++
1 file changed, 97 insertions(+)
Target config file for newish DM365 chip. Think of this as
an improved DM355, integrating much better HD video support,
Ethernet, and other goodies.
---
tcl/target/ti_dm365.cfg | 97 ++
1 file changed, 97 insertions(+)
--- /dev/null
+++ b/tcl/target/ti_dm365.cfg
@@ -0,0 +1,97 @@
+#
+# Texas Instruments DaVinci family: TMS320DM365
+#
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
+ set _CHIPNAME dm365
+}
+
+#
+# For now, expect EMU0/EMU1 jumpered LOW (not TI's default) so ARM and ETB
+# are enabled without making ICEpick route ARM and ETB into the JTAG chain.
+#
+# Also note: when running without RTCK before the PLLs are set up, you
+# may need to slow the JTAG clock down quite a lot (under 2 MHz).
+#
+source [find target/icepick.cfg]
+set EMU01 "-enable"
+#set EMU01 "-disable"
+
+# Subsidiary TAP: ARM ETB11, with scan chain for 4K of ETM trace buffer
+if { [info exists ETB_TAPID ] } {
+ set _ETB_TAPID $ETB_TAPID
+} else {
+ set _ETB_TAPID 0x2b900f0f
+}
+jtag newtap $_CHIPNAME etb -irlen 4 -ircapture 0x1 -irmask 0xf \
+ -expected-id $_ETB_TAPID $EMU01
+jtag configure $_CHIPNAME.etb -event tap-enable \
+ "icepick_c_tapenable $_CHIPNAME.jrc 1"
+
+# Subsidiary TAP: ARM926ejs with scan chains for ARM Debug, EmbeddedICE-RT, ETM.
+if { [info exists CPU_TAPID ] } {
+ set _CPU_TAPID $CPU_TAPID
+} else {
+ set _CPU_TAPID 0x0792602f
+}
+jtag newtap $_CHIPNAME arm -irlen 4 -ircapture 0x1 -irmask 0xf \
+ -expected-id $_CPU_TAPID $EMU01
+jtag configure $_CHIPNAME.arm -event tap-enable \
+ "icepick_c_tapenable $_CHIPNAME.jrc 0"
+
+# Primary TAP: ICEpick (JTAG route controller) and boundary scan
+if { [info exists JRC_TAPID ] } {
+ set _JRC_TAPID $JRC_TAPID
+} else {
+ set _JRC_TAPID 0x0b83e02f
+}
+jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0x3f \
+ -expected-id $_JRC_TAPID
+
+
+
+# various symbol definitions, to avoid hard-wiring addresses
+# and enable some sharing of DaVinci-family utility code
+global dm365
+set dm365 [ dict create ]
+
+# Physical addresses for controllers and memory
+# (Some of these are valid for many DaVinci family chips)
+dict set dm365 sram0 0x0001
+dict set dm365 sram1 0x00014000
+dict set dm365 sysbase 0x01c4
+dict set dm365 pllc1 0x01c40800
+dict set dm365 pllc2 0x01c40c00
+dict set dm365 psc 0x01c41000
+dict set dm365 gpio 0x01c67000
+dict set dm365 a_emif 0x01d1
+dict set dm365 a_emif_cs0 0x0200
+dict set dm365 a_emif_cs1 0x0400
+dict set dm365 ddr_emif 0x2000
+dict set dm365 ddr 0x8000
+
+source [find target/davinci.cfg]
+
+
+# GDB target: the ARM, using SRAM1 for scratch. SRAM0 (also 16K)
+# and the ETB memory (4K) are other options, while trace is unused.
+set _TARGETNAME $_CHIPNAME.arm
+
+target create $_TARGETNAME arm926ejs -chain-position $_TARGETNAME
+
+# NOTE that work-area-virt presumes a Linux 2.6.30-rc2+ kernel,
+# and that the work area is used only with a kernel mmu context ...
+$_TARGETNAME configure \
+ -work-area-virt [expr 0xfffe + 0x4000] \
+ -work-area-phys [dict get $dm365 sram1] \
+ -work-area-size 0x4000 \
+ -work-area-backup 0
+
+arm7_9 dbgrq enable
+arm7_9 fast_memory_access enable
+arm7_9 dcc_downloads enable
+
+# trace setup
+etm config $_TARGETNAME 16 normal full etb
+etb config $_TARGETNAME $_CHIPNAME.etb
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
Øyvind Harboe wrote: > On Mon, Jun 22, 2009 at 5:47 PM, Michael > Schwingen wrote: >> Harald Kipp wrote: >>> This is easier to implement than what I suggested: Building an >>> intermediate LGPL'ed DLL which links OpenOCD with FTD2XX. >>> >> I don't see how that solves the GPL problem: as soon as the FTD2XX >> library is linked into openocd, it is not OK to distribute - having an >> intermediate do the linking does not change the legal status, IMHO - but >> IANAL. > > I'm not a GPL expert, but this still sounds like trying to circumvent the > license problem and is no different than LoadLibrary() vs. implicit > LoadLibrary(). Sorry for those convoluted language constructions. We Germans love to create complicated sentences, although they typically lead to confusion. Simple version: 1. Someone creates a dummy FTD2XX library, published under LGPL. This library does not contain any FTDI-code, just dummies which contain the same entry names, but always return errors. 2. This library can be distributed with the OpenOCD executable, enabled for FT2232 support. OpenOCD will run flawlessly, but of course not work with Turtelizer 2 or similar hardware. It will work with other adapters. 3. The user can replace this dummy with the original libraries, downloadable from FTDI's website. Now OpenOCD will work with FT2232 based adapters. Harald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Mon, Jun 22, 2009 at 7:09 PM, Michael Schwingen wrote: > Øyvind Harboe wrote: >>> As far as I see the situationn, the only clean possibility (except >>> changing the license) is to have the FTD2XX library in a separate >>> process, not linked into openocd's address space, which means separating >>> the functionality and communicating by sockets or similar mechanisms. >>> >> >> I'm not a GPL expert, but this still sounds like trying to circumvent the >> license problem and is no different than LoadLibrary() vs. implicit >> LoadLibrary(). >> > If you simply wrap FTD2XX calls in network packets, then I agree. > > If the protocol used is more general and not FTD2XX-specific, it should > be OK, especially if multiple implementations for different targets exist. My favourite is to introduce a serialized protocol for JTAG that can work over TCP/IP, pipes, even fn calls... This has been discussed before and could be *very* useful for other stuff, including remote access to targets for debug purposes... OpenOCD would itself also implement this as a server to forwarding it to the underlying driver, acting as the server. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf fileforwindows/libusb-win32
Michael Fischer wrote: > Hello List, > > here is the driver which was build from the SVN r161 (libusb). > Please test it, it should work with composite devices too. > > The zip contains the driver for the "user". The library > is the new one which was create by the build process. > > I have removed all 64 bit stuff from the inf file. > In the moment only the JTAGkey and the Turtelizer was added. > > Best regards, > > Michael How do I add olimex-arm-usb-ocd device to this inf? And once I have added it, how do you install the driver so it remains permanent (i.e., survives a winXP reboot)? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] cleanup board/hitex_stm32-performancestick.cfg
Make the Hitex STM32-PerformanceStick board config behave better:
source the STM32 target config instead of using a private clone.
The same should evidently be done with the STR750 chip on this
board, but the str750.cfg looks like quite a mess ... I'm not
sure which board it's expecting, but it's likely not this one.
---
tcl/board/hitex_stm32-performancestick.cfg | 47 +--
1 file changed, 3 insertions(+), 44 deletions(-)
NOTE: not tested, I don't have this hardware.
Make the Hitex STM32-PerformanceStick board config behave better:
source the STM32 target config instead of using a private clone.
The same should evidently be done with the STR750 chip on this
board, but the str750.cfg looks like quite a mess ... I'm not
sure which board it's expecting, but it's likely not this one.
---
tcl/board/hitex_stm32-performancestick.cfg | 47 +--
1 file changed, 3 insertions(+), 44 deletions(-)
--- a/tcl/board/hitex_stm32-performancestick.cfg
+++ b/tcl/board/hitex_stm32-performancestick.cfg
@@ -1,50 +1,9 @@
# Hitex stm32 performance stick
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
- set _CHIPNAME stm32_hitex
-}
-
-if { [info exists ENDIAN] } {
- set _ENDIAN $ENDIAN
-} else {
- set _ENDIAN little
-}
-
-# set jtag speed
-jtag_khz 500
-
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst
-
-#jtag scan chain
-# The CPU
-if { [info exists CPUTAPID ] } {
- set _CPUTAPID $CPUTAPID
-} else {
- # See STM Document RM0008
- # Section 26.6.3
- set _CPUTAPID 0x3ba00477
-}
-jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
-
-# The boundery scan register, leave the "expected-id" undefined.
-jtag newtap $_CHIPNAME bs -irlen 5 -ircapture 0x1 -irmask 0x1
+set CHIPNAME stm32_hitex
+source [find target/stm32.cfg]
# configure str750 connected to jtag chain
+# FIXME -- source [find target/str750.cfg] after cleaning that up
jtag newtap $_CHIPNAME unknown -irlen 4 -ircapture 0x1 -irmask 0x0f
-set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
-target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position $_TARGETNAME
-
-$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x2000 -work-area-size 16384 -work-area-backup 0
-
-#
-flash bank stm32x 0 0 0 0 0
-
-# For more information about the configuration files, take a look at:
-# openocd.texi
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
Øyvind Harboe wrote: >> As far as I see the situationn, the only clean possibility (except >> changing the license) is to have the FTD2XX library in a separate >> process, not linked into openocd's address space, which means separating >> the functionality and communicating by sockets or similar mechanisms. >> > > I'm not a GPL expert, but this still sounds like trying to circumvent the > license problem and is no different than LoadLibrary() vs. implicit > LoadLibrary(). > If you simply wrap FTD2XX calls in network packets, then I agree. If the protocol used is more general and not FTD2XX-specific, it should be OK, especially if multiple implementations for different targets exist. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
On Mon, Jun 22, 2009 at 5:47 PM, Michael Schwingen wrote: > Harald Kipp wrote: >> This is easier to implement than what I suggested: Building an >> intermediate LGPL'ed DLL which links OpenOCD with FTD2XX. >> > I don't see how that solves the GPL problem: as soon as the FTD2XX > library is linked into openocd, it is not OK to distribute - having an > intermediate do the linking does not change the legal status, IMHO - but > IANAL. > > As far as I see the situationn, the only clean possibility (except > changing the license) is to have the FTD2XX library in a separate > process, not linked into openocd's address space, which means separating > the functionality and communicating by sockets or similar mechanisms. I'm not a GPL expert, but this still sounds like trying to circumvent the license problem and is no different than LoadLibrary() vs. implicit LoadLibrary(). There are technical solutions to these GPL problems that are a bit of work, but not terribly hard. I think a good first step would be to accumulate possible solutions and commit them to todo.txt after there is a consensus that they are workable from a license point of view. Once we have a list of GPL-safe solutions, patches can flow -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
Xiaofan Chen wrote: > > Have you tried the following method? > > Run cmd.exe as admin (under Vista) and > D:\libusb-win32-device-bin-0.1.12.1\bin>c:\windows\sys tem32\rundll32 > libusb0.dll,usb_install_driver_np_rundll olimex.inf > Unfortunately, at least on my XP setup, this does not survive a reboot. When I plug in USB after a reboot, it asks me again to install the proprietary olimex drivers from CD and the libusb-win32 driver does not appear in hardware mgr. If I redo the above command libusb driver comes back and XP stops asking me to install drivers on usb pull/plug (until the next reboot). As I mentioned before, installing the libusb driver with the "update driver" right click dialogs never works for me. If it did, maybe it would be permanent? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
Harald Kipp wrote: > This is easier to implement than what I suggested: Building an > intermediate LGPL'ed DLL which links OpenOCD with FTD2XX. > I don't see how that solves the GPL problem: as soon as the FTD2XX library is linked into openocd, it is not OK to distribute - having an intermediate do the linking does not change the legal status, IMHO - but IANAL. As far as I see the situationn, the only clean possibility (except changing the license) is to have the FTD2XX library in a separate process, not linked into openocd's address space, which means separating the functionality and communicating by sockets or similar mechanisms. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cygwin bootstrap problem, r2350
On Mon, Jun 22, 2009 at 5:32 PM, Timothy Clacy wrote: > > Any suggestions for getting past this bootstrap problem? > > > $ ./bootstrap > + aclocal > + libtoolize --automake --copy > + autoconf > /usr/bin/m4:configure.in:432: cannot create temporary file for > diversion: Permission denied > autom4te-2.63: /usr/bin/m4 failed with exit status: 1 > Bootstrap complete; you can './configure --enable-maintainer-mode ' 1. delete c:\cygwin 2. reinstall cygwin 3. and try again > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cygwin bootstrap problem, r2350
Any suggestions for getting past this bootstrap problem? $ ./bootstrap + aclocal + libtoolize --automake --copy + autoconf /usr/bin/m4:configure.in:432: cannot create temporary file for diversion: Permission denied autom4te-2.63: /usr/bin/m4 failed with exit status: 1 Bootstrap complete; you can './configure --enable-maintainer-mode ' ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
Xiaofan Chen wrote: > > No. By using libusb-win32 device driver as the driver for > the Olimex device instead of FTDI driver, you will lost the > serial port. Maybe I was not understanding. I think you are really saying that there is *no way* to have the serial port *and* the jtag running together on windows with the free drivers. (This is also the impression I got from reading all the GPL discussions.) I thought you were originally explaining a way to have both. Again, thanks for helping me. -gene ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
Orin Eman wrote: > All someone need do is produce a DLL that is called FTD2XX and implements > (or plans to implement) all the interfaces that OpenOCD uses and release it > under LGPL. The interfaces can all return failure for now. There would be > no problem whatsoever releasing a binary linked against such > a 'replacement' DLL... If the user choses to delete the replacement DLL and > use FTDI's version, that's their choice. This is easier to implement than what I suggested: Building an intermediate LGPL'ed DLL which links OpenOCD with FTD2XX. IMHO, best solution so far. Harald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
Duane Ellis wrote: > We as a group, perhaps may not like this fact, but it is what it is. I > can not change that original exception, nor can anyone else. It was part > of the deal when each of us started to contribute to OpenOCD. Good argument against the repeated phrase "I wouldn't have contributed if...". Anyway, if the GPL purists see a chance to fight against proprietary software, they are in a good position. There is even a vague possibility to get your view granted in a legal dispute, but IMHO this is most unlikely. We either need a written GPL exception explicitly granted by all contributors or a clear statement of at least one of them, that they don't want this simply because they are in the position to say so. Without "I wouldn't have contributed if...". Harald P.S.: This discussion about free software reminds me of Brian: "Excuse me. Are you the Judean People's Front?" Reg: "Fuck off! We're the People's Front of Judea." ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Zach Welch wrote: > Thank you for taking the time to participate in this discussion. Zach, thank you for taking the time to respond to my lengthy explanations. I'll try to make it short now. :-) > I think you need to get legal counsel to confirm your point; I believe > this case is no different than the GPL. AFAICT, you must distribute the > source to the library, which cannot be done legally with the FTD2XX > library. You end up in the same place as we find ourselves now with the > GPL, with a new library that tries to obfuscate this fact. You definitely cannot do this, if... 1. The driver is distributed with OpenOCD. 2. The executable fails to work without the driver included. Both items are not required, because... 1. Windows users can easily install FTD2XX separately. 2. The same executable continues to work with other interfaces. The intermediate LGPL library can use LoadLibrary and GetProcAddress to dynamically link to FTD2XX, without crashing OpenOCD, if FTDI DLLs are not available. IMHO, it could be done this way by OpenOCD directly without violating GPL, but a number of contributors do not share this view and the LGPL part may not make its way into the official release. >> Referring to pure GPL: It explicitly allows exceptions and in reality >> there are many Open Source projects make use of this. > > But all copyright holders must agree to adding one. I do not. Fully understood and fully accepted. > OpenOCD binaries linked to FTD2XX drivers could never be distributed > legally, even if no one was called out on it until now. This is not > about attitude, other than compliance with the language of the license > in the manner which its authors intended. Just because of the language? C'mon...admit that there is at least a little breeze of attitude to win the fight against non-free software. ;-) >> I also understand, that many contributors (you, probably also Øyvind) do >> not care much about FTDI libraries, because they simply don't need them. > > I helped improve the high-speed patch for the FTD2XX driver, and I now > own a couple of FTDI-based interfaces. Furthermore, I have been > improving and maintaining all of the code in the tree, regardless of > whether or not I will ever have the related hardware. Judging only by > the number of patches, I care about this code more than you do. ;) Oops, I should have checked the contribs before making this statement. I'm sorry. > Let me say it again. As far as I can tell, no one has ever had the > legal right to distribute OpenOCD binaries with FTD2XX support included > in them, and it is only by the good graces of the existing copyright > holders that violators are not being held accountable with consequences. > In this way, that driver has never been a viable commercial solution. In fact we should have checked the legal situation before starting to sell Turtelizer 2. All problems we have now are definitely our own fault. Anyway, I must try to solve this for our customers and my company in the most economic way. > Developers exist that would be happy to solve these problems for you,* > or you could contribute the required patches yourself. The limitations > of libusb+libftdi are solvable, because the FTD2XX drivers have solved > all of them (or they would not be limitations). You just need to hire > someone that realizes this fact and will do the required work to reach > functional parity; the same goes with libusb support for the secondary > UART on those chips. Probably more than 50% of work done in my company is for Open Source projects under different licenses, including GPL. And, like other companies that focus on Open Source as a successful business model, we do hire external resources for this work as well. In this special case, however, I think, that the effort to add the missing parts to libftdi (RS-232 port plus Vista 64 support) may be to big for us. It may work as a unique feature for the Turtelizer to push its sales, but it will not work in competition with other vendors taking the benefit from our investment. Simply because the Turtelizer is not one of our main products. > I hope that you chose to continue to support the OpenOCD project, but > that does mean abiding by the terms of the GPL. To this end, I want you > to ask this chip vendor to release their library under the LGPL. As > their customer, you should have both a channel and some amount of > leverage to help the open source community accomplish this goal. Of course, we have to investigate all options. Before designing the Turtelizer 2 we intended to buy an alternative solution from Amontec first, which failed because of their prices at that time. Today they are much cheaper. Laurent faces the same problem and FTDI programmers are part of his main business. So one of my hopes is, that he will come up with a solution, which also fits our needs. > I hope everyone thinks this is the absolutely "best solution." It makes > me wonder what would h
Re: [Openocd-development] FT2232 & Windows - summary of options
2009/6/22 Nico Coesel : > As far as I can understand the problem is that OpenOCD > cannot be distributed as a Windows binary linked against a > USB device driver which is non-GPL code. This makes me wonder > how the executable is to be run on Windows. Somewhere the code > must be linked against Microsoft's APIs which are non-GPL as well. > So what is the difference between a non-GPL USB device driver and > the Windows APIs? According to Zach the GPL chain extends up and > down infinitely but I don't think that is the case. So it seems there are > some (practical) boundaries to GPL after all. > David Brownell answered before that there is a system library exception in GPL. Those Windows OS core components are installed along with Windows. That is why you can have GPL software running under Windows (or other non-GPL OS). http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs The FTDI driver/DLL may not be considered as system library according to David even though there is a gray area that they can be installed using Windows Updates (but may not be for the JTAG debuggers with custom VID/PID combinations). -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
> -Original Message- > From: openocd-development-boun...@lists.berlios.de [mailto:openocd- > development-boun...@lists.berlios.de] On Behalf Of Xiaofan Chen > Sent: maandag 22 juni 2009 1:59 > To: Zach Welch > Cc: openocd-development@lists.berlios.de > Subject: Re: [Openocd-development] FT2232 & Windows - summary of options > > 2009/6/22 Zach Welch : > > On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote: > >> On Sunday 21 June 2009, Audrius Urmanavičius wrote: > >> > I can also second Xiaofan, who offers distribution of .zip file with > >> > Cygwin building environment set up, probably with shell script that > >> > does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make` > >> > there, so that Windows users with (almost) no linux experience could > >> > build openocd themselves in minutes. > >> > >> I can't see any particular issue with such a "build kit". > >> Of course it shouldn't include binaries of any kind. > >> > >> It should however be exactly equivalent to carefully > >> written build instructions that include fetching the > >> source (maybe both "release 0.2.0" or "SVN-head" options) > >> and libraries. > > > > Finally!! Someone came up with one of the legal workarounds! > > > > A build script can be distributed that automatically fetches every > > single component (including the compilers, if necessary) and builds all > > of the source code from scratch. This doesn't sound like a viable option. Way too complicated. Like others said: you really don't want this mailing list flooded with questions about installing OpenOCD. I must say there are very few questions about the installation op OpenOCD. This indicates the current installation process and documentation are fine. Lets not change that. > > This is simply a matter of doing the work, but I have done this for past > > projects for exactly these same reasons. This may seem like extra work, > > but the resulting distribution complies with the terms of the GPL. > > > > If we had fully modular drivers, it would even be possible to distribute > > a build kit that compiles _only_ the FTD2XX driver, which can be > > installed into OpenOCD's (forthcoming) driver module directory. > > > > Glad to heat that build-kit idea is acceptable by GPL and you two. > Cygwin is not small. So it is good to distribute is as a zip file. > The a shell script to fetch OpenOCD and FTD2XX driver > and build OpenOCD can be put in to automatic the job. As far as I can understand the problem is that OpenOCD cannot be distributed as a Windows binary linked against a USB device driver which is non-GPL code. This makes me wonder how the executable is to be run on Windows. Somewhere the code must be linked against Microsoft's APIs which are non-GPL as well. So what is the difference between a non-GPL USB device driver and the Windows APIs? According to Zach the GPL chain extends up and down infinitely but I don't think that is the case. So it seems there are some (practical) boundaries to GPL after all. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 & Windows - summary of options
Freddie Chopin wrote: > >> You are spreading FUD. Please. Stop. Now. >> > > Why? You - on the other hand - are all "that violates GPL, period", so > you're spreading "GPL-or-die". Please. Stop. Now. Any realistic solution > is "violating the GPL" according to you, that's a pure "No, because > that's what I say" attitude. > No, I think he is correct. The license is as it is, and proposing ways to violate or circumvent that license is not productive, so don't expect the developers who chose that license to support you in circumventing it. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
