Re: [Openocd-development] Dynamic library loading
Hello David, David Brownell napsal(a): > And that's why GPL restricts distribution of GPL > software with non-Free libraries. If it didn't, > then the users relying on the non-Free code would > not have the full set of Freedoms intended by GPL. however, here we speak about distributing binary WITHOUT non-free library. A binary which does not depend on a non-free library. If there is a free option compiled in, such binary may be used without non-free driver and thus user has CHOICE to use free or non-free driver. There is nothing wrong in distributing binary compiled for a non-free CPU (a core not released under GPL) so with all the respect to GPL, I do not understand why is it wrong to distribute binary having (beside others) just SUPPORT for a non-free hw? Another matter is a binary dependent on a non-free library, but this is not the case. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Harald Kipp napsal(a): >>> AFAIK, adding support for a non-compliant DLL in GPL code is not >>> circumventing any GPL clause that I know of, neither directly not >>> indirectly. >> so is your belief that it is GPL compliant to also distribute >> GPLed binary that includes support for a closed DLL which is actually >> not required to use the binary, as there is a free alternative compiled >> in? (e.g. bitbang parallel port driver or libtfdi support) > > Exactly. > > At my current state of knowledge I'd have no problem to distribute such > a binary, _without_ FTD2XX libraries, of course. Thank you, Harald, this is what I was pointing at in my previous posts: find the real meaning, the original idea of GPL and defend that, not some disputable literal interpretation. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [windows + openocd] GPL implementation of libd2xx.dll ?
Hello Zach, Zach Welch napsal(a): > On Fri, 2009-06-26 at 00:21 +0159, Maciej Grela wrote: >> A friend of mine pointed me to the threads concerning >> GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an >> idea came to my head - what if we implement our own GPL/LGPL version >> of libd2xx.dll ? > [snip] > > My concern would be that you would be using a proprietary ABI. > The same idea was suggested, but using the libftdi ABI instead. > So, I am against the first (it's gray!) but can accept the second. What is wrong about adopting existing ABI, especially when it is designed to talk to a proprietary hw anyway? Whether we use former or latter, OpenOCD would still talk to a proprietary solution and that piece of code cannot be used for anything else. No offense but isn't this sort of GPL madness? It seems to me there is no significant difference which interface we use, but using fd2xx bring one benefit - no necessity to maintain "ftd2xx shim" in addition to its free libftdi reimplementation. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx -> libftdi
Hello Zach and the list, Zach Welch napsal(a): > If we are pursuing all of these at one time, our collective resources > are not being used efficiently. It's nice to see all the activity, but > I think we could make more productive use of our collective time. Now, > I am *not* asking anyone to change what they are doing, but "what if" > _everyone_ just buckles down and focuses on fixing libusb and libftdi? > > As I said at the start of all of this, this option seems like the best > use of the community's resources: This path is IMHO very far from best solution, remember that FTDI chips evolve, there are several variants on the market today. Is it really a good idea to maintain compatibility with future chips? Is this not exactly the task for a device driver? Be the answer yes or no (I assume yes) this is definitely not a task for OpenOCD itself. FTDI delivers a solution which is so popular _mainly_ for the fact that it is easy to use without necessity to implement low level USB stuff. Maintaining a driver for hw solution which is still _closed_ and noone knows for how long it will be produced is _totally_pointless_ - especially when speaking about long term solution. Moreover FTDI is not the only USB chip in the world. And finally libusb is a hack which moves driver to userspace, and it may be necessary to digitally sign it (Windows). Who is going to pay for a signing certificate? If we want OpenOCD to support various JTAG interfaces, even commercial ones (I see no problem in that, it is the same as buying computer hardware) the _only_ option is to create a _single_standard_ interface between OpenOCD and JTAG hw driver. I see support for commercially sold JTAG interfaces as very good thing, it brings to the community those people who prefer having professional JTAG interface over soldering together some free circuitry. So if this has to happen I vote for vendor neutral solution: a) adding "controlled interface" http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface which is probably legally complitated b) use suitable communication method like sockets, may be easily built on top of bitq.c > (a) It will be the best contribution to the free software community. And even better contribution to FTDI - why shall we prefer any single manufacturer? > Developers: are there others that want to follow this same path? For myself - no. 1> Distributors: do you want to deliver this solution to your users, if not > today then someday? Again, not all JTAG interafaces which may be potentially used woth OpenOCD have to be built using FTDI. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Hello Harald and the list, Harald Kipp napsal(a): > It's perfectly legitimate to _distribute_ a *GPL compliant* DLL with > GPL'ed executables. > > It's perfectly legitimate to _run_ a *non GPL compliant* DLL with GPL'ed > executables. The intention of GPL is to explicitly give users the > freedom to use GPL software in any way they see fit. > >> Transparent attempts at circumventing GPL lie down this >> same path, so keep your eyes peeled :-) > > AFAIK, adding support for a non-compliant DLL in GPL code is not > circumventing any GPL clause that I know of, neither directly not > indirectly. so is your belief that it is GPL compliant to also distribute GPLed binary that includes support for a closed DLL which is actually not required to use the binary, as there is a free alternative compiled in? (e.g. bitbang parallel port driver or libtfdi support) Thank you for your opinion. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [windows + openocd] GPL implementation of libd2xx.dll ?
Hello Maciej, Maciej Grela napsal(a): > A friend of mine pointed me to the threads concerning > GPL/windows/building/libftdi/libusb/libd2xx. After reading all this an > idea came to my head - what if we implement our own GPL/LGPL version > of libd2xx.dll ? This is also an option, but there are problems mainly in maintainance of compatibility - these days there is more than just a single version of the chip while FTDI keeps compatible API - I am not sure whether the compatibility is maintained in the driver or the DLL but I experienced a situation after driver update that different versions of driver and DLL are not necessarily compatible. > From my investigation it seems, that the driver does all the hard > work, the DLL itself just calls some ioctls. However, this is completely undocumented. > Also, the driver is the > only thing, that needs to be signed if I understand correctly. Yes, you are right. > Obviously, GPL code can communicate with drivers using system calls so > I don't suspect any traps. Correct, despite (as stated in my previous post) I really do not like the qualification of communication to "GPL allowed" and "GPL prohibited", GPL speaks so. > Also, Freddie, can I ask for more details about your performance > comparisons ? You've said, that libd2xx performs better than libftdi > but is this only under windows ? What is the speed difference between > libftdi + libusb under linux, libftdi + libusb under windows and > libd2xx + native windows driver ? I'm trying to figure out if the > windows driver does some magic to speed up the transfers or does > libusb suckiness on win32 cause it's inferior performance. The problem with libftdi used to be that it was not able to do async I/O operations, which meant that data was not read from the chip during writing larger block to it - this might cause buffer overflow. Because of that there had to be quick write/read turnarounds with small block sizes - what fits into the on-chip buffer. However when I looked into recent libftdi sources I assume this is no longer true, so the performance difference shall not be that significant these days - in theory. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FT2232 & Windows - license consideration
Hello Øyvind and the list, Øyvind Harboe napsal(a): > welcome back it's been a while! I hope that you'll stick around > to submit some more good patches. You've contributed lots of nice > stuff in the past! I am still here, monitoring the forum and I surely also do have future plans to contribute to OpenOCD in the future. > GPL stops closed source target & interface for OpenOCD. Sure, I understand that and I have to say I am not arguing about this. I like open source, it is just I really do not like if suddenly appears someone literally interpreting a legal document making a problem from something which has not been problem for years - I believed that ftd2xx.dll is linked "per design" by the will of the original author, giving me an impression that in such case it is not a license infringement. Anyway, as I noted in my post, it is better to (technically) solve this for good rather than argue forever, I suppose you see it the same way. But we shall not become GPL slaves, solving how to pass literal interpretation of the license instead of pushing OpenOCD further. > That's one of the *main* reasons I got involved with OpenOCD in the first > place. Actually me to, I am not for closed interfaces, and PRESTO is also open. The only closed thing is ftd2xx, a hw driver wrapper with rather trivial API which is mostly the same as OS file I/O API so the discussion about this seems to me a bit ridiculous. Open interface to FTDI chips does not make much sense without the chip itself, noone is going to implement a compatible silicon, that is why I consider ftd2xx as part of the hw and why I see the discussion pointless, bringing no real benefit to the project itself > I also knew that since the project was GPL to start with, it wouldn't > switch to another license once a sufficient # of contributors had signed > up. At least not without *everybody* agreeing to a license change. This > ensures that any license change won't be full of holes. Agreed. Too late, too complicated these days. > I *know* there are hardware vendors out there that > are aching to use OpenOCD together with closed source target support, > and they *would* find any tiny loophole and throw money at lawyers to > exploit it. Actually, this is not what I want. But I also do not like the silly madness about ftd2xx. BTW I like Linux, but what I really hate on it is lack of binary driver interface making many problems with hw compatibility - this is simply not the right way to do it, single word: interoperability. GPL does not mean the project shall not be able to communicate with non-free world and the attempt GPL made to classify "allowed" and "forbidden" ways of communication is far from ideal solution, neither does it guarantee freedom: binary communication over socket may be non-transparent in such a fashion that the code actually is not free (liberty) despite it is open. So this is what I was pointing at in my post: it is necessary to see the the principles of the license, its real meaning, so that we choose the right way, not just a technical workaround which passes the rules. > Now, I *know* you can fix these USB problems with both hands tied > behind your back in your sleep with a modest effort. The acceptable > solutions have been outlined. For sure it's a million times easier for > you to solve this technically than legally. You are right. > You stand out amongst the hardware vendors because you have made > *very* significant contributions in the past. Thank you very much. Personally I do no think it was such a big contribution. Without having the OpenOCD sources I would not have courage to start working on ARM JTAG debug solution, neither I have had time to program it from scratch. That is what I like on open source. Hopefully there will be more contribution from me (or us as company). > How about using the bitq stuff forl a generic JTAG over TCP/IP solution? ;-) Surely possible, but not much convenient, another process running on users computer, however, speed shall not be a big deal, probably a way to go. What I really would like is to separate all the JTAG logic from all low level drivers (if all drivers make use of bitbang or bitq). I am not sure about current status, I have not looked into recent source for an extensive period. On contrary, creating socket bitq interface would make it easier for vendors selling proprietary JTAG interfaces without giving any contribution, they would just implement the other side of the pipe. As you see every coin has two sides - implementing socket bitq would comply with literally interpreted GPL but at the same time, it would undermine its principles. Binary compatible libftdi->ftd2xx is also fine but opposite solution might be even more interesting: reimplement ftd2xx.dll using libftdi, giving a free solution also for other projects which use ftd2xx. In other words to take ftd2xx ABI as a standard and reimplement it to get fully free solution to fully comply with the licens
Re: [Openocd-development] FT2232 & Windows - summary of options
Hello list! Wookey napsal(a): > +++ Freddie Chopin [2009-06-24 16:56 +0200]: >> Important Qestion - Is OpenOCD meant for users to use, or just to be >> "100%-GPL-at-any-cost"? Good question! GPL is to bring free software to users, to support evolution of software, this is what was meant when the license was created. There may be many examples found when literal interpretation of legal documents does not end up with the aim of its author, some examples may be found in law. That is why there are courts and juries - otherwise a case could be decided by some robot or artificial intelligence. What I state here is not lack of respect to the license but what I ask for is to interpret GPL as it was meant, not in some kind of tendentious way. We have to understand the real sense and meaning of the license, its PURPOSE, not just read it as sequence of words - legal document is NOT a computer program so just don't read it like a compiler. > We need to just fix the problem for users (by getting a > licence-compatible USB driver for windows people who currently don't > have one). Here we go... ftd2xx is part of the driver, thus we may think about it as part of the hardware. OpenOCD, compared to other projects, is a bit specific in that it requires hw connectivity solution and there has to be a way to communicate with hw. If OpenOCD communicates with some driver backend over TCP, it would be 100% OK with literal interpretation of GPL. The question is: Would it make the code better in any sense? Would it make the code more free? (Remember GPL is about liberty.) I say no, this would not make any difference. This problem touches virtually any software using closed hw connectivity solution. An example: if I program an extension or connector (wrapper) for some closed library, which enables it to be conveniently used and I would like release the source to the public am I forbidden to use GPL license for my work just because it (by definition - as it is aim of the project) links to a closed library? Yes or no? Application for tweaking graphics card chip of certain manufacturer might be another example. No doubt that using LGPL would be a better choice, but again, am I forbidden to use GPL? In the light if the examples above: the project was started by Dominic Rath, and he included support ftd2xx. This is very important, because this was his choice - the choice of the only one author that day. Isn't it similar? OpenOCD links with ftd2xx "by definition" from the days the project was started. So ftd2xx was originally meant to be linked to OpenOCD, it was not added later. Dominic, please correct me, if I am wrong. Nevertheless it would be fine if this issue is finally fixed so that no more nitpickers could bother the community by reopening it. Please do not take the above as call for ignoring licensing issues, it is not meant like that, the point is: overinterpretting legal documents may lead to really absurd situations, this is what we have to bear in mind. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] first ftd2xx fix: documentation!
Hello Zach and the list, Zach Welch napsal(a): > It remains somewhat unclear to me exactly how badly distributors need to > see a solution today, when users (who are all developers, right?) should > be able to compile the code themselves and use the FTD2XX driver. I would like draw attention to this many times repeated misconception that all OpenOCD users are developers, which is definitely not true. Company I work for sells development tools including MCU/FLASH programmers. The praxis shows that significant part of the users ouf such products are amateurs, who just build a circuitry published on the Internet or in a magazine and all the are willing to do is to feed binary image of firmware into the device. They just download it and use a tool to flash it. And with no offense, some of these people are "dummies" when speaking about programming/development - there are many of them. OpenOCD is a solution which (with proper script) may be used for programming firmware into a device by a non-developer. I may also be used for production purposes this way. From this point of view the assupmtion that OpenOCD user == developer is simply wrong, this would exclude certain hobbists. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] LPC2148 JTAG Issues
Hello Peter and list, I might be looking into completely wrong direction in this case, but it is worth noting that when I was experimenting with LPC2148 with OpenOCD, If found out, that LPC needs reset pulled while RTCK is low. At least from what I've seen, it seemed to me that power-on reset is not sufficient for this. It might be that RTCK is latched upon reset, not sure about what is going on inside. Please have a look into the lpc2148.cfg, there is still note about this, but the following lines I have added jtag_reset 1 1 jtag_reset 0 0 are gone, I assume that it did not work for someone that way or influenced reset configuration etc. This was before JIM TCL integration, so I am not sure whether these to lines would still do the desired job. Please see following links: http://www.mail-archive.com/openocd-development@lists.berlios.de/msg00604.html http://www.embeddedrelated.com/groups/lpc2000/show/36295.php You may also try pulling reset by a jumper by hand before running OpenOCD, just experiment with this and let the list know about the results, please. Best regards, Pavel Peter LaDow napsal(a): > openocd-ftd2xx -d 3 -f interface/arm-usb-ocd.cfg -f target/lpc2148.cfg ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] LPC2k calc_checksum and mismatch during verify_image
Hello, > I'm not familiar with the calc_checksum option. Sounds strange to have > that built into the driver. I agree on this, but let's just leave the feature there - for users convenience. However, the preferred method shall be to externally calculate the checksum and embed it into the image. Despite it is surely possible to make some nasty workaround in OpneOCD, I do not see it as the right direction to go. Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] "reset run" is by default
Hello Spen, Spen napsal(a): >> Let's retire daemon_startup. It is completely equivalent to >> -c init -c "reset xxx" >> it only sows confusion. >> >> It is definitely not worth the backwards compatibility >> factor, especially for the grief that it will cause for new users. >> > My point is we discussed this a while back and not everybody wants to > remember a commandline - all they want todo is run openocd with a config. the same behavior can be achieved by adding init and reset commands as last two lines in the config script. I thought that concept of config files and commands given by parameters was clear: all that OpenOCD effectively does is a concatenation of all commands from -f and -c options and executes them one by one. I hope this is still true after Tcl integration. So there is no real inconvenience to the user caused by making daemon_startup deprecated. (There is no necessity to remember any command line.) Concerning backwards compatibility... despite I think compatibility is good if it is possible to keep it at reasonable cost, but we cannot keep odd and cofusing commands when we want to move forward - keeping 100% compatibility just because some legacy scritpts would be a painful way to hell. Regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Retire reset_mode option to target
Øyvind Harboe wrote: > We should of course take into account the current users, but my thinking > is that OpenOCD's *future* users (who are MUCH more numerous :-) > will thank us for making the right choice. Right. I vote for "reset" doing simple reset, that is "reset run" and either keep "reset run" as is, or retire it (which may be controversial, so rather keep it). Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Retire reset_mode option to target
Hello, Øyvind Harboe wrote: >> A "reset" will be the same as "reset run". If I want to reset and halt the >> target, >> then I have to use "reset run_and_init" explicitly. I agree that this is >> more intuitive. > > Dominic suggested that perhaps removing the default argument altogether would > be a good idea since expectations differ. I think the expectations differ because of historical reasons - some people are used to current behavior with target reset_mode parameter, otherwise I would say that it shall be pretty clear to most people that simple "reset" command just does reset. (But maybe I am mistaken.) If there is wider acceptance of removing default behavior, I can live with that however, this would meet a, but not b: Commands should a) look logically and resemble the thing they really do b) are convenient for the user Regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Retire reset_mode option to target
Hello Pieter, Pieter Conradie wrote: > Hi Øyvind, > Please explain/specify what is being retired. > When the target reset configuration is specified, there are options: > "reset_halt", "reset_init", "reset_run", "run_and_halt", "run_and_init" For > example: > > target arm7tdmi little run_and_init 0 > The reset command has the following options: > reset ['run'|'halt'|'init'|'run_and_halt' |'run_and_init'] > > It is said in the documentation that the "optional parameter overrides the > setting specified in the configuration file". > Do you propose that the target reset configuration is *always* overridden > with "reset init"? Why? Target reset mode specifies what is to be done when plain reset command (without parameters) is issued by script/user. Is a parameter is given to reset command, it always does what the parameter says, no matter what was stated in the target reset configuration. What is to be retired (if I understood right) is the target reset mode option, making the behavior of plain reset command fixed (and well defined). Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Retire reset_mode option to target
Hi Øyvind, Michael and others, Øyvind Harboe wrote: > You can choose the type of reset by the argument to reset > > "reset init" *always* executes the init script > "reset halt" *always* executes a reset halt. > > What we are discussing is the case without any arguments "reset". > I'd like it to always do a "reset init". Well, it is really a matter of discussion and also matter of point of view, whether this would be an expected behavior (expected by the user). I would say rather not. Reset is reset, it literally means to reset the target, nothing more. So if reset_mode is retired, I believe that the default behavior of reset command should be as plain as pressing a button which pulls the reset line - that is, "reset run", just a plain reset. If user needs to init the target, (s)he shall issue "reset init" command. My belief is that commands shall be constructed so that they: a) look logically and resemble the thing they really do b) are convenient for the user Fist a, then b, not otherwise. And remember - we have Tcl now, so if anyone is not fine with typing "reset init", there is always a possibility to define Tcl proc for this (or even override it - this shall be possible in Tcl). In general, I agree that the default behavior of reset command (unless overridden by custom Tcl proc) shall be fixed, as reset_mode adds unnecessary confusion. Note: Other logical possibility for reset command without parameters would be to do either "reset run" or "reset [run_and_]halt" depending on current state of the target - i.e. leave it running or halted after the reset, this might also be an expected behavior, probably more expected than "reset init", IMHO. Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Is tcl now a must have?
Hello, Øyvind Harboe wrote: > 2. commands.tcl requires (1), but we *could* embed it into the > executable instead but that addresses the symptom and not > the disease, it will only help us short-term. I consider this a goo idea if OOCD functions are changed to be scripting friendly with a TCL frontend like in flash banks example, so that basic commands are kept completely inside OOCD to reduce hassle for end users, especially those not much familiar with OOCD yet. Best ragards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Making commands more scripting friendly
Hello, Øyvind Harboe napsal(a): > Consider "flash banks 0". > > The output it produces is pretty hellish to parse from Tcl > (or any language really) + if we make that output of that > command part of the API, then changing it becomes > very awkward. > > Here is a thought on how to address this problem: > > 1. implement a low level fn that returns the information > above in tcl-speak. This is the OpenOCD API. > > 2. write a small tcl proc that formats the low level fn > info into a human readable form. This proc is part > of the "Telnet GUI" and not the API. So this is like moving OpenOCD in the direction of becoming more a library and transforming some code which is now internal to OpenOCD (in C) to TCL, right? Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] External scripting of OpenOCD
Øyvind Harboe napsal(a): >> I think we can come up with ONE simple reply format that *ALL* host apps >> can parse. > > I don't see the need for *any* format. > > My thinking is that the API is the tcl you send in, not the return format. > The return format is according to the convention in the frontend language.tcl > you use. language.tcl itself should be considered part of the application, > not the API. Hello, If I understood correctly, the external scripting is to be done by submitting commands to TCL server. So at least result of the TCL command processing itself shall be returned in defined format, or have I missed something? Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH - Jim/TCL patch - far more complete.
Hello, Duane Ellis napsal(a): > Øyvind> The GDB "mon" is just the channel/transport. > That however is an exclusive and private to GDB and GDB alone. That is > problematic. > Stated more generally - it is exclusive to the active debugger on the > GDB connection. > Nothing else can access the target via MON. I am using GDB protocol to communicate with OpenOCD from flash programming GUI - not a perfect solution, but it works. > All that I am suggesting is a more 'programmatic defined protocol' > specific to the tcl_server interface - nothing more. It is absolutely true that using GDB mon is not much suitable for real scripting from external application, e.g. it lacks passing a machine readable error code to the caller. Personally I am not against such extension, but it shall be a simple submit/result protocol, nothing complicated. Regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] reset config SRST_ONLY
Hello Steve and all, Steve Franks wrote: >> I'd say this is just one more argument for scriptable reset. There is no way >> we'll be able to come up with an algorithm & config parameters something >> that can cover all the weird reset schemes out there >> >> I'm trying to summarize a consensus + plan here > > Before the ARM, I'd never met a device that used/had a TRST > signal/pin. I have alot of cabling without it. Also, none of the > logic devices have an SRST either. Usually just use a 6 pin (4 jtag + > Vcc & Gnd) cable, seems to work on all my current FPGA & AVR > designs... well, you are right. The reset_config basically does make sense for ARMs only. I do not think that scripting is really needed for doing reset properly, however, OpenOCD has to take care about keeping state of the whole JTAG chain in sync, that is, when TRST is pulled (or even SRST, if it pulls TRST), the state machine has to be brought to TLR state by means of TMS to ensure that the parts not connected to TRST/SRST are in sync. I do not know for sure whether OpenOCD does that in current revision (anyone?) Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd scripting challenge
Øyvind Harboe wrote: >> Øyvind Harboe wrote: >>> Can anyone come up with a good example of how scripting >>> could be useful in configuration scripts? >> just as was mentioned already - mass production flash programming ant >> testing, >> but this is pretty important task in my point of view. > > Please explain "ant testing". (I use ant everyday, but I'm not sure it's > the same ant as you are referring to :-) ...and... of course, just a typo ;-) I do not know how it got there, despite I type with all 10 fingers but I should be more careful and read it back what. Spell checker certainly did not complain, as it is a valid word :-) > Could you explain the mass production scenario a bit more? Briefly a script which does steps like: 1) upload a routine doing basic hw tests and run it 2) check for result when the testing routine finishes 3) STOP if something went wrong - CONDITIONAL STEP, cannot be done with current batch command processing! 4) programming of flash memory 5) verification, STOP on error 6) generate serial number, program it to EEPROM and append it along with date and time to a file 7) return OK to calling process so that we can go on with next part I am sure that more complex examples may be found for hw containing more than one target or an FPGA etc... Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd scripting challenge
Hello, Øyvind Harboe wrote: > Can anyone come up with a good example of how scripting > could be useful in configuration scripts? just as was mentioned already - mass production flash programming ant testing, but this is pretty important task in my point of view. Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] reset config SRST_ONLY
Hello ?yvind, ?yvind Harboe napsal(a): > Basically a TMS reset happens while srst is asserted. This is > probably to drive the state machine into TAP_TLR as srst > pulls trst to sync up things. > > A cleaner way would be to simply set the tracked state > to TAP_TLR. This is not sufficient in all cases. If there is a part which does not feature TRST hooked up in the JTAG chain (e.g. FPGA) transition to TLR by means of TMS is a necessity to keep all parts in sync. I am going to test this soon, we have a board with this configuration in the manufacturing (AT91SAM9260 with SRST pulling TRST + an FPGA without TRST) Best regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Scripting language experiments
Hello Michael and Øyvind, Michael Schwingen wrote: >> messing around with this. Ideally they should just specify the >> target via the target library and then live happily ever after without >> worrying about OpenOCD again :-) If end users never mess >> around with the scripting language > > I don't really see this happening. At work, I use a BDI2000 on different > targets, and I usually have to write a config file that matches my hardware. I agree on this... modification of a script is often necessary to make it work with given hw. >> - write a flash driver in tcl. A flash driver consists of "a few peeks >> and pokes". Could a tcl script handle this for non-standard parts? I think this would perform really bad. Flash drivers without semi-hosting are slow on high latency JTAG interfaces even if written in C. >> The eCos + ocl flash drivers have had zero visible success. Sad but true, however, I am planning to do some more work on this. >> - write variant target support in tcl. The slight arm7/9 variants >> could perhaps be written in tcl? I have to say, that I do not like such idea at all, I doubt that end users would cope with TCL (or anything else) to create target variant support. This is rather unlikely. And for developers - mixture of two languages does not bring benefits, it would just make things more complicated. > I do not really see the benefit of splitting the source code for developers > into two languages. Having a full-fledged scripting language for > configuration is great, > however, if I need to learn another language to add/modify/patch openocd code > (like the CFI flash driver), I will be reluctant to do so. > Another problem: how do you debug a mixture of C and script code? Currently, > I can start up gdb on openocd and see everything that happens. My words, I do not see a benefit. However, scripting for configuration is fine (but not a necessity from my point of view). Regards, Pavel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] patch: jtag.c TLR rather than tms
Hello list, A cosmetic patch changing several remainder strings and comments - TAP reset without TRST shall be called TLR (stands for test-logic-reset, named after the TAP state it ends is) rather than tms (test-mode-select) - some comments changed to /* C coding style */ Please commit Pavel Index: src/jtag/jtag.c === --- src/jtag/jtag.c (revision 714) +++ src/jtag/jtag.c (working copy) @@ -106,7 +106,7 @@ char* jtag_event_strings[] = { - "JTAG controller reset(tms or TRST)" + "JTAG controller reset (TLR or TRST)" }; /* kludge these are just global variables that the @@ -927,7 +927,7 @@ /* FIX!!! there are *many* different cases here. A better * approach is needed for legal combinations of transitions... - */ +*/ if ((jtag_reset_config & RESET_HAS_SRST)&& (jtag_reset_config & RESET_HAS_TRST)&& ((jtag_reset_config & RESET_SRST_PULLS_TRST)==0)) @@ -937,7 +937,7 @@ ((req_srst&&!jtag_srst)|| (!req_srst&&jtag_srst))) { - // FIX!!! srst_pulls_trst allows 1,1 => 0,0 transition + /* FIX!!! srst_pulls_trst allows 1,1 => 0,0 transition */ //LOG_ERROR("BUG: transition of req_tlr_or_trst and req_srst in the same jtag_add_reset() call is undefined"); } } @@ -1000,7 +1000,7 @@ if (trst_with_tlr) { - LOG_DEBUG("JTAG reset with tms instead of TRST"); + LOG_DEBUG("JTAG reset with TLR instead of TRST"); jtag_add_end_state(TAP_TLR); jtag_add_tlr(); jtag_call_event_callbacks(JTAG_TRST_ASSERTED); @@ -1578,11 +1578,11 @@ if ((retval=jtag_interface_init(cmd_ctx)) != ERROR_OK) return retval; - LOG_DEBUG("Trying to bring the JTAG controller to life by asserting TRST / tms"); + LOG_DEBUG("Trying to bring the JTAG controller to life by asserting TRST / TLR"); /* Reset can happen after a power cycle. * -* Ideally we would only assert TRST or run tms before the target reset. +* Ideally we would only assert TRST or run TLR before the target reset. * * However w/srst_pulls_trst, trst is asserted together with the target * reset whether we want it or not. @@ -1595,7 +1595,7 @@ * NB! order matters srst *can* disconnect JTAG circuitry * */ - jtag_add_reset(1, 0); /* TMS or TRST */ + jtag_add_reset(1, 0); /* TLR or TRST */ if (jtag_reset_config & RESET_HAS_SRST) { jtag_add_reset(1, 1); ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] patch: several issues with PRESTO
Hello list, the attached patch fixes several issues in presto.c - lower jtag speeds (higher divisor) was used, TDI was not changed on falling TCK edge as it should - reset signal was release upon any TMS transition, making it impossible to use reset halt - added khz() and speed_div() functions and bitq.c - TAP state changed to TLR when SRST goes active with srst_pulls_trst, as in all other drivers Please commit Pavel Index: src/jtag/bitq.c === --- src/jtag/bitq.c (revision 714) +++ src/jtag/bitq.c (working copy) @@ -283,6 +283,10 @@ #ifdef _DEBUG_JTAG_IO_ LOG_DEBUG("reset trst: %i srst %i", cmd->cmd.reset->trst, cmd->cmd.reset->srst); #endif + if ((cmd->cmd.reset->trst == 1) || (cmd->cmd.reset->srst && (jtag_reset_config & RESET_SRST_PULLS_TRST))) + { + cur_state = TAP_TLR; + } bitq_interface->reset(cmd->cmd.reset->trst, cmd->cmd.reset->srst); if (bitq_interface->in_rdy()) bitq_in_proc(); break; Index: src/jtag/presto.c === --- src/jtag/presto.c (revision 714) +++ src/jtag/presto.c (working copy) @@ -51,6 +51,8 @@ int presto_jtag_speed(int speed); +int presto_jtag_khz(int khz, int *jtag_speed); +int presto_jtag_speed_div(int speed, int *khz); int presto_jtag_register_commands(struct command_context_s *cmd_ctx); int presto_jtag_init(void); int presto_jtag_quit(void); @@ -60,6 +62,8 @@ .name = "presto", .execute_queue = bitq_execute_queue, .speed = presto_jtag_speed, + .khz = presto_jtag_khz, + .speed_div = presto_jtag_speed_div, .register_commands = presto_jtag_register_commands, .init = presto_jtag_init, .quit = presto_jtag_quit, @@ -121,10 +125,13 @@ int jtag_tms; /* last tms state */ int jtag_tck; /* last tck state */ + int jtag_rst; /* last trst state */ int jtag_tdi_data; int jtag_tdi_count; + int jtag_speed; + } presto_t; presto_t presto_state; @@ -422,9 +429,12 @@ presto->jtag_tms=0; presto->jtag_tck=0; + presto->jtag_rst=0; presto->jtag_tdi_data=0; presto->jtag_tdi_count=0; + presto->jtag_speed=0; + #if BUILD_PRESTO_FTD2XX == 1 return presto_open_ftd2xx(req_serial); #elif BUILD_PRESTO_LIBFTDI == 1 @@ -567,81 +577,95 @@ /* -- */ +int presto_tdi_flush(void) +{ + if (presto->jtag_tdi_count == 0) + return 0; + + if (presto->jtag_tck == 0) + { + LOG_ERROR("BUG: unexpected TAP condition, TCK low"); + return -1; + } + + presto->jtag_tdi_data |= (presto->jtag_tdi_count - 1) << 4; + presto_sendbyte(presto->jtag_tdi_data); + presto->jtag_tdi_count = 0; + presto->jtag_tdi_data = 0; + + return 0; +} + + +int presto_tck_idle(void) +{ + if (presto->jtag_tck == 1) + { + presto_sendbyte(0xCA); + presto->jtag_tck = 0; + } + + return 0; +} + + +/* -- */ + + int presto_bitq_out(int tms, int tdi, int tdo_req) { - unsigned char cmdparam; + int i; + unsigned char cmd; if (presto->jtag_tck == 0) { - presto_sendbyte(0xA4); /* jtag activity */ - presto->jtag_tck = 1; /* clock remains high after the function returns */ - /* do just a single tick first, accelerated shifting needs TCK=1 */ + presto_sendbyte(0xA4); /* LED idicator - JTAG active */ } - else if (!tdo_req && tms == presto->jtag_tms) + else if (presto->jtag_speed == 0 && !tdo_req && tms == presto->jtag_tms) { - if (presto->jtag_tdi_count == 0) - presto->jtag_tdi_data = (tdi != 0); - else - presto->jtag_tdi_data |= (tdi != 0) << presto->jtag_tdi_count; + presto->jtag_tdi_data |= (tdi != 0) << presto->jtag_tdi_count; if (++presto->jtag_tdi_count == 4) - { - presto->jtag_tdi_data |= (presto->jtag_tdi_count - 1) << 4; - presto_sendbyte(presto->jtag_tdi_data); - presto->jtag_tdi_count = 0; - } + presto_tdi_flush(); + return 0; } - if (presto->jtag_tdi_count) - { - presto->jtag_tdi_data |= (presto->jtag_tdi_count - 1) << 4; - presto_sendbyte(presto->jtag_tdi_data); -