Re: [Openocd-development] OpenOCD + libftdi on Windows
On Fri, Jun 19, 2009 at 4:05 AM, Freddie Chopin wrote: > Michael Fischer pisze: >> upps, in case of performance I have tested here only >> download to RAM. And this looks like the same, 140 KB/sec. > > Unfortunately, I have no chips with external RAM, so I cannot test that > kind of speed - STM32 I have has only 20kB, so the upload speed result > will be worthless IMHO > > At work I have a STM32-EVAL-E, which (I think) has some external RAM, so > maybe I'll test that too. > Yes that one is a nice board and have the following expansion memory on the FSMC: 512 Kx16 SRAM, 512 Mbit or 1 Gbit NAND Flash and 128 Mbit NOR Flash (along with a TFT LCD). I just borrowed one from ST Singapore and it has a STM32103ZET6 on board. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
On Fri, Jun 19, 2009 at 3:36 AM, Freddie Chopin wrote: > As Michael wrote to me, you actually need a hacked version of > libusb0.sys for any composite USB device (FT2232) to work... It's just > asking for trouble IMHO... > > http://www.nabble.com/LibUSB---composite-USB-devices-td11027391.html > > Add that libusb cannot be compiled on Windows and you need to use > libusb-win32, which is 2 y.o. now and only 0.1.12... When someday > OpenOCD switches to newer libusb, what will happen to windows support? > Will that be dropped, for the sake of GPL? Please refer to my reply to Michael. You may want to try out two methods. 1) Use the svn version of libusb-win32. This may not work. https://lists.berlios.de/pipermail/openocd-development/2009-June/008004.html 2) I believe the INF file is not correct in order to use a composite device with libusb-win32 0.1.12. You should use the INF wizard to generate the driver for the whole device, not the individual interface. I have used libusb-win32 0.1.12 with USB composite device using this method and it works fine. https://lists.berlios.de/pipermail/openocd-development/2009-June/008022.html https://lists.berlios.de/pipermail/openocd-development/2009-June/008066.html Reference: http://article.gmane.org/gmane.comp.lib.libusb.devel.windows/2088 Unfortunately I do not have an FTDI device to try out this method. But you may want to give it a try. As for the speed issue, I think that might get some help if OpenOCD will switch to use libusb 1.0 under Linux and use asynchronous I/O. libusb-win32 0.1.12 already supports asynchronous I/O. As for GPL issue, I think that is up to the authors. I personally think it would be better to grant a exception to the D2XX driver given the complications of using libsub-win32/libftdi under Windows. But I am not an author (can not code) so I have no say on this topic. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Thursday 18 June 2009, Michael Fischer wrote: > > have you make a decision if the next official release > will build on FTD2XX or on libftdi? The source code should still build with both. However, nobody is allowed to distribute binaries that depend on the D2XX libraries. that is, no change whatever in policy, the licensing remains unchanged. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 9/11] Transform 'u64' to 'uint64_t'
On Thu, 2009-06-18 at 13:50 -0700, Rick Altherr wrote:
> On Jun 18, 2009, at 3:47 AM, Zach Welch wrote:
>
> > On Thu, 2009-06-18 at 03:17 -0700, David Brownell wrote:
> >> On Wednesday 17 June 2009, Zach Welch wrote:
> >>> --- src/target/trace.h (working copy)
> >>> +++ src/target/trace.h (working copy)
> >>> @@ -28,7 +28,7 @@
> >>> typedef struct trace_point_s
> >>> {
> >>>uint32_t address;
> >>> - u64 hit_counter;
> >>> + uint64_t hit_counter;
> >>> } trace_point_t;
> >>>
> >>> typedef struct trace_s
> >>
> >> On x86_64 builds I now get:
> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper -
> >> I../../src/jtag -I../../src/xsvf -I/usr/local/include -Wall -
> >> Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -
> >> Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT
> >> trace.lo -MD -MP -MF .deps/trace.Tpo -c trace.c -o trace.o
> >> cc1: warnings being treated as errors
> >> trace.c: In function ‘handle_trace_point_command’:
> >> trace.c:63: warning: format ‘%lld’ expects type ‘long long int’,
> >> but argument 4 has type ‘uint64_t’
> >> make[3]: *** [trace.lo] Error 1
> >> make[3]: *** Waiting for unfinished jobs
> >>
> >> Making it "%llu" doesn't help. I guess this is one of the ways
> >> that the previous "u64" behaved differently from "uint64_t"...
> >
> > I found this myself and just committed a patch to fix it, but I simply
> > use a cast. There probably is a better way, but this fixes the build
> > for now. Fortunately, this is the only variable in the tree that uses
> > the uint64_t type, so the consequences should be minor.
> >
> > Cheers,
> >
> > Zach
> >
> > ___
> > Openocd-development mailing list
> > Openocd-development@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/openocd-development
>
> The proper fix is to use the PRId64 format string provided by
> inttypes.h. The PRI* macros exist to provide the correct format
> string for the uint*_t types. The problem is that the size of long
> changes between 32-bit and 64-bit x86 processors. For 32-bit, you get
> a 64-bit number via long long, but for 64-bit, you only need long.
> PRId64 will change appropriately to handle that depending on the
> target architecture.
Ack.
> It looks like inttypes.h should be included in types.h, but it will
> also need tests added to configure.
Actually, think inttypes.h can replace stdint.h, since the later is
included by the former.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
Freddie Chopin wrote: > As Michael wrote to me, you actually need a hacked version of > libusb0.sys for any composite USB device (FT2232) to work... It's just > asking for trouble IMHO... > > http://www.nabble.com/LibUSB---composite-USB-devices-td11027391.html > I already have libusb working fine on windows with jlink. Now I am trying to add libftdi. I have built and installed enough of libftdi to enable a build of openocd with --enable-ft2232_libftdi. And I installed the new libusb0.sys described above. When I plug in the USB from the olimex arm-usb-ocd, a driver installation dialog pops up (which I have so far ignored) and I see the "Olimex OpenOCD JTAG" device detected in device manager. Then when I run openocd I get the "device not found" message as Freddie originally described. Do I still need to install the proprietary driver from the olimex CD? I thought that installing libusb and libftdi on windows would be enough. -gene ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gdb error: Error: Load failed
Freddie Chopin wrote: > Gene Smith pisze: >> Uh...never mind. Apparently I had some bad instances of gdb and/or >> insight for windows (e.g, GNUARM). When I rebuilt gdb and insight using >> mingw32 package on fedora 11 it works OK. > > Use CodeSourcery G++ Lite > That's what I am using (their source packages and build script modified to cut out the proprietary stuff) with insight added. P/S: What does the 4\/3!! mean? Do you play the piano? :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gdb error: Error: Load failed
Gene Smith pisze: > Uh...never mind. Apparently I had some bad instances of gdb and/or > insight for windows (e.g, GNUARM). When I rebuilt gdb and insight using > mingw32 package on fedora 11 it works OK. Use CodeSourcery G++ Lite 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 9/11] Transform 'u64' to 'uint64_t'
On Jun 18, 2009, at 3:47 AM, Zach Welch wrote:
On Thu, 2009-06-18 at 03:17 -0700, David Brownell wrote:
On Wednesday 17 June 2009, Zach Welch wrote:
--- src/target/trace.h (working copy)
+++ src/target/trace.h (working copy)
@@ -28,7 +28,7 @@
typedef struct trace_point_s
{
uint32_t address;
- u64 hit_counter;
+ uint64_t hit_counter;
} trace_point_t;
typedef struct trace_s
On x86_64 builds I now get:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper -
I../../src/jtag -I../../src/xsvf -I/usr/local/include -Wall -
Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -
Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT
trace.lo -MD -MP -MF .deps/trace.Tpo -c trace.c -o trace.o
cc1: warnings being treated as errors
trace.c: In function ‘handle_trace_point_command’:
trace.c:63: warning: format ‘%lld’ expects type ‘long long int’,
but argument 4 has type ‘uint64_t’
make[3]: *** [trace.lo] Error 1
make[3]: *** Waiting for unfinished jobs
Making it "%llu" doesn't help. I guess this is one of the ways
that the previous "u64" behaved differently from "uint64_t"...
I found this myself and just committed a patch to fix it, but I simply
use a cast. There probably is a better way, but this fixes the build
for now. Fortunately, this is the only variable in the tree that uses
the uint64_t type, so the consequences should be minor.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
The proper fix is to use the PRId64 format string provided by
inttypes.h. The PRI* macros exist to provide the correct format
string for the uint*_t types. The problem is that the size of long
changes between 32-bit and 64-bit x86 processors. For 32-bit, you get
a 64-bit number via long long, but for 64-bit, you only need long.
PRId64 will change appropriately to handle that depending on the
target architecture.
It looks like inttypes.h should be included in types.h, but it will
also need tests added to configure.
--
Rick Altherr
kc8...@kc8apf.net
"He said he hadn't had a byte in three days. I had a short, so I split
it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] gdb error: Error: Load failed
Gene Smith wrote: > I now have a problem on windows (ok on linux) that when I do a load of > my elf file (to flash on cortex m3) I get the errors on openocd: > > Error: AHBAP Cached values: dp_select 0x0, ap_csw 0xa212, ap_tar > 0x > Error: SWJ-DP STICKY ERROR > Error: Read MEM_AP_CSW 0x2352, MEM_AP_TAR 0x804 > Error: AHBAP Cached values: dp_select 0x0, ap_csw 0xa212, ap_tar > 0x > Error: SWJ-DP STICKY ERROR > Error: Read MEM_AP_CSW 0x2352, MEM_AP_TAR 0x804 > Warn : Block write error address 0x800, wcount 0x79 > Error: unexpected error -107 Uh...never mind. Apparently I had some bad instances of gdb and/or insight for windows (e.g, GNUARM). When I rebuilt gdb and insight using mingw32 package on fedora 11 it works OK. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
On Thu, Jun 18, 2009 at 9:43 PM, Michael Fischer wrote: > Hello Freddie, > > upps, in case of performance I have tested here only > download to RAM. And this looks like the same, 140 KB/sec. > > Btw, an old OpenOCD, r657, had a performance of about 165 KB/sec: That narrows down the regression to ~1000 commits or so :-) Any chance of a bisection? -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
Michael Fischer pisze: > upps, in case of performance I have tested here only > download to RAM. And this looks like the same, 140 KB/sec. Unfortunately, I have no chips with external RAM, so I cannot test that kind of speed - STM32 I have has only 20kB, so the upload speed result will be worthless IMHO At work I have a STM32-EVAL-E, which (I think) has some external RAM, so maybe I'll test that too. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD + libftdi on Windows
Hello Freddie, upps, in case of performance I have tested here only download to RAM. And this looks like the same, 140 KB/sec. Btw, an old OpenOCD, r657, had a performance of about 165 KB/sec: http://www.yagarto.de/projects/jtagspeed/index.html Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
As Michael wrote to me, you actually need a hacked version of libusb0.sys for any composite USB device (FT2232) to work... It's just asking for trouble IMHO... http://www.nabble.com/LibUSB---composite-USB-devices-td11027391.html Add that libusb cannot be compiled on Windows and you need to use libusb-win32, which is 2 y.o. now and only 0.1.12... When someday OpenOCD switches to newer libusb, what will happen to windows support? Will that be dropped, for the sake of GPL? Anyway, about that "equal" performance with libftdi: Tested with a ~29kB image on LPC2103 (upload to flash): libftdi: > Start address 0x3c, load size 29640 > Transfer rate: 6 KB/sec, 14820 bytes/write. ftd2xx: > Start address 0x3c, load size 29640 > Transfer rate: 15 KB/sec, 14820 bytes/write. So: libftdi is 2.5x slower Tested with ~114kB image on STM32 (upload to flash): libftdi: > Start address 0x8000134, load size 114432 > Transfer rate: 8 KB/sec, 16347 bytes/write. ftd2xx: > Start address 0x8000134, load size 114432 > Transfer rate: 11 KB/sec, 16347 bytes/write. Again slower, this time only about 30%, but still, that's nowhere to "comparable" 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD + libftdi on Windows
First of all let me state that if one considers building OpenOCD with ftd2xx on Windows hard, than building that with libftdi is extreme... I really don't know whether I've done that right... Now - my question: How do I use that? I've just managed to compile OpenOCD r2268 with libftdi and libusb-win32. I've also compiled the same revision with ftd2xx. I have a custom build JTAGkey. The ftd2xx version just works, the one with libftdi just doesn't. I've installed the filter driver for libftdi on my system, and I had to uninstall it using just the keyboard, so the first thing I did with my regained mouse was deleting that crap. I downloaded the "device" driver, there is a wizard which creates a driver for you. The created driver is worthless. The driver which Michael Fisher posted a few days ago does install, but OpenOCD still doesn't work with it... Whatever I do I always get: > Error: unable to open ftdi device: device not found > Runtime error, file "command.c", line 469: So - how is that possible to use that library? I'm just a bit ironic, most of all I would like to make it to work... Thx for help... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
Hello List, have you make a decision if the next official release will build on FTD2XX or on libftdi? Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 9/11] Transform 'u64' to 'uint64_t'
On Jun 18, 2009, at 13:47, Zach Welch wrote:
> On Thu, 2009-06-18 at 03:17 -0700, David Brownell wrote:
>>
>> On x86_64 builds I now get:
>> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper -
>> I../../src/jtag -I../../src/xsvf -I/usr/local/include -Wall -
>> Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -
>> Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT
>> trace.lo -MD -MP -MF .deps/trace.Tpo -c trace.c -o trace.o
>> cc1: warnings being treated as errors
>> trace.c: In function ‘handle_trace_point_command’:
>> trace.c:63: warning: format ‘%lld’ expects type ‘long long int’,
>> but argument 4 has type ‘uint64_t’
>> make[3]: *** [trace.lo] Error 1
>> make[3]: *** Waiting for unfinished jobs
>>
>> Making it "%llu" doesn't help. I guess this is one of the ways
>> that the previous "u64" behaved differently from "uint64_t"...
> I found this myself and just committed a patch to fix it, but I simply
> use a cast. There probably is a better way, but this fixes the build
> for now. Fortunately, this is the only variable in the tree that uses
> the uint64_t type, so the consequences should be minor.
The stardands-conforming formatting string would be "%" PRIu64 (eg.
printf("var is %" PRIu64 "\n", mybigvar); )
In the C99 standard draft, these formatting specifiers are described
in section 7.8.
Regards,
Anders Montonen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] r2269 build error (need --disable-werror ?)
On Thu, 2009-06-18 at 09:37 -0400, Gene Smith wrote: > Zach Welch wrote: > > On Wed, 2009-06-17 at 18:17 -0400, Gene Smith wrote: > >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper > >> -I../../src/target -g -O2 -Wall -Wstrict-prototypes -Wformat-security > >> -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align > >> -Wredundant-decls -Werror -MT tcl.lo -MD -MP -MF .deps/tcl.Tpo -c tcl.c > >> -o tcl.o > >> tcl.c: In function `handle_irscan_command': > >> tcl.c:1222: warning: passing arg 2 of `parse_u32' from incompatible > >> pointer type > >> make[3]: *** [tcl.lo] Error 1 > >> make[3]: Leaving directory `/cygdrive/c/openocd-0.1.0/trunk/src/jtag' > > > > Please let me know if you still see these problems with r2284. > > > > Cheers, > > > > Zach > > OK on latest (> r2284). However, after configure, I still need to > manually change ECHO= to echo= in libtool when build in cygwin. Is it > just me? It relates to version conflicts between 'libtool --version' and './libtool --version', which you reported do not match. I do not know what causes you to get mismatched versions, though, and I expect that we would getting more reports if others could reproduce this. However, you should be able to find the same reports that Google found for me, as this does seem to be a repeatable problem in the broader community. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] jtag_add_callback() change
The "in" argument should be changed to type jtag_callback_data_t. It is entirely up to the caller what this points to and what it is used for. So change from: extern void jtag_add_callback4(jtag_callback_t f, uint8_t *in, jtag_callback_data_t data1, jtag_callback_data_t data2, jtag_callback_data_t data3); To: extern void jtag_add_callback4(jtag_callback_t f, jtag_callback_data_t data0, jtag_callback_data_t data1, jtag_callback_data_t data2, jtag_callback_data_t data3); I spotted this in the embedded host. This will also resolve a few warnings in embedded hosts where jtag_add_callback4 is just a macro that invokes the callback directly. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] r2269 build error (need --disable-werror ?)
Zach Welch wrote: > On Wed, 2009-06-17 at 18:17 -0400, Gene Smith wrote: >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper >> -I../../src/target -g -O2 -Wall -Wstrict-prototypes -Wformat-security >> -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align >> -Wredundant-decls -Werror -MT tcl.lo -MD -MP -MF .deps/tcl.Tpo -c tcl.c >> -o tcl.o >> tcl.c: In function `handle_irscan_command': >> tcl.c:1222: warning: passing arg 2 of `parse_u32' from incompatible >> pointer type >> make[3]: *** [tcl.lo] Error 1 >> make[3]: Leaving directory `/cygdrive/c/openocd-0.1.0/trunk/src/jtag' > > Please let me know if you still see these problems with r2284. > > Cheers, > > Zach OK on latest (> r2284). However, after configure, I still need to manually change ECHO= to echo= in libtool when build in cygwin. Is it just me? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] symbol cleanup
Hi all, For my next trick with my Surpass tool, I intend to try and bring more uniformity to the various OpenOCD APIs. This primarily translates to renaming functions such that they group and sort better, but it should also involve structure and enum names. We could even go so far replace instances of 'struct blah *' and 'blah_t *' with new 'blah_p' types. These kinds of transformations can be turned into a new chain of patch series, by providing a list of simple search and replace expressions. Examples of these expressions are provided in the commit comments of my recent series of patches, though most of those are probably more complex than what will be needed for this type of simple symbol rework. Please reply to this thread with suggestions for symbols changes that can be accomplished in this manner. Specifically, please provide lines of text that meet following the criteria: 0) Two columns of text, separated by a TAB character: 1) Column 1: regex suitable for grep and LHS of "sed -e 's,LHS,RHS,g'" 2) Column 2: pattern suitable for RHS of "sed -e 's,LHS,RHS,g'" For example, I have the following symbols on my hit list already, which should come through in this required format (attach it, if in doubt): jtag_register_event_callbackjtag_event_callback_register jtag_unregister_event_callback jtag_event_callback_unregister jtag_call_event_callbackjtag_event_callbacks_run These changes reflect a very simple heuristic: name components should be ordered from the most general to most specific. The following naming schemes should demonstrate this model with more clarity: module_noun_verb module_primary_secondary_verb module_primary_secondary_phase_step module_structure_field_verb With this scheme, related symbols will be grouped properly when sorted in the documentation. By extension, this will help developers learning the code, because names will become easily derivable from related constructs. I can provide numerous other examples in the code where this general guideline could be followed, but I can also find places where it would be idiosyncratic when applied. Put another way, this rule does not suffice on its own, but I think it worth giving some consideration before the 0.2.0 release. While each function merits independent consideration for its name, this heuristic provides a unified style with some clear benefits, but other schemes would work. We need to have agreed upon these high-level standards before the repository sees any renaming changes committed, and I this will emerge from the suggestions provided under this thread. I hope the community contributes ideas, so I can collate the feedback into appropriate series scripts. This may be a Sisyphean task overall, but the low-hanging fruit are overripe and must be picked to avoid rot. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 9/11] Transform 'u64' to 'uint64_t'
On Thu, 2009-06-18 at 03:17 -0700, David Brownell wrote:
> On Wednesday 17 June 2009, Zach Welch wrote:
> > --- src/target/trace.h (working copy)
> > +++ src/target/trace.h (working copy)
> > @@ -28,7 +28,7 @@
> > typedef struct trace_point_s
> > {
> > uint32_t address;
> > - u64 hit_counter;
> > + uint64_t hit_counter;
> > } trace_point_t;
> >
> > typedef struct trace_s
>
> On x86_64 builds I now get:
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper
> -I../../src/jtag -I../../src/xsvf -I/usr/local/include -Wall
> -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter
> -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT trace.lo -MD
> -MP -MF .deps/trace.Tpo -c trace.c -o trace.o
> cc1: warnings being treated as errors
> trace.c: In function ‘handle_trace_point_command’:
> trace.c:63: warning: format ‘%lld’ expects type ‘long long int’, but argument
> 4 has type ‘uint64_t’
> make[3]: *** [trace.lo] Error 1
> make[3]: *** Waiting for unfinished jobs
>
> Making it "%llu" doesn't help. I guess this is one of the ways
> that the previous "u64" behaved differently from "uint64_t"...
I found this myself and just committed a patch to fix it, but I simply
use a cast. There probably is a better way, but this fixes the build
for now. Fortunately, this is the only variable in the tree that uses
the uint64_t type, so the consequences should be minor.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 9/11] Transform 'u64' to 'uint64_t'
On Wednesday 17 June 2009, Zach Welch wrote:
> --- src/target/trace.h (working copy)
> +++ src/target/trace.h (working copy)
> @@ -28,7 +28,7 @@
> typedef struct trace_point_s
> {
> uint32_t address;
> - u64 hit_counter;
> + uint64_t hit_counter;
> } trace_point_t;
>
> typedef struct trace_s
On x86_64 builds I now get:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper -I../../src/jtag
-I../../src/xsvf -I/usr/local/include -Wall -Wstrict-prototypes
-Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast
-Wcast-align -Wredundant-decls -Werror -MT trace.lo -MD -MP -MF .deps/trace.Tpo
-c trace.c -o trace.o
cc1: warnings being treated as errors
trace.c: In function ‘handle_trace_point_command’:
trace.c:63: warning: format ‘%lld’ expects type ‘long long int’, but argument 4
has type ‘uint64_t’
make[3]: *** [trace.lo] Error 1
make[3]: *** Waiting for unfinished jobs
Making it "%llu" doesn't help. I guess this is one of the ways
that the previous "u64" behaved differently from "uint64_t"...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] - Replace 'if(' with 'if ('.
On Thu, 2009-06-18 at 00:43 -0700, David Brownell wrote: > One of my pet peeves with this source base! Glad to see this stuff > vanishing on a more wholesale basis. Clearly, it was one of mine... to the extent that I wrote a new tool to manage the process of producing chains of patches that affect this kind of wholesale change. These series helped prove many of the ideas of what I am now calling Surpass (from the acronym: Surpass Usually Replaces Patch and Series Scripts). I will post a new thread shortly to outline my additional plans for using this new power tool on OpenOCD. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/5] - Replace 'if(' with 'if ('.
One of my pet peeves with this source base! Glad to see this stuff vanishing on a more wholesale basis. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] r2269 build error (need --disable-werror ?)
On Wed, 2009-06-17 at 18:17 -0400, Gene Smith wrote: > gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper > -I../../src/target -g -O2 -Wall -Wstrict-prototypes -Wformat-security > -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align > -Wredundant-decls -Werror -MT tcl.lo -MD -MP -MF .deps/tcl.Tpo -c tcl.c > -o tcl.o > tcl.c: In function `handle_irscan_command': > tcl.c:1222: warning: passing arg 2 of `parse_u32' from incompatible > pointer type > make[3]: *** [tcl.lo] Error 1 > make[3]: Leaving directory `/cygdrive/c/openocd-0.1.0/trunk/src/jtag' Please let me know if you still see these problems with r2284. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
