[Openocd-development] Breakpoints do not work for LM3S6918 /
I also am posting to the SparkFun's list for openOCD http://forum.sparkfun.com/viewtopic.php?t=16068 Best regards, Joe ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Creative summary of options for OpenOCDdistros
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Freddie Chopin Sent: woensdag 24 juni 2009 18:28 To: openocd-development Subject: [Openocd-development] Creative summary of options for OpenOCDdistros OK - be creative. End the flames, throw some ideas. Here goes another summary of REALISTIC and ACCEPTABLE options, if ftd2xx.dll will still be censored in the distributions. 1. Any kind of network protocol that would talk to driver. PRO - Possibilities to use JTAGs over internet to debug remotely, possibility to use closed-source drivers (for me that's a pro [; ) CONS - latency of the medium, need to run another program on one's PC, someone has to create the program and that has to be more complicated than the one from option 2. Freddy, Talking over de network may not be an option for Windows. A couple of years aho I worked on a portable (Linux / Windows) client - server application that used tcp/ip. On Linux this worked fine but on Windows XP we quickly learned that many short packets takes a lot of CPU power (even when send received on localhost). We ended up using a shared memory signals solution on Windows. A bit more cumbersome to write, but it performed very well. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Nico Coesel Sent: woensdag 24 juni 2009 22:28 To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers I'm itching to apply any patches on MIPS4K, but I can't really dive into MIPS support and provide useful feedback I could give the patches a spin on the MIPS platform I'm working with. I just don't know whether 'my' target has the FASTDATA register. I think I could give it a try for programming external flash first thing in the morning. I can't really promise anything though. I gave it a try but it doesn't apply to OpenOCD 0.1.0 (jtag_get_end_state missing). Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] The OpenOCD Foundation
On Wed, 2009-06-24 at 23:48 +0100, Wookey wrote: +++ Zach Welch [2009-06-24 14:00 -0700]: On Wed, 2009-06-24 at 09:30 -0700, Zach Welch wrote: I hereby commit myself to donating all profits recovered in the pursuit of OpenOCD GPL violations on my behalf to a non-profit. I would prefer that the community create The OpenOCD Foundation to receive such funds and manage them along with the copyrights and trademarks on behalf the open source and free software communities. Should forming this type of organization haven proven intractable, I want any recovered monies to fund the Free Software Foundation instead. I have prepared a proposal to create The OpenOCD Foundation, which I can post in a new thread. I'm not sure a project of this size needs a whole foundation of its own. It might make more sense to look at using an institution like SPI which provides services like keeping money in pools for projects and legal advice, to Free Software projects. This requires little more than asking them to accept OpenOCD and set up a pool for project monies. Having a copyright assignment body might be useful. Excellent. I had already considered this option, but adding it in addition to the above language would have gotten more cumbersome. Such organizations definitely offer a middle-ground, but the ability to manage copyright assignments seems pretty important for the sake of GPL enforcement by the community, yes. Additional consideration in this matter will require looking at the mission and resources of those bodies, and measuring these to see which fits this community the best. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
On Jun 24, 2009, at 1:32 PM, openocd-development-requ...@lists.berlios.de wrote: 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx How would ftd2xx be linked here? Via LoadLibrary (dlopen) and friends? I'd volunteer to create such a solution. We build and distribute: OpenOCD - libftdi Users would download and install libftdi-ftd2xx *instead* of libftdi. Since they have the same ABI, the application cannot tell the difference between the open and closed versions. OpenOCD binaries cannot legally be distributed with the wrapper, only with the the normal libftdi. They should behave the same in all outward function ways; there cannot be any conditional code in OpenOCD to enable the wrapper library. I like the sound of this approach. In order to prevent disruption to the existing OpenOCD users, I would like to suggest that no change be made to the status quo (i.e. you have to manually enable FTD2XX mode at build time, and that code path is still there) until this new shim library project has been completed. i.e. I think it would be great to go forward when the prerequisite support is there to do so, however I feel that should be on its own timeline and the existing level of capability in OpenOCD (fully GPL compliant or not, this is the status quo) -- should not be allowed to regress prior to that moment. Restated: Let OpenOCD 0.2.0 ship with whatever feature set is desired, but without removing any capability for FTD2XX - *unless* - the new shim lib is completed and available to mate up with that release. i.e. I think this is a great thing to improve, but I am questioning whether it is a priority-1 blocker for 0.2.0, given the history. Rob ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
On Thu, 2009-06-25 at 01:17 -0700, Rob Barris wrote: On Jun 24, 2009, at 1:32 PM, openocd-development-requ...@lists.berlios.de wrote: 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx How would ftd2xx be linked here? Via LoadLibrary (dlopen) and friends? I'd volunteer to create such a solution. We build and distribute: OpenOCD - libftdi Users would download and install libftdi-ftd2xx *instead* of libftdi. Since they have the same ABI, the application cannot tell the difference between the open and closed versions. OpenOCD binaries cannot legally be distributed with the wrapper, only with the the normal libftdi. They should behave the same in all outward function ways; there cannot be any conditional code in OpenOCD to enable the wrapper library. I like the sound of this approach. In order to prevent disruption to the existing OpenOCD users, I would like to suggest that no change be made to the status quo (i.e. you have to manually enable FTD2XX mode at build time, and that code path is still there) until this new shim library project has been completed. i.e. I think it would be great to go forward when the prerequisite support is there to do so, however I feel that should be on its own timeline and the existing level of capability in OpenOCD (fully GPL compliant or not, this is the status quo) -- should not be allowed to regress prior to that moment. Restated: Let OpenOCD 0.2.0 ship with whatever feature set is desired, but without removing any capability for FTD2XX - *unless* - the new shim lib is completed and available to mate up with that release. i.e. I think this is a great thing to improve, but I am questioning whether it is a priority-1 blocker for 0.2.0, given the history. We have said it before, but the official position bears repeating: The FTD2XX driver is legal to build and use on your machine. It always has been and always will be. It is not legal to distribute binaries with that driver. In these respects, we have no reason to remove it from the source code, until such a time as the open source alternative has been shown to outperform it (and the proprietary driver bit-rots). Personally, I want to make that day come sooner rather than later. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] platform survey
Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 Please _everyone_ register (sorry) and tell us what host OS you want to use OpenOCD with. It's not scientific or accurate, but comments could help fill in information gaps that the numbers would fail to capture. If enough users make their voices heard, the maintainers can use these numbers to better investigate the feasibility of forming a community foundation to manage our resources (e.g. copyrights, funding, etc.). This data can also be used seek support in the broader free software community, such as pursuing funding for community development and resources. Large numbers of users will help attract interest. Without such evidence of use, that boat may be sunk before it sails. Your vote will matter here. Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Jun 23, 2009, at 7:53 PM, Rick Altherr wrote: Technically, nothing is required from the project-side. The infringement happens solely at the time of distribution, not at the time of authoring or compilation. Since OpenOCD is only released as source code, the project is not directly affected by any infringement. Doing nothing still leaves packagers and distributors open to the possibility of committing infringement rather easily, but that is still a choice made by them, not us. D2xx is by default disabled. _If_ we choose to do anything for 0.2.0, it could be as simple as adding a warning that by having D2xx enabled, the resulting binaries cannot be distributed. I have a few questions which I would like each regular contributor to assess, if you can spare a few moments: a) is Rick's last sentence above one that you agree or disagree with ? b) Given the number of revisions and releases of OpenOCD out in the wild, and the lack of any conflict to date (other than the thought experiments posted on the list), do you feel it is a #1 priority to solve for 0.2.0? I have seen a couple of scattered opinions, but am not clear on how a final decision will be made for this release. Statements such as we must do this don't fly with me since prior releases have gone out and the Sun did not go nova. c) Aren't there GPL applications on Linux that can load binary DLL's, I don't know, say the Flash plugin ? d) Is it worth our time to talk to FTDI and see if they can move to GPL ? e) What concrete benefits does the *existing* OpenOCD derive from being GPL licensed, as compared to BSD license ? Rob ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] platform survey
Zach Welch z...@superlucidity.net napisał(a): Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 There are already some more votes here: http://www.elektroda.pl/rtvforum/topic1347875.html You have to register to see the poll, but currently the numbers are: Windows ? 68% ?[ 20 ] Linux ? 24% ?[ 7 ] Mac OS X ? 3% ?[ 1 ] other ? 3% ?[ 1 ] all : 29 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] platform survey
On Thu, 2009-06-25 at 11:12 +0200, freddie_cho...@op.pl wrote: Zach Welch z...@superlucidity.net napisał(a): Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 There are already some more votes here: http://www.elektroda.pl/rtvforum/topic1347875.html Dang, I actually cut out a sentence saying: Please inform all other OpenOCD user group to register their votes here too! So much for KISS. We want to be able to show people a single verifiable page to confirm this data, and I saw that was posted in the past few days. I was not sure what other options would be more appropriate for this purpose, but the new survey was low-hanging fruit. So, any suggestions other than mine above to just tell everyone to hit the Sparkfun poll? Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
On Thu, 2009-06-25 at 01:09 -0700, Rob Barris wrote: On Jun 23, 2009, at 7:53 PM, Rick Altherr wrote: Technically, nothing is required from the project-side. The infringement happens solely at the time of distribution, not at the time of authoring or compilation. Since OpenOCD is only released as source code, the project is not directly affected by any infringement. Doing nothing still leaves packagers and distributors open to the possibility of committing infringement rather easily, but that is still a choice made by them, not us. D2xx is by default disabled. _If_ we choose to do anything for 0.2.0, it could be as simple as adding a warning that by having D2xx enabled, the resulting binaries cannot be distributed. I have a few questions which I would like each regular contributor to assess, if you can spare a few moments: a) is Rick's last sentence above one that you agree or disagree with ? Technically, I agree. Politically, I think it better to find a solution for binary distribution. That said, the technical argument probably deserves to win. Others need to provide feedback; I will not dictate our release goals, but I will help lead us to them. b) Given the number of revisions and releases of OpenOCD out in the wild, and the lack of any conflict to date (other than the thought experiments posted on the list), do you feel it is a #1 priority to solve for 0.2.0? I have seen a couple of scattered opinions, but am not clear on how a final decision will be made for this release. Statements such as we must do this don't fly with me since prior releases have gone out and the Sun did not go nova. Well, I think there is value to start pumping out releases, regardless of the potential binary distribution problems. I think Rick is right that these can be worked in parallel, and waiting would only hold back everyone that uses source code distribution or can do without FTD2XX. There are few reasons to delay pursuing releases, but I do not want that to prevent distribution solutions from being developed. Due to the recent confusion and scattering to action on new problems, resources are indeterminate at the moment. I cannot say where we stand, so I am reluctant to make any release decisions yet. c) Aren't there GPL applications on Linux that can load binary DLL's, I don't know, say the Flash plugin ? I will not comment on other projects, sorry. This stuff is complicated. d) Is it worth our time to talk to FTDI and see if they can move to GPL ? LGPL would be fine, but YES YES YES. If you have contacts and leverage, then you are encouraged to use them to this end. The more users that ask them, the more likely they will be to change their minds. I hope. If someone gets a meaningful answer from them that explains why they could never do that, then please post it. If they are simply protecting their library IP, then keep putting pressure on them. Gentle, kind, loving pressure; you know -- the kind that smothers and suffocates. Torches and pitchforks will work better when delivered with a smile and a friendly attitude. We mean business, but we must use the diplomatic approach here -- FTDI has done us no real harm. They are not an enemy, but neither does their present license make them our friend. e) What concrete benefits does the *existing* OpenOCD derive from being GPL licensed, as compared to BSD license ? OpenOCD is GPL. The short answer is enforceable freedoms, but this is not the time or the place to debate licensing pros and cons. Sorry. :) Thanks, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] MIPS/EJTAG watchpoints support
Committed. Thanks! his patch replaces only comments where we have a false positive ERROR_OK today and a /* TODO*/ comment, so even if I can't review it from a MIPS point of view, I don't have a problem with committing it. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] proposed FASTDATA bulk write optimizationfor mips_m4k file transfers
I gave it a try but it doesn't apply to OpenOCD 0.1.0 (jtag_get_end_state missing). It wouldn't. OpenOCD 0.1.0 is pretty ancient by now. Please try again with svn head. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
On Wed, Jun 24, 2009 at 23:30, Duane Ellisopen...@duaneellis.com wrote: Zach Welch wrote: Hi all, Here is the full list of GPL-compliant solutions for libftd2xx GPL compliance, after further review, consideration, and enumeration: 1) Documentation: build it yourself! 2) Build-Kit: automate the build on users' machines 3) XXX: to be revealed, if legal 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx 5) sockets: separate ftd2xx into their own process space 6) libusb+libftdi: The Right Thing To Do ;) You are missing (7) - WinUSB - the windows platform type solution that is simular to libusb. Sadly, it does not go back to Win2K - but - most (popular) others are solved. Does WinUSB require any special privileges or signatures for a client that connects to the API? From my understanding libusb requires a kernel mode driver that needs to be installed by an admin first. If that is the case and if WinUSB can be used by the program without signing or admin privileges then WinUSB would seem the more practical approach. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Wed, Jun 24, 2009 at 17:34, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote: The libusb improvements certainly sound interesting, however no one has stepped forward to implement them or to pay someone to implement them. They may or may not also require some reverse engineering plus extensive profiling that would make them more time-consuming than the wrapper. So they don't seem like a near-term solution at the moment. Others have stated emphatically that the specifications are open and available for the developers to take a whack at replacing their library. Unless it is incomplete or inaccurate, the matter should be straightforward enough. :) Heh. I have not seen a spec that documents the USB endpoints and how to interact with them. But if someone has a link to that it would be nice if that person could post that. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Summer coding project proposal
On Thu, 2009-06-25 at 14:55 +0200, Michael Bruck wrote: On Wed, Jun 24, 2009 at 17:34, Zach Welchz...@superlucidity.net wrote: On Wed, 2009-06-24 at 16:00 +0200, Michael Bruck wrote: The libusb improvements certainly sound interesting, however no one has stepped forward to implement them or to pay someone to implement them. They may or may not also require some reverse engineering plus extensive profiling that would make them more time-consuming than the wrapper. So they don't seem like a near-term solution at the moment. Others have stated emphatically that the specifications are open and available for the developers to take a whack at replacing their library. Unless it is incomplete or inaccurate, the matter should be straightforward enough. :) Heh. I have not seen a spec that documents the USB endpoints and how to interact with them. But if someone has a link to that it would be nice if that person could post that. Indeed. I took a look around their site today, and I can only find chip specifications -- no protocol documents. They may be there, but I gave up after a few pointless PDF downloads. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Joe, Try adding this to your configuration file # gdb_memory_map enable # This tells openocd to inform GDB where 'flash lives' - thus GDB will attempt to use hardware breakpoints. You are also not paying attention to what GDB is telling you - when it cannot find the bounds of the current function - not much is going to work.. This is very true of the command step - which - is a *source*level* step. Read back through what I told you about how GDB steps ... if the current PC is not within the bounds of your code - GDB has no way to figure out how to STEP - it can - however stepi - which is an instruction step, but *you* the human need to type stepi - not step. === I start GDB - without a configuration file, and type various commands - below is a transcript of what I am typing with embedded comments. I am using an atmel at91sam3u4E chip on a SAM3U-EK eval board, I do not have a Luminary Micro - however both are cortex-M3 parts. === [du...@borgcube basic-internalflash-project]$ ../../../install/bin/arm-none-eabi-gdb GNU gdb (GDB) 6.7.50.20080107-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as --host=i686-pc-linux-gnu --target=arm-none-eabi. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. === I did not specify a CONFIG file on the command-line and I did not specify an ELF file on the command line. therefore I must type commands and specify the ELF file I want to debug. === = Specify the ELF file... = (gdb) file ./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf Reading symbols from /home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas ic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf...done. = Specify the target = (gdb) target remote 192.168.0.100: Remote debugging using 192.168.0.100: 0x in ?? () = Tell openocd to HALT the target = (gdb) mon halt = Tell openocd to RESET the target. = (gdb) mon reset JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) JTAG Tap/device matched = And i tell it to halt again... = (gdb) mon halt target state: halted target halted due to debug-request, current mode: Handler BusFault xPSR: 0x2105 pc: 0x000817dc = Load my program - this actually programs the flash = (gdb) load Loading section .fixed, size 0x133c lma 0x8 Loading section .relocate, size 0xf4 lma 0x8133c Start address 0x811dc, load size 5168 Transfer rate: 4 KB/sec, 2584 bytes/write. = Set a breakpoint at main() = (gdb) break main Breakpoint 1 at 0x800c0: file main.c, line 168. = Tell GDB to continue - see the NOTE from GDB... = (gdb) cont Continuing. Note: automatically using hardware breakpoints for read-only addresses. = I hit my breakpoint.. = Breakpoint 1, main () at main.c:168 168 TRACE_CONFIGURE(DBGU_STANDARD, 115200, BOARD_MCK); (gdb) = Works for me :-) = -Duane. ___ 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] 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] Creative summary of options for OpenOCDdistros
Nico Coesel pisze: Talking over de network may not be an option for Windows. A couple of years aho I worked on a portable (Linux / Windows) client - server application that used tcp/ip. On Linux this worked fine but on Windows XP we quickly learned that many short packets takes a lot of CPU power (even when send received on localhost). We ended up using a shared memory signals solution on Windows. A bit more cumbersome to write, but it performed very well. Generally that was not me who suggested that idea some time ago. I believe that was Oyvind or Duane. Generally _IMHO_ the network protocol should be used via networks, and on the localhost I'd prefer the driver/modules solution. But that's not up to me (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
Zach Welch pisze: Technically, I agree. Politically, I think it better to find a solution for binary distribution. That said, the technical argument probably deserves to win. Others need to provide feedback; I will not dictate our release goals, but I will help lead us to them. As English is the second language I know, I'm really confused about what exactly do you mean... Any clarifications please? 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
Hi Pavel, 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! GPL stops closed source target interface for OpenOCD. That's one of the *main* reasons I got involved with OpenOCD in the first place. 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. It would be absolutely hell to try come up with some sort of GPL with exception that did not open up for closed source target/interface's. Personally I don't think it can be done, LGPL isn't it and nothing else specifi has been suggested. 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. There are lots of closed source debug solutions out there for those targets/interfaces that are not willing to open up. Good for 'em! That's not what OpenOCD is about. 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 stand out amongst the hardware vendors because you have made *very* significant contributions in the past. How about using the bitq stuff forl a generic JTAG over TCP/IP solution? ;-) Giving up the most important line of defense against closed source target interface support due to some silly little technical problem can't possibly make any sense to you? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fix Rev 2403 build on Windows
Rev 2403 fails on Windows/MinGW, because:
1. there is no strtok_r(), but strtok() is reentrant, so use that
patch file - win32-strtok.patch
That was discussed earlier in [Openocd-development] [Openocd-svn] r2381
- trunk/src/helper thread
2. alloca() needs malloc.h included
patch file - win32-alloca.patch
These two patches fix Windows/MinGW build, please test and commit (;
4\/3!!
Index: src/helper/membuf.c
===
--- src/helper/membuf.c (revision 2403)
+++ src/helper/membuf.c (working copy)
@@ -25,6 +25,13 @@
#include membuf.h
+/*
+ * Win32 plaftorm doesn't have strtok_r(), but strtok() is reentrant
+ */
+#ifdef _WIN32
+#define strtok_r(source, delimiters, lasts)strtok(source, delimiters)
+#endif
+
struct membuf {
// buflen is alway +1 bigger then
// what is shown here, the +1 is for
Index: src/flash/at91sam3.c
===
--- src/flash/at91sam3.c(revision 2403)
+++ src/flash/at91sam3.c(working copy)
@@ -56,6 +56,12 @@
#include config.h
#endif
+/*
+ * Win32 platform has alloca() in malloc.h
+ */
+#ifdef _WIN32
+#include malloc.h
+#endif
#include stdio.h
#include string.h
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] platform survey
Zach Welch wrote: Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 Please _everyone_ register (sorry) and tell us what host OS you want to use OpenOCD with. It's not scientific or accurate, but comments could help fill in information gaps that the numbers would fail to capture. Hi, this sounds a bit over the top to me - *register* at a forum I don't need, just to participate in a poll? cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] openocd.texi - svf and xsvf commands
Add a short chapter on boundary scan support, which currently
just documents the SVF and XSVF commands.
---
doc/openocd.texi | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
Add a short chapter on boundary scan support, which currently
just documents the SVF and XSVF commands.
---
doc/openocd.texi | 50 +-
1 file changed, 49 insertions(+), 1 deletion(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -78,6 +78,7 @@ Free Documentation License''.
* General Commands:: General Commands
* Architecture and Core Commands:: Architecture and Core Commands
* JTAG Commands::JTAG Commands
+* Boundary Scan Commands:: Boundary Scan Commands
* TFTP:: TFTP
* GDB and OpenOCD:: Using GDB and OpenOCD
* Tcl Scripting API::Tcl Scripting API
@@ -850,7 +851,7 @@ There are many ways you can configure Op
A simple way to organize them all involves keeping a
single directory for your work with a given board.
When you start OpenOCD from that directory,
-it searches there first for configuration files
+it searches there first for configuration files, scripts,
and for code you upload to the target board.
It is also the natural place to write files,
such as log files and data you download from the board.
@@ -5353,6 +5354,53 @@ levels, such as advancing the ARM9E-S in
Consult the documentation for the TAP(s) you are working with.
@end itemize
+...@node Boundary Scan Commands
+...@chapter Boundary Scan Commands
+
+One of the original purposes of JTAG was to support
+boundary scan based hardware testing.
+Although its primary focus is to support On-Chip Debugging,
+OpenOCD also includes some boundary scan commands.
+
+...@section SVF: Serial Vector Format
+...@cindex Serial Vector Format
+...@cindex SVF
+
+The Serial Vector Format, better known as @dfn{SVF}, is a
+way to represent JTAG test patterns in text files.
+OpenOCD supports running such test files.
+
+...@deffn Command {svf} filename [...@option{quiet}]
+This issues a JTAG reset (Test-Logic-Reset) and then
+runs the SVF script from @file{filename}.
+Unless the @option{quiet} option is specified,
+each command is logged before it is executed.
+...@end deffn
+
+...@section XSVF: Xilinx Serial Vector Format
+...@cindex Xilinx Serial Vector Format
+...@cindex XSVF
+
+The Xilinx Serial Vector Format, better known as @dfn{XSVF}, is a
+binary representation of SVF which is optimized for use with
+Xilinx devices.
+OpenOCD supports running such test files.
+
+...@quotation Important
+Not all XSVF commands are supported.
+...@end quotation
+
+...@deffn Command {xsvf} (tapname|@option{plain}) filename [...@option{virt2}] [...@option{quiet}]
+This issues a JTAG reset (Test-Logic-Reset) and then
+runs the XSVF script from @file{filename}.
+When a @var{tapname} is specified, the commands are directed at
+that TAP.
+When @option{virt2} is specified, the @sc{xruntest} command counts
+are interpreted as TCK cycles instead of microseconds.
+Unless the @option{quiet} option is specified,
+messages are logged for comments and some retries.
+...@end deffn
+
@node TFTP
@chapter TFTP
@cindex TFTP
___
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
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. Sorry to hijack this message. The whole situation made me wonder about MySQL several times. The MySQL license says that it is free when GPL is respected but you must pay if you want to use it in a commercial / closed source product. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix Rev 2403 build on Windows
alloca()? That's very unfriendly towards non-MMU
targets.
Attached is a patch that removes alloca().
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
Index: C:/workspace/openocd/src/flash/at91sam3.c
===
--- C:/workspace/openocd/src/flash/at91sam3.c (revision 2399)
+++ C:/workspace/openocd/src/flash/at91sam3.c (working copy)
@@ -2146,7 +2146,7 @@
return ERROR_FAIL;
}
- pagebuffer = alloca(pPrivate-page_size);
+ pagebuffer = malloc(pPrivate-page_size);
// what page do we start end in?
page_cur = offset / pPrivate-page_size;
@@ -2167,7 +2167,7 @@
LOG_DEBUG(Special case, all in one page);
r = sam3_page_read(pPrivate, page_cur, pagebuffer);
if (r != ERROR_OK) {
- return r;
+ goto exit_fn;
}
page_offset = (offset (pPrivate-page_size-1));
@@ -2177,9 +2177,10 @@
r = sam3_page_write(pPrivate, page_cur, pagebuffer);
if (r != ERROR_OK) {
- return r;
+ goto exit_fn;
}
- return ERROR_OK;
+ r=ERROR_OK;
+ goto exit_fn;
}
// non-aligned start
@@ -2189,7 +2190,7 @@
// read the partial
r = sam3_page_read(pPrivate, page_cur, pagebuffer);
if (r != ERROR_OK) {
- return r;
+ goto exit_fn;
}
// over-write with new data
@@ -2200,7 +2201,7 @@
r = sam3_page_write(pPrivate, page_cur, pagebuffer);
if (r != ERROR_OK) {
- return r;
+ goto exit_fn;
}
count -= n;
@@ -2219,7 +2220,7 @@
(count = pPrivate-page_size)) {
r = sam3_page_write(pPrivate, page_cur, buffer);
if (r != ERROR_OK) {
- return r;
+ goto exit_fn;
}
count-= pPrivate-page_size;
buffer += pPrivate-page_size;
@@ -2232,7 +2233,7 @@
// we have a partial page
r = sam3_page_read(pPrivate, page_cur, pagebuffer);
if (r != ERROR_OK) {
- return r;
+ goto exit_fn;
}
// data goes at start
memcpy(pagebuffer, buffer, count);
@@ -2238,7 +2239,7 @@
memcpy(pagebuffer, buffer, count);
r = sam3_page_write(pPrivate, page_cur, pagebuffer);
if (r != ERROR_OK) {
- return r;
+ goto exit_fn;
}
buffer += count;
count -= count;
@@ -2244,7 +2245,11 @@
count -= count;
}
LOG_DEBUG(Done!);
- return ERROR_OK;
+
+ r=ERROR_OK;
+exit_fn:
+ free(pagebuffer);
+ return retval;
}
static int
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
Rob Barris wrote: I have a few questions which I would like each regular contributor to assess, if you can spare a few moments: a) is Rick's last sentence above one that you agree or disagree with ? I agree technically. A release can be made in the current state, and I could live with that version just fine. However, I see that there are Windows users that would be unhappy with a source-only version (or a binary without D2XX). If developing a solution for them can be done fast, we should wait. Otherwise, there is no harm in releasing 0.2.0 soon and releasing a new version as soon as the solution is release-worthy - there is no need to delay the release for everyone just to wait for one platform. 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 Thu, Jun 25, 2009 at 7:20 PM, Nico Coeselncoe...@dealogic.nl wrote: 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. Sorry to hijack this message. The whole situation made me wonder about MySQL several times. The MySQL license says that it is free when GPL is respected but you must pay if you want to use it in a commercial / closed source product. So you're saying that someone might try to have it both ways? Keep anything *they* make closed source, yet demand to be able to freely use OpenOCD GPL for the stuff that they don't have(target support) or that OpenOCD provides for free or does better. It makes business sense I guess. Perfectly legal. They would have to be careful as the devil in not letting any of the OpenOCD code seep into their proprietary/closed source stuff though. I found that Zylin would be better off to go for GPL all the way for our zy1000 hardware debugger. Less hazzle and I have great faith in the OpenOCD future. I wouldn't want to try to compete with the community. At some point OpenOCD is going to reach critical mass where it no longer makes sense to reimplement everything closed source/clean room... -- Øyvind Harboe Embedded software and hardware consulting services http://www.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
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. You know, if we *all* were reasonble and would intrepret things in the best meaning, then we wouldn't need a license at all. The license is there to handle the case of conflicting interests and scheming bastards :-) So as maintainers and contributors in the community it is in our best interest to try to find all the loopholes and nasty tricks that a malicous party may try to pull. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Dynamic library loading
Hello list! I'm trying to make loading of libraries dynamic, so that those would not be required always - just when needed. I've created globals for function pointers, library handle. I open the library - everything is cool. I get processes addresses - still cool. I use some functions - cool. Generally whole ft2232 initialization works fine (there are many functions called dynamically and that works, the read serial number is correct), then there are initialization functions for JTAG chain and suddenly function ft2232_read() fails, but in some strange way... The FT_Read is executed (via a function pointer of course), and it returns. There is no OpenOCD error (so some status is returned, the number of bytes is ok, and so on). The function gets to it's end, but never returns to the caller. Windows shows access violation exception, so I'm guessing that dynamially called FT_Read destroys the stack frame and return address somehow... Any idea what I may be doing wrong? What info can I provide for you to help me in that task? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] first ftd2xx fix: documentation!
Freddie Chopin wrote: Main problem with build environment for Windows is that MinGW itself is just a compiler, and MSYS is just a shell. You need like a dozen of different addons for MSYS, and you need to compile them and install them. It's not common knowledge for Windows user what is the system directory on linux. Maybe I'm missing the point but you can also build openocd with cygwin using the gcc flag -mno-cygwin. You do need a finite number of cygwin packages such as gcc, make etc beyond the default install. I tried the build under msys but couldn't get past the ./bootstrap step. The howto on this is on Sparkfun. google: build openocd on windows. A build instructions can be detailed, but the process itself is pretty long, as you have to download an install lots of stuff - my folder with almost-all that is required is 133megs, add the libraries and openocd itself. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Building on Ubuntu (9.04)
Ok this should be an easy one compared to what we have been dealing with :) I have check out out svn, ./bootstrap ./configure --enable-ft2232_libftdi --enable-jlink --enable-arm-jtag-ew --enable-ioutil and I get checking Build Link with libftdi.. configure: error: Cannot build run test program using libftdi I checked the archives and see talk of fixing this kind of problem in december an did mentioned version 0.10 (which is what I have) Is that something that should have been committed? Should I download and build the latest libftdi instead? tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
The FT_Read is executed (via a function pointer of course), and it returns. There is no OpenOCD error (so some status is returned, the number of bytes is ok, and so on). The function gets to it's end, but never returns to the caller. Windows shows access violation exception, so I'm guessing that dynamially called FT_Read destroys the stack frame and return address somehow... Any idea what I may be doing wrong? What info can I provide for you to help me in that task? you are using the wrong calling convention if this happens. Note the WINAPI i have done this with previous ftdi stuff, try typedef FT_STATUS (WINAPI *FT_OPENEX)(PVOID pArg1,DWORD Flags,FT_HANDLE *pHandle); static FT_OPENEX FT_OpenEx = NULL; and then to get functions: hDll = LoadLibrary( ftd2xx.dll ); if( hDll == NULL ) return ERROR_FTD2XX; FT_OpenEx = (FT_OPENEX)GetProcAddress( hDll, FT_OpenEx ); if( FT_OpenEx == NULL ) return ERROR_FTD2XX; Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building on Ubuntu (9.04)
On Thu, 2009-06-25 at 17:05 -0300, Alain Mouette wrote: Building OpenOCD is far more complex then it should be :( I also had a few problems building on Ubuntu 8.04. I made a detailed report on the problems, so that they could be improved. Unfortunately I got no echo from the list on these matters :( Alain Thanks, I will track down your message... I am curious... what hosts does it build properly right out of the box? tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building on Ubuntu (9.04)
On Thursday 25 June 2009, Thomas A. Moulton wrote: ./configure --enable-ft2232_libftdi --enable-jlink --enable-arm-jtag-ew --enable-ioutil and I get checking Build Link with libftdi.. configure: error: Cannot build run test program using libftdi Did you sudo apt-get install libftdi-dev to get the library? I've done a build on 9.04, no problems. Though ... I also kickedin the --enable-maintainer-mode (since I was building from git-svn). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building on Ubuntu (9.04)
On Thursday 25 June 2009, Alain Mouette wrote: Building OpenOCD is far more complex then it should be :( I also had a few problems building on Ubuntu 8.04. I made a detailed report on the problems, so that they could be improved. Unfortunately I got no echo from the list on these matters I thought I followed up on that. The issue with the 8.04 release is that it's got an old libftdi. To build on that you'll need a new libftdi. https://lists.berlios.de/pipermail/openocd-development/2009-June/008095.html Ah, I see. Wrong thread. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...
On Thursday 11 June 2009, Alain Mouette wrote: and I get this error: checking for ftd2xx.h... yes checking for library containing FT_GetLibraryVersion... no configure: error: You appear to be missing the FTD2xx driver library. https://lists.berlios.de/pipermail/openocd-development/2009-June/008095.html The 8.04 version is too old to work with current source. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Spencer Oliver pisze: you are using the wrong calling convention if this happens. Note the WINAPI Dude - you rule! That was exactly the problem - I've copied the typedef for pointers from msdn and the example used __cdecl instead of WINAPI. Changing that with your suggestion fixed the problem [; Thx : I'm wondering now whether I should be doing such things... /; Anyway - would such feature be accepted to OpenOCD (if fully tested and working of course)? I think that it would be a good addition, because no libraries would have to be distributed with OpenOCD releases. Now - when all interfaces are enabled - the distro should have libftdi.dll (or ftd2xx.dll) and libusb0.dll - even if the end-user doesn't need them. I think there are 4 interfaces that would need that - ft2232, presto, jlink and rlink. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
Michael Fischer pisze: this looks great. If you need someone for testing, give me a note. Does it mean you need for each interface a dll? In this case, perhapse I can try to translate an interface for you. Unfortunatelly I'm not trying to implement drivers/modularity in OpenOCD, as the status of that solution is not clear to me. Probably that one is not good - see Oyvind's (I hope he doesn't mind regular O instead of trV-norsk one) posts about vendors willing to add closed source drivers to OpenOCD. I'm just trying to make libftdi, ftd2xx and libusb0 loaded dynamically - that's for startes : 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building on Ubuntu (9.04)
David Brownell escreveu: On Thursday 25 June 2009, Alain Mouette wrote: Building OpenOCD is far more complex then it should be :( I also had a few problems building on Ubuntu 8.04. I made a detailed report on the problems, so that they could be improved. Unfortunately I got no echo from the list on these matters I thought I followed up on that. The issue with the 8.04 release is that it's got an old libftdi. To build on that you'll need a new libftdi. Ah, I did not get that because I used only libftdxx :) But here comes one more suggestion: CMAKE should give a message about the old version during the check phase... If this is made, I volunteed to make a test :) Ah, I see. Wrong thread. ?? Alain ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Dynamic library loading
you are using the wrong calling convention if this happens. Note the WINAPI Dude - you rule! That was exactly the problem - I've copied the typedef for pointers from msdn and the example used __cdecl instead of WINAPI. Changing that with your suggestion fixed the problem [; Thx : been there many times myself!! I'm wondering now whether I should be doing such things... /; Anyway - would such feature be accepted to OpenOCD (if fully tested and working of course)? I think that it would be a good addition, because no libraries would have to be distributed with OpenOCD releases. Now - when all interfaces are enabled - the distro should have libftdi.dll (or ftd2xx.dll) and libusb0.dll - even if the end-user doesn't need them. Personally i think it is a good addition - i am not a fan of binding dll's at link time. At least then openocd can be built for all interfaces and the user does not have to install libusb and libftdi etc. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...
On Thursday 25 June 2009, Alain Mouette wrote: The 8.04 version is too old to work with current source. It is not too old, I managed to compile ok, in the end... The problem with that error is that it was trying to make a test program linking to /usr/lib/libftd2xx.so and it was not there. The problem I saw was different: it was trying to link its test program using a symbol that wasn't present on older libraries. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compiling from svn on ubuntu 8.04 fails...
David Brownell escreveu: On Thursday 25 June 2009, Alain Mouette wrote: The 8.04 version is too old to work with current source. It is not too old, I managed to compile ok, in the end... The problem with that error is that it was trying to make a test program linking to /usr/lib/libftd2xx.so and it was not there. The problem I saw was different: it was trying to link its test program using a symbol that wasn't present on older libraries. That is exactly the problem: the message is missleading. I had the latest version, and the problem in fact is not what is reported. And because of that, it took me a lot of time to fix. That is the reason why I made a report as a whish to be inproved :) Alain ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] platform survey
On Thu, 2009-06-25 at 19:19 +0200, Michael Schwingen wrote: Zach Welch wrote: Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 Please _everyone_ register (sorry) and tell us what host OS you want to use OpenOCD with. It's not scientific or accurate, but comments could help fill in information gaps that the numbers would fail to capture. Hi, this sounds a bit over the top to me - *register* at a forum I don't need, just to participate in a poll? And I _asked_ for alternate suggestions. What would you have me do? --Z ___ 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 ?
On Fri, 2009-06-26 at 00:21 +0159, Maciej Grela wrote: Hi, 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. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix Rev 2403 build on Windows
On 25/06/2009, Øyvind Harboe oyvind.har...@zylin.com wrote: Attached is a patch that removes alloca(). From the patch: - return ERROR_OK; + + r=ERROR_OK; +exit_fn: + free(pagebuffer); + return retval; Is it just me, or are you assigning everything to r and then returning retval instead? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building on Ubuntu (9.04)
On Thu, 2009-06-25 at 13:26 -0700, David Brownell wrote: On Thursday 25 June 2009, Alain Mouette wrote: Building OpenOCD is far more complex then it should be :( I also had a few problems building on Ubuntu 8.04. I made a detailed report on the problems, so that they could be improved. Unfortunately I got no echo from the list on these matters I thought I followed up on that. The issue with the 8.04 release is that it's got an old libftdi. To build on that you'll need a new libftdi. https://lists.berlios.de/pipermail/openocd-development/2009-June/008095.html Ah, I see. Wrong thread. Boy they gotta watch the numbering... I have 8.04LTS on a machine in my office and 9.04 is running at home... g I am going to upgrade my office machine... Let me get up to date and try again... I do see other comments about the errors reported and will watch out too... tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building on Ubuntu (9.04)
Thomas A. Moulton a écrit : On Thu, 2009-06-25 at 17:05 -0300, Alain Mouette wrote: Building OpenOCD is far more complex then it should be :( I also had a few problems building on Ubuntu 8.04. I made a detailed report on the problems, so that they could be improved. Unfortunately I got no echo from the list on these matters :( Alain Thanks, I will track down your message... I am curious... what hosts does it build properly right out of the box? tom Fedora, SuSE, Mandriva and most likely Slackware. -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Building on Ubuntu (9.04)
Michel Catudal escreveu: I am curious... what hosts does it build properly right out of the box? Fedora, SuSE, Mandriva and most likely Slackware. Not really. It does compile but it is difficult to get it to compile the first time, problems usualy with dependecies and figuring out how to setup things. IMHO that figuring out is what can be made better... Alain PS. I was a Mandriva user untill recently, I just moved to Kubuntu 8.04 wich is LTS and it is good for a while more. I just hope that KDE4 becomes useable by the end of the year. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] platform survey
Hi all, Here's some random place I found that hosts polls. See if you can vote here. It doesn't appear to require a login to work: http://www.freepollhosting.com/directory.php?id=437page=6pop= http://www.freepollhosting.com/directory.php?id=437page=6pop= The site seems still beta, but it should be able to house the poll at the very least. // Dean On 06/25/2009 05:32 PM, Zach Welch wrote: On Thu, 2009-06-25 at 19:19 +0200, Michael Schwingen wrote: Zach Welch wrote: Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 Please _everyone_ register (sorry) and tell us what host OS you want to use OpenOCD with. It's not scientific or accurate, but comments could help fill in information gaps that the numbers would fail to capture. Hi, this sounds a bit over the top to me - *register* at a forum I don't need, just to participate in a poll? And I _asked_ for alternate suggestions. What would you have me do? --Z ___ 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] platform survey
Thanks for the constructive alternative; I knew someone would fine one. This would be acceptable too, except it can be gamed. Unfortunately, this is a tricky proposition... I am not sure if on-line voting can be fully trusted in any form at this point in time, even with registration. So, we might as well give this a try. Also, the alternatives you provided do not seem too specific. If we want such detailed data, I would rather see them grouped w/o 32/64-bit and get that data point a separate poll question. I have a feeling there will be a significant number of Other users. For right now, the most important number is the total user base. How big is the community? So, everyone go there and try to vote. Let's give it a try. Cheers, Zach On Thu, 2009-06-25 at 14:52 -0500, Dean Glazeski wrote: Hi all, Here's some random place I found that hosts polls. See if you can vote here. It doesn't appear to require a login to work: http://www.freepollhosting.com/directory.php?id=437page=6pop= The site seems still beta, but it should be able to house the poll at the very least. // Dean On 06/25/2009 05:32 PM, Zach Welch wrote: On Thu, 2009-06-25 at 19:19 +0200, Michael Schwingen wrote: Zach Welch wrote: Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 Please _everyone_ register (sorry) and tell us what host OS you want to use OpenOCD with. It's not scientific or accurate, but comments could help fill in information gaps that the numbers would fail to capture. Hi, this sounds a bit over the top to me - *register* at a forum I don't need, just to participate in a poll? And I _asked_ for alternate suggestions. What would you have me do? --Z ___ 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] Dynamic library loading
Zach Welch pisze: FWIW, this will not bring GPL-compliance. How could that possibly bring GPL compliance? Is that the goal, or just loadable library support? I am in favor of this later, but I thought you were pushing for the former. Later. I want to see a patch before commenting about whether or not it should be accepted here. I'm not a kind of developer that does such things in a blink of an eye, so I'd rather not waste my time if - for example - some developers are highly against dynamic loading. That's clear that you won't add something I propose without judgement, but I'm rather asking about attitude towards such concept. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fix Rev 2403 build on Windows
On Fri, Jun 26, 2009 at 1:01 AM, Martin Pantervadmium+o...@gmail.com wrote: On 25/06/2009, Øyvind Harboe oyvind.har...@zylin.com wrote: Attached is a patch that removes alloca(). From the patch: - return ERROR_OK; + + r=ERROR_OK; +exit_fn: + free(pagebuffer); + return retval; Is it just me, or are you assigning everything to r and then returning retval instead? It's broken alright :-) I want to get rid of alloca. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
