Unsubscribe.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
d most of them now.
>
> Here comes my patch.
>
> Best regards
> Magnus
>
>
> New jtag statetables in ft2232 and jlink
>
>
> The parts concering jtag state tables and transitions are from Dick
> Hollenbeck
>
&g
Magnus Lundin wrote:
> Dick Hollenbeck skrev:
>> Zach,
>>
>> I think this patch is fundamentally wrong and is a disaster the
>> moment it is applied.
>>
>> The queue sits between the jtag api and the drivers. The api calls
>> track "future"
Zach,
I think this patch is fundamentally wrong and is a disaster the moment
it is applied.
The queue sits between the jtag api and the drivers. The api calls
track "future" state according to the most recent api call submitted
(and put onto the back end of the queue) via the cmd_queue_cur_st
* xsvf.patch:
This simplifies XSTATE handling, and protects against illegal state
transitions that might be in an SVF file. Previous code was vulnerable
to a bad path. They are now handled through a robust use of the
tms_seq[] table. With this patch and my xsvf_tools, I was able to work
w
Zach,
You are a quality guy and I want to go on record, with you being the
recipient, of why I am leaving the project.
>>> Yes, it could be separated. I could do it myself, but I have my own
>>> list of tasks.
If the patch was separated and only portions of it were ap
>> I have never seen a project that needs to be forked as badly as this
>> one. You sit around and nit pick about about which dinner glasses to
>> pour the water into. Somebody shows up with a firetruck wanting to fill
>> the swimming pool and you can't handle it.
>>
>> This firetruck ain't w
#Using_executables_in_the_build_created_during_the_build
Index: src/pld/CMakeLists.txt
===
--- src/pld/CMakeLists.txt (revision 0)
+++ src/pld/CMakeLists.txt (revision 0)
@@ -0,0 +1,11 @@
+# Copyright 2009 SoftPLC Corporation http://softplc.com
+# Dick Hollenbeck
+# License: GPL
Index: src/openocd.c
===
--- src/openocd.c (revision 1588)
+++ src/openocd.c (working copy)
@@ -228,6 +228,21 @@
int httpd_start(void);
void httpd_stop(void);
+
+#if !BUILD_HTTPD
+/* implementations of OpenOCD that uses multithre
> Dick,
>
> Once again, "it's not you, it's me." Blah, blah, blah :)
>
English please. No idea what the above sentence is saying.
> On Fri, 2009-05-01 at 20:02 -0500, Dick Hollenbeck wrote:
>
>> This patch is large and:
>>
>
ion 0)
@@ -0,0 +1,11 @@
+# Copyright 2009 SoftPLC Corporation http://softplc.com
+# Dick Hollenbeck
+# License: GPL v2
+
+SET(PLD_SRCS
+ pld.c
+ xilinx_bit.c
+ virtex2.c
+)
+
+add_library(pld STATIC ${PLD_SRCS})
Property changes on: src/pld/CMakeList
of an AGDI
> plug-in for using OpenOCD; Dario Vecchio posted his implementation along
> with references to the related specifications; I hope someone will take
> these pieces and provide a complete and robust solution (in tree?).
>
> OMAP3 and Cortex-{M3,A8} support were improved by
Øyvind Harboe wrote:
> On Fri, May 1, 2009 at 6:24 PM, Dick Hollenbeck wrote:
>
>> That function basically exists in the xsvf.c file, so some factoring may be
>> possible.
>>
>
> Ah. Thanks!
>
> Rename to jtag_add_statemove() & move into jtag.c as a
Magnus Lundin wrote:
> Dick Hollenbeck wrote:
>
>> Laurent Gauch wrote:
>>
>>
>>>> Dick Hollenbeck wrote:
>>>>
>>>>
>>>>
>>>>> / Are other folks having problems with tab expan
That function basically exists in the xsvf.c file, so some factoring may
be possible.
Here is a copy of my current work:
> Single stepping is broken in ARM11 w/parport interface(and
> others). I'm working on adding a jtag_add_statemove() fn
> that will sit on top of jtag_add_pathmove() that is
Laurent Gauch wrote:
>> Dick Hollenbeck wrote:
>>
>>> / Are other folks having problems with tab expansion differences between
>>>
>> />/ editors?
>> />/
>> />/ I load jtag.c into two different editors and get
Are other folks having problems with tab expansion differences between
editors?
I load jtag.c into two different editors and get two different results
when tab width is set to 4.
This makes it difficult to view a table like tms_seq in the two
editors. The editors are well established, JEdit a
Øyvind Harboe wrote:
>> - Changing JTAG state transitions to use shortest path rather than 7 clocks
>> - Fixing all the drivers that assumed 7 clocks per transition
>>
>
> Why would you want to change this? We've got pathmove for those cases
> where the path matters...?
>
>
Said another way
This lets the
#define OPENOCD_VERSION
refer to the config.h contents, by moving it below the #include config.h
Please commit, thanks.
Dick
Index: src/openocd.c
===
--- src/openocd.c (revision 1570)
+++ src/openocd.c (working copy
Rick Altherr wrote:
> Actually, the TCL layer is using TCL objects which in the JIM
> implementation of TCL, happen to be pointers. Of course, with JIM, we
> didn't need to build our own runtime, so things like determining the
> type of an object is handled for us.
>
> I've had a number of idea
Albert Cahalan wrote:
> On Thu, Apr 30, 2009 at 1:59 AM, Michael Bruck wrote:
>
>> On Thu, Apr 30, 2009 at 7:12 AM, Zach Welch wrote:
>>
>
>
>>> At the most fundamental level, it comes down to this:
>>>
>>> C == imperative programming
>>> C++ == object-oriented programming
>>>
>>> Th
Michael Schwingen wrote:
> Dick Hollenbeck wrote:
>
>> As I said before, I personally would be willing to give up designated
>> initializers, but really nothing more within C99. And I really love the
>> iterator type stuff:
>>
>> for( int i=0; i<7; ++
> Sorry I have lost most of my enthusiasm, but I don't understand your
> problem probably. Please explain if you can.
>
> Dick
>
>
A candid analysis would paint me extremely resentful for having to do
anything to support Microsoft in any way. If they cannot keep up, there
stupid C compiler
Igor Skochinsky wrote:
> Hello Dick,
>
> Thursday, April 30, 2009, 4:28:54 AM, you wrote:
>
>
>
>>> Due to the lack of prior opposition, I had been debating whether to
>>> simply commit a change that adds -std=c99 and seeing how the community
>>> reacts (since I can now revert it quickly if it p
> Due to the lack of prior opposition, I had been debating whether to
> simply commit a change that adds -std=c99 and seeing how the community
> reacts (since I can now revert it quickly if it poses a real problem).
>
The -std=c99 option is a big positive for me. I like it. There are C
co
Michael Bruck wrote:
> This problem was introduced by r1559 in replacements.h
>
> in ft2232.c windows.h (or more precise winsock2.h) must be included
> after sys/select.h
>
> Michael
>
I put this change into my pending patch, so it can be piggy backed there.
That will be on the list by end of
Dick Hollenbeck wrote:
> The new driver is working ok with the calls to
> tap_get_tms_path_len(start_state, goal_state);
>
> If I use the old version of the new binary tms_seqs table with the new
> driver, I see the exact same behavior on my ARM9 board as with the
> ft2232.c
The new driver is working ok with the calls to
tap_get_tms_path_len(start_state, goal_state);
If I use the old version of the new binary tms_seqs table with the new
driver, I see the exact same behavior on my ARM9 board as with the
ft2232.c in HEAD.
If I use the new version of the binary tms_s
Ironically, if the project was compilable with C++, there would likely
be *more* compatibility with MS VC++ than what we have now using C. I
say that because Kicad can be compiled by either, using CMake.
Dick
___
Openocd-development mailing list
Open
Zach,
Your work is appreciated, by me and others.
> On Wed, 2009-04-29 at 13:24 -0500, Dick Hollenbeck wrote:
> [snip]
>
>> The C99 stuff is purely arbitrary IMO, there is almost always another
>> way to code those things. And rather than ifdef-ing them out, I would
>> And I am allergic to Windows, so there will need to be a "CMake on Windows"
>> champion to step up and take this bull by the horns.
>>
>
> Good luck finding that one :)
>
Not my job. I don't use Windows. But I think the folks that do have
found their champion. :)
>
>
> I found
Michael Bruck wrote:
> I tried that and it seems IS_CYGWIN is not set correctly on cygwin. Any idea ?
>
> Michael
>
Michael,
I see a potential solution that is worth a try.
Move these lines:
if(CYGWIN)
set(IS_CYGWIN, true)
else(CYGWIN)
set(IS_CYGWIN, false)
endif(CYGWIN)
if(MINGW)
> As I said, the makefile generation mostly works "out of box" (I only
> had to specifty location of libftd2xx manually). Right now I'm trying
> nmake makefiles, not VS projects.
>
>
>> To deal with your issues, and assuming Windows, I would stick with the GNU
>> compiler as your first attempt,
> I tried that and it seems IS_CYGWIN is not set correctly on cygwin. Any idea ?
>
> Michael
>
>
Michael,
Thanks for trying this.
How do you build openocd on windows, does it require CYGWIN or is there
another way?
Using CMake on Windows, a reasonable goal would be to ween ourselves of
Igor Skochinsky wrote:
> Hello All,
>
> Tuesday, April 28, 2009, 7:29:46 PM, Dick wrote:
>
> DH> Latest.
> DH> Paaleese commit any time.
>
> So I decided to try the legendary CMake compatibility and compile
> OpenOCD with native Win32 MSVC. The makefile generation went mostly
> without a hitch, but
Øyvind Harboe wrote:
> On Tue, Apr 28, 2009 at 10:48 PM, Dick Hollenbeck wrote:
>
>> Michael Bruck wrote:
>>
>>> So my question would be: does anyone know if the drivers produce
>>> different state transitions (except for idling on stable states) for
the day I can delete the above script.
Dick
Index: src/pld/CMakeLists.txt
===
--- src/pld/CMakeLists.txt (revision 0)
+++ src/pld/CMakeLists.txt (revision 0)
@@ -0,0 +1,11 @@
+# Copyright 2009 SoftPLC Corporation http://softpl
Michael Bruck wrote:
> So my question would be: does anyone know if the drivers produce
> different state transitions (except for idling on stable states) for
> the jtag_* calls, including more complex stuff that involves
> jtag_add_ir_scan etc. ?
>
This is a superbly excellent question. One t
nd states.
>
> * I agree with Michael, put the restrictions in the upper levels, that
> would be state_move
>
> Regards,
> Magnus
>
>
>
> Dick Hollenbeck wrote:
>
>> Michael,
>>
>>
>>
>>> 1. The underlaying jtag_* layer
This adds:
* calls to tap_get_tms_path_len(start, end);
* adds buffer overflow protection in the form of a few well placed
asserts().
* numerous comments and documentation references.
* attempts to do diligent state transition logging, making it easier to
track moves to ANY tap state at any
riction should be retired at the earliest
> possible opportunity. And it should weighted if the benefits of
> supporting severely restricted JTAG hardware outweigh the problems of
> adding complexity and potential for errors in the target drivers.
>
> At the least I would like to know if it
This patch adds the platform for experimentation of state path
transitions using TMS sequences shorter than 7 clocks.
It will break nothing, I promise.
If you want to experiment with the new table at line 3143 in jtag.c,
then just enable that #if statement at line 3127 and augment your
driver
://softplc.com
+# Dick Hollenbeck
+# License: GPL v2
+
+SET(PLD_SRCS
+ pld.c
+ xilinx_bit.c
+ virtex2.c
+)
+
+add_library(pld STATIC ${PLD_SRCS})
Property changes on: src/pld/CMakeLists.txt
___
Added: svn:mime-type
+ text/plain
Øyvind Harboe wrote:
> I'm concerned about backwards compatibility on this one.
>
> I'd like to see a compile/runtime option to switch between
> the old/new table.
>
> E.g. I suspect that ARM11 has some dependencies on
> the precise paths taken today and that really it should
> have a couple of mor
Dick Hollenbeck wrote:
> Just a heads up on this table. Because the old table had an implicit
> length of 7 bits understood, often there are "clock consumption" stages
> in the old path, enough to consume 7 clock cycles and still get to the
> final destination.
>
>
Just a heads up on this table. Because the old table had an implicit
length of 7 bits understood, often there are "clock consumption" stages
in the old path, enough to consume 7 clock cycles and still get to the
final destination.
That is, if the transition needed less than 7 clocks, there st
Magnus Lundin wrote:
>> It would be nice to get some comments on the 8 bit sequence for entering
>> RESET.
>>
>> I think the reasoning needs to be documented, else we go back to 7 bits?
>>
>
> Agree, or even use shortest path, I think the state transitions should be
> shortest path.
Ok, agre
It would be nice to get some comments on the 8 bit sequence for entering
RESET.
I think the reasoning needs to be documented, else we go back to 7 bits?
Dick
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.ber
Revised.
Found a bug in one of the bit counts.
Removed some redundant error checks.
Dick
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 1548)
+++ src/jtag/jtag.h (working copy)
@@ -181,7 +181,26 @@
*/
int tap_get_tms_
Zach Welch wrote:
> On Mon, 2009-04-27 at 09:51 -0500, Dick Hollenbeck wrote:
>
>> This was removed from the repo.
>>
>> Why?
>>
>> The project will not build.
>>
>
> Please be sure to use --enable-maintainer-mode with configure. If you
>
This puts the bit count into the tms_seq table and adds the function:
int tap_get_tms_path_len( tap_state_t from, tap_state_t to )
It may break the ft2232 driver, but I have a fix coming for that in
about 6 hours. I have it written but have to run out for awhile to hit
some tennis balls.
Duane Ellis wrote:
> Dick Hollenbeck wrote:
>> Duane,
>>
>> This is the 3rd time now I am mentioning my need to get after the
>> ft2232.c driver code, starting Monday. I am happy to start from
>> your starting point or from HEAD, but once I start, I won&#x
Collect some macros, add DIM()
Collection can be moved but at least they are starting to be gathered up.
Dick
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 1545)
+++ src/jtag/jtag.h (working copy)
@@ -40,7 +40,18 @@
#de
This was removed from the repo.
Why?
The project will not build.
Dick
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Zach Welch wrote:
> On Fri, 2009-04-24 at 18:39 +0200, Magnus Lundin wrote:
> [snip]
>
>>>static tap_state_t exception_path[] = {
>>>TAP_DREXIT2,
>>>TAP_DRSHIFT,
>>>TAP_DREXIT1,
>>>
Øyvind Harboe wrote:
> On Fri, Apr 24, 2009 at 7:52 AM, Dick Hollenbeck wrote:
>
>> Why is this code in jtag_add_pathmove()?
>>
>>
>> ??
>>
>>/* the last state has to be a stable state */
>>if (!tap_is_state_stable(path[nu
Why is this code in jtag_add_pathmove()?
??
/* the last state has to be a stable state */
if (!tap_is_state_stable(path[num_states - 1]))
{
LOG_ERROR("BUG: TAP path doesn't finish in a stable state");
exit(-1);
}
???
It is not
Duane Ellis wrote:
> zack> [arrays]
>
> Dick> [nak arrays, they get out of sync, etc]
>
> ???> [use C99 array initializers]
>
> All well and good, but remember their is this big nasty other compiler
> that does not support C99... openocd does not build with that compiler.
Correct, and C++ does n
Magnus Lundin wrote:
> Hi, here are som thoughts after looking throuh some parts of the jtag
> subsystem.
>
> What is a stable state ? A state that is unchanged or a state that is
> unchanged and has no sideeffects ? Only RESET and PAUSE ?
>
A stable state is one that can persist with subse
Øyvind Harboe wrote:
> Ironically, resisting the CMake patch, might the best
> way to get people to stand up and report their interst ;-)
>
> I'm starting to be more convinced that having both
> committed to svn is not detrimental to OpenOCD,
> the crowd is growing and you're getting some good
> na
> The device is really an
> easedropping tool but the brains behind it would be back on the PC,
> perhaps a separate process which only looks at the serial port, and is
> probably written in Python if I were to do it.
>
> This keeps the cost out of the device, and puts the emulation software
>
Øyvind Harboe wrote:
>> In others words: nothing beats testing with a real target and there will
>> always be new devices that require some patching.
>>
>
> Most of the time the trouble is with bugs and quirks in the target
> hardware and not actually bugs in OpenOCD as such
>
>
>
Funny
R.Doss wrote:
>
>>> now on The
>>>
> List with numerous bullets beneath it.
>
>
Yes, this is an FPGA with a serial port on it?The is
>>> your universal
>>>
JTAG TAP emulator, which gives feedback about the path than
>>> an
Magnus Lundin wrote:
> Dick Hollenbeck wrote:
>
>> Magnus Lundin wrote:
>>
>>> The tap state engine will not change any time soon.
>>>
>>> Hopefully the statenumbers will stay.
>>>
>>> But there will probably be work on shortes
Magnus Lundin wrote:
> The tap state engine will not change any time soon.
>
> Hopefully the statenumbers will stay.
>
> But there will probably be work on shortest path tables, path transition
> tables with fixed mumber of tap transition etc. For this type of work I
> think an array is a better
Magnus Lundin wrote:
> OK, I am a developer, I am lazy and my only strong feelings about build
> systems is "I dont care, I dont want to know, and a do not want to
> learn". Sure, sometimes we have to do this and perfect builds with
> clean installations for every platform is an art to admire a
Zach Welch wrote:
> On Wed, 2009-04-22 at 16:04 -0500, Dick Hollenbeck wrote:
>
>> Zach Welch wrote:
>>
>>> On Wed, 2009-04-22 at 14:51 -0500, Dick Hollenbeck wrote:
>>>
>>>
>>>>>> Nice work Zach.
>>>>
This was posted to another project and it lists some nice things about
CMake:
1) you can run ccmake (yes, extra c in front) to fine tune the
configuration options interactively if your first choices are wrong,
inside a nice GUI.
2) you can run cmake to do out of tree builds. This is
nice
Michael Schwingen wrote:
> Dick Hollenbeck wrote:
>
>> I nak the arrays. I hate them, they are a crash waiting to happen.
>>
>>
> Why?
>
>
>> Put the same logic into a series of switches please, nested if necessary.
>>
>> Switches
Zach Welch wrote:
> On Wed, 2009-04-22 at 14:51 -0500, Dick Hollenbeck wrote:
>
>>>> Nice work Zach.
>>>>
>>>>
>>> Thanks Dick. But nothing else for me to add? :)
>>>
>>>
>> Yes, I would
>> Nice work Zach.
>>
>
> Thanks Dick. But nothing else for me to add? :)
>
Yes, I would ask that folks *try* out the CMake support.
I think they have the potential to help some Windows folks who might
get roadblocked at cygwin requirements.
>
>> Maybe this file can be put int
Zach Welch wrote:
> Hi all,
>
> Unless I accidentally missed something, the attached patches provide the
> last _functional_ changes in Jeff Williams' J-Link patch; my final task
> will be to extract and apply the debugging improvements that he made, as
> it looks like they will then need to be imm
Zach Welch wrote:
> On Wed, 2009-04-22 at 11:07 -0700, Rick Altherr wrote:
> [snip]
>
>> This is an interesting idea, but I think it skips an important step.
>> There seem to be a number of problems solely within the JTAG and
>> interface layers. It would be great if someone constructed so
Zach Welch wrote:
> On Wed, 2009-04-22 at 19:52 +0200, Øyvind Harboe wrote:
>
>> One annoying problem is that all target hardware is
>> not available to all OpenOCD developers.
>>
>> For development purposes, this could perhaps be
>> addressed by creating a JTAG over TCP/IP protocol.
>>
>> The i
prove 32/64-bit portability
>
> ======
> OpenOCD's Active Developers and Testers
> --
>
> ** - Name - Status - Targets - Interfaces
> NC - Nico Coesel - *
Magnus Lundin wrote:
> The only reason I can think of for a specic numbering is that it might
> optimize the gate design in a hardware implementation of the tap state
> engine. But this is not a problem for us so thats OK. If we want to
> follow JTAG documentation standards (ARM ane IEEE) in ou
You know in the old days source code control systems (SCCS) would
require a developer to "check out" a copy of the code, and while it was
checked out, nobody else could modify the code. This was before the
merge routines were as smart as they are today.
There has been a LOT of traffic on thi
Dick Hollenbeck wrote:
> Zach Welch wrote:
>
>> Hi all,
>>
>> This patch fixes several warnings caused by -Wformat-security, which
>> appears to be the default in Ubuntu
Zach Welch wrote:
> Hi all,
>
> This patch fixes several warnings caused by -Wformat-security, which
> appears to be the default in Ubuntu 8.10.
>
> Cheers,
>
> Zach
>
>
The original code looks fine to me. I think you are
both for a while
> - convert drivers that use old API over to the new one
> - remove old tap_get_tms_path
> - other changes work picking out of Duane's patch-in-progress
>
> * FT2232 driver:
> - fix segfault from long scan chains (observed by Dick Hollenbeck)
Zach Welch wrote:
> On Sat, 2009-04-18 at 06:31 -0500, Dick Hollenbeck wrote:
>
>> 1)
>> I would like to see tap_set_state() called for ALL state changes, not
>> just the end points of of a multi-state path move. This way when
>> logging is compiled ON, we can
Zach Welch wrote:
> On Sun, 2009-04-19 at 21:25 -0500, Dick Hollenbeck wrote:
>
>> [snip]
>> Why are you changing this argument from the machine's natural size to
>> one that is 32 bits wide?
>>
>> Dick
>>
>
> Fair enough. Here is take
Duane Ellis wrote:
> dick hollenbek>
> [duane where are you??? ... snip snip snip]
>
> zach welch>
> [[I am working my way down to debugging this driver, but I have been
> waiting for Duane to finish his TAP patches in hope they help.]]
>
> Some things have come up and I'm not go
Zach Welch wrote:
> On Sun, 2009-04-19 at 17:54 -0700, Zach Welch wrote:
>
>> On Sun, 2009-04-19 at 17:18 -0700, Zach Welch wrote:
>>
>>> Hi all,
>>>
>>> Since my patch to enable -Werror got in a little faster than I expected,
>>> I decided to try and save myself some pain by installing and
Zach Welch wrote:
> Hi guys,
>
> What is the status of the out-of-tree TAP work? Can I talk you into
> posting the patches in their current state for review, along with a
> description of what is done and the list of tasks still in progress?
>
> Thanks,
>
> Zach
>
I have no modified code yet.
Piotr Esden-Tempski wrote:
> Hi!
>
> On Apr 17, 2009, at 4:52 AM, Dick Hollenbeck wrote:
>
>>
>>>> There still needs to be some
>>>>
>>>> if(APPLE)
>>>> endif(APPLE)
>>>>
>>>> lines added for static li
>> There still needs to be some
>>
>> if(APPLE)
>> endif(APPLE)
>>
>> lines added for static libraries on APPLE.
>>
>
> These should be called MACOS_X as Apple is a company, not a product or
> OS.
You are correct. CMake probably has its own platform define however,
that it defines automagicall
/helper/CMakeLists.txt (revision 0)
+++ src/helper/CMakeLists.txt (revision 0)
@@ -0,0 +1,43 @@
+# Copyright 2009 SoftPLC Corporation http://softplc.com
+# Dick Hollenbeck
+# License: GPL v2
+
+
+
+add_executable(bin2char bin2char.c)
+add_custom_command(
+OUTPUT ${CMAKE_CURRENT_BINARY_DIR
I found some new support for static libraries in CMake 2.6.2 and will
test it out shortly
Dick
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Michael Fischer wrote:
> Hi Dick,
>
> the LIB problem is a general LIB problem, because the
> libusb and libftdi will not be found.
>
> Your line look like:
>
> set(CONDITIONAL_LIBS ${LIBFTDI_LIBRARIES} ${CONDITIONAL_LIBS})
>
> I know that my libs was installed here:
>
> /opt/local/libftdi-0.15
>
>
Michael Fischer wrote:
> Hello Dick,
>
>
>> Michael,
>>
>> Do these changes work for you?
>>
>>
>> if(NEED_USB)
>> find_package(LibUSB)
>> set(CONDITIONAL_LIBS ${CONDITIONAL_LIBS} ${LIBUSB_LIBRARIES})
>> include_directories( ${LIBUSB_INCLUDE_DIR} )
>> endif(NEED_USB)
>>
>>
>> if(BUILD_FT2232_FTD
Michael Schwingen wrote:
> Dick Hollenbeck wrote:
>
>> I am not a CMake expert, but this is a decent first draft. I believe
>> it will be possible to get to a point where you can build openocd just
>> with simple tools on Windows, no need for CYGWIN or even a bash s
Michael Fischer wrote:
> Hello Dick,
>
> now I understand a little how to use CMake, I could define tht
> path with -D. Now I use a build.sh script which look like:
>
> ===
> #!/bin/sh
>
> cmake -DLIBFTDI_LIBRARIES=/opt/local/libft
Michael,
This script looks good. Another way is to use ccmake before running
make. ccmake will edit the cmake cache, CMakeCache.txt
You can also edit that file with a text editor.
Then your 4 paths will be set.
And as your other email mentions, we need to add the two include paths
to the com
Moving a private conversation to the list.
--- Begin Message ---
Hello Dick,
now I understand a little how to use CMake, I could define tht
path with -D. Now I use a build.sh script which look like:
===
#!/bin/sh
cmake -DLIBFTD
Yes Michael, good catch!
You are a CMake expert in 10 minutes. The same level of expertise in
autotools would take a person 10 days.
We need to add the includes, like you suggest. (I missed that in my
testing because I had my includes in a standard place.)
You can run any CMake built makefi
Øyvind Harboe wrote:
> There are a couple of problems with C++:
>
> - there is no consensus to use it for OpenOCD. This will be
> *hard* to arrive at since there are a lot of deeply embedded
> developers that we need for OpenOCD to succeed.
> - there is a lot of messy & nasty C++ libraries. I'd hat
Rick Altherr wrote:
>
> On Apr 14, 2009, at 1:44 PM, Øyvind Harboe wrote:
>
>>> I'd rather know _why_ something failed rather than having to dig
>>> through the
>>> code to figure out which layer and why. Not every user is a UNIX
>>> programmer
>>> with intimate knowledge of the targets, interfa
/opt/local/libusb-0.1.12"
> LIBS="-lftdi -lusb" gcc conftest.c
>
> But got the following error:
>
> Undefined symbols,
> "_ftdi_new", referenced from:
> _main in ccy6Vq7b.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
&
Michael Fischer wrote:
> Hello list,
>
> I am working on a Mac OS X installer for OpenOCD.
> If I only install the openocd executable, I got an
> error that the dynamic library for libusb and libftdi
> can not be found.
>
Are you saying that you want to use:
1) static libraries for libusb and
1 - 100 of 164 matches
Mail list logo
