On Sun, 2009-06-21 at 07:08 +0300, Oleksandr Tymoshenko wrote:
> Resume command works only if resume address is provided. Attached patch
> fixes this problem
Thanks for catching this; sorry for breaking it during my cleanup.
Committed, r2348.
--Z
___
On Sat, 2009-06-20 at 23:35 -0400, Duane Ellis wrote:
> Commits - r2296 - through 2347 - are commits that fix "printf()"
> -Werrors so that Cygwin will build.
>
> These where done (for the most part) as one file per commit so that if a
> specific issue arises, it can be reverted.
> This is a *na
Resume command works only if resume address is provided. Attached patch
fixes this problem
--
gonzo
Index: src/target/target.c
===
--- src/target/target.c (revision 2347)
+++ src/target/target.c (working copy)
@@ -1996,6 +1996,7 @@
Commits - r2296 - through 2347 - are commits that fix "printf()"
-Werrors so that Cygwin will build.
These where done (for the most part) as one file per commit so that if a
specific issue arises, it can be reverted.
This is a *nasty* bunch of mechanical changes... Agh...
FYI - anyone writing a
On Sun, Jun 21, 2009 at 2:20 AM, Zach Welch wrote:
> On Sat, 2009-06-20 at 20:05 +0200, Michael Schwingen wrote:
>> Zach Welch wrote:
>> >> BTW: one possible solution for 64-bit windows would be to ship an
>> >> openocd appliance - ie. a VM image containing a minimal linux system
>> >> together wit
On Sun, Jun 21, 2009 at 4:53 AM, David Brownell wrote:
> As I said, I won't object to such fixes. But at the same time, it's
> worth realizing that it's been quite a few years since much general
> purpose code has worked on 16-bit CPUs. Even Intel is working on
> moving away from BIOS boot code t
Also by the way, what do these error messages mean ?:
Error: SWJ-DP STICKY ERROR
Error: dcb_dhcsr 0x30003, nvic_shcsr 0x2, nvic_cfsr 0x0, nvic_bfar
0xe000edf8
On Sat, Jun 20, 2009 at 4:19 PM, Joseph Kuss wrote:
> Dear sirs,
>
> I have a Luminary LM3S6918 with 64k ram, 256k flash,
> Has an
On Saturday 20 June 2009, Rick Altherr wrote:
> I agree that fixing all the portability issues isn't easy and isn't
> strictly necessary for any particular future release. I'd just like
> to see us progress in that direction when making fixes for data
> types. If you need to fix a printf fo
On Jun 20, 2009, at 11:05 AM, David Brownell wrote:
On Saturday 20 June 2009, Duane Ellis wrote:
I assert that is specifically *not* a goal of openocd to build
and run openocd on *HOSTS* where the host basic compiler types
"int" and "unsigned int" are *less*then* then 32bits.
True of false?
On Jun 20, 2009, at 6:16 AM, Duane Ellis wrote:
rick> For example, in your case:
duane> uint32_t x;
duane> void funny_function( uint32_t );
duane>
duane> for( x = 0 ; x < 10 ; x++ ){
duane>printf(" X = %d, Calling funny function\n", (int)(x));
duane> funny_function( x )
Hello List,
I have changed the default value for "want_ftd2xx_highspeed"
from "maybe" to "no".
In case of maybe, it makes problem here with a normal JTAGkey.
Best regards,
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.
On Sat, 2009-06-20 at 20:05 +0200, Michael Schwingen wrote:
> Zach Welch wrote:
> >> BTW: one possible solution for 64-bit windows would be to ship an
> >> openocd appliance - ie. a VM image containing a minimal linux system
> >> together with openocd & libraries.
> >>
> >> Users would need to in
On Friday 19 June 2009, Dirk Behme wrote:
> Seems to work :) THANKS!!
Good. I look forward to seeing more things start to work
there ... and the next release after 0.2.0 having some
support for Cortex-A8! :)
- Dvae
___
Openocd-development mailing lis
Zach Welch wrote:
>> BTW: one possible solution for 64-bit windows would be to ship an
>> openocd appliance - ie. a VM image containing a minimal linux system
>> together with openocd & libraries.
>>
>> Users would need to install VMware player or SUN Virtualbox to use that,
>> but would get a c
On Saturday 20 June 2009, Duane Ellis wrote:
> I assert that is specifically *not* a goal of openocd to build
> and run openocd on *HOSTS* where the host basic compiler types
> "int" and "unsigned int" are *less*then* then 32bits.
>
> True of false?
IMO: true.
Not that I'd object to merging p
On Sat, 2009-06-20 at 14:24 +0200, Michael Schwingen wrote:
> Michael Fischer wrote:
> > The instruction can be found here, and use libftdi and libftd2xx:
> > http://forum.sparkfun.com/viewtopic.php?t=11221
> >
> > But the problem is that the normal user want to have a working solution
> > and do n
Freddie Chopin wrote:
>> I do not see why users would choose not to
>> use the new version?
>>
>
> Just because thousands of users already have a 0.1.0 release compiled
> with ftd2xx support. The performance is more or less the same, old
> version supports one's JTAG without problems, new v
Freddie Chopin wrote:
> Kees Jongenburger pisze:
>
>> 99% of the open-source people are happy they are liberated
>> from the need to use warez craks and other stuff.
>>
>
> Liberated to a prison of GPL... That's a dream-liberty indeed, as you
> see in this discussion.
>
For you.
I have
On Fri, Jun 19, 2009 at 6:26 PM, Duane Ellis wrote:
> >> I think we should start to collect the inf files too?
>
> Agree, it would be nice to have a "libusb" - INF file for all ftdi based
> chips that point to libusb :-)
I tend to believe this is possible. Just need to collect the different
VID/
Hello List,
Thomas A. Moulton wrote:
>And to answer who could be sued? Well if a business takes a non-GPL
>complaint tool and redistributes it, then they could be at risk.
>So yes the developers are right to be GPL purists, it does matter!
I have now removed my OpenOCD installer and will come bac
On Sat, Jun 20, 2009 at 10:53 PM, Thomas A. Moulton wrote:
> If libusb and libftdi works, then please build it and make it available
> so it can be used.
I believe it can work under the platforms where libusb-win32 device
driver works (Win 2K, Windows XP 32/64bit, Vista 32bit). It is
not so simple
On Fri, Jun 19, 2009 at 2:26 AM, Freddie Chopin wrote:
> 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
On Sat, 2009-06-20 at 11:13 +0800, Xiaofan Chen wrote:
> On Fri, Jun 19, 2009 at 3:36 AM, Freddie Chopin wrote:
> > Anyway, about that "equal" performance with libftdi:
> > Tested with a ~29kB image on LPC2103 (upload to flash):
> >
> > libftdi:
> > > Start address 0x3c, load size 29640
> > > Tra
Freddie Chopin wrote:
> whole GPL situation here looks to me like:
>
> - Don't do this!
> - Why?
> - Just because I say so!
>
> You cannot buy drugs but you can produce them at home for your personal
> use? I don't think so... Forged money? Guns? Nuclear weapons?
Legal rules are not based on lo
rick> For example, in your case:
duane> uint32_t x;
duane> void funny_function( uint32_t );
duane>
duane> for( x = 0 ; x < 10 ; x++ ){
duane>printf(" X = %d, Calling funny function\n", (int)(x));
duane> funny_function( x ) ;
duane> }
rick> Casting to int is fine as long as i
Freddie Chopin pisze:
> The performance is more or less the same
Just to be clear - I meant the performance with ftd2xx because
performance with libftdi is way lower. Another reason not to change...
4\/3!!
___
Openocd-development mailing list
Openocd-d
Michael Schwingen pisze:
> I do not see why users would choose not to
> use the new version?
Just because thousands of users already have a 0.1.0 release compiled
with ftd2xx support. The performance is more or less the same, old
version supports one's JTAG without problems, new version require
Michael Fischer wrote:
> The instruction can be found here, and use libftdi and libftd2xx:
> http://forum.sparkfun.com/viewtopic.php?t=11221
>
> But the problem is that the normal user want to have a working solution
> and do not / can not build OpenOCD by itself.
>
> I think if libftdi will be use
duane> (3) and thus, target addresses are generally equal to - or
duane> smaller then the host "unsigned integers"
zach> This is why we have intptr_t. The code shouldn't care.
zach> It's a bug if it does.
I believe you are mistaken, what you are looking for is: TARGET_intptr_t
not HOST_intptr_
On Sat, Jun 20, 2009 at 12:48 PM, Gene Smith wrote:
> Xiaofan Chen wrote, On 06/19/2009 07:35 PM:
>
>> Glad to hear that OpenOCD works with the libusb-win32/libftdi
>> combination.
>>
>> As for the com port, if it is part of the device, then using libusb-win32
>> device driver (as the driver of the
On Sat, Jun 20, 2009 at 12:45 PM, Freddie Chopin wrote:
> Kees Jongenburger pisze:
>> 99% of the open-source people are happy they are liberated
>> from the need to use warez craks and other stuff.
>
> Liberated to a prison of GPL... That's a dream-liberty indeed, as you
> see in this discussion.
Zach Welch wrote:
> On Fri, 2009-06-19 at 18:26 +0200, Harald Kipp wrote:
>> Dynamic linking to proprietary libraries by adding LoadLibrary and
>> GetProcAddress to OpenOCD is a gray area. While the FSF would not allow
>> this, some lawyers may have a different view.
>
> The big problem with gray
Kees Jongenburger pisze:
> 99% of the open-source people are happy they are liberated
> from the need to use warez craks and other stuff.
Liberated to a prison of GPL... That's a dream-liberty indeed, as you
see in this discussion.
4\/3!!
___
Openocd-
> And another thing - do you really believe, that no-one will create such
> binary and distribute that somehow (torrent, rapidshare, forum or
> whatever)? 99% of ppl don't care about GPL...
99% of the open-source people are happy they are liberated
from the need to use warez craks and other stuff.
Some more questions: What's the difference between distributing a binary
with ftd2xx.dll and allowing user to create such binary by himself? This
whole GPL situation here looks to me like:
- Don't do this!
- Why?
- Just because I say so!
You cannot buy drugs but you can produce them at home for
Michael Fischer pisze:
> OpenOCD comes in a libftdi version, but at the same time there
> is a binary patch program available. Now the user can decide if
> they want to use the libfti or "build" his own ftd2xx version.
A "crack" for OpenOCD <: That's brilliant <:
I understand, that there is nothi
Hello List,
as I understand it correct, a private build with FTD2XX is correct!
In this case we give the user the possibility to make a private
build in a easy way.
OpenOCD comes in a libftdi version, but at the same time there
is a binary patch program available. Now the user can decide if
they
Zach Welch pisze:
> The big problem with gray areas is that you can be sued anyway
And who is going to sue the developers of OpenOCD? Really - aren't you
talking about a non-existent imaginary enemy that will never show up?
> Inevitably, that means that you will be back to
> complying with the t
Hello List,
>But as it stands now, FTD2XX library is the nature choices for Windows
>users. So probably a more detailed document to build OpenOCD
>under Windows with FTD2XX is needed. The GPL issue can be highlighted
>and that the users can only use it as a private build and not distribute
the
>bi
39 matches
Mail list logo
