Hi,
I was the maintainer of libusb when Zadig came to be.
Zadig is not part of the libusb project, but the its origin is code
and discussion in the libusb project, which became the libwdi
project.
Liviu Ionescu wrote:
> it looks like I am missing something with the usb configurations.
> I chec
Hi Mindy,
Mindy Beseler wrote:
> Thanks so much for taking the time to answer all these, I know,
> rather stupid questions! This does clear things up.
They're not stupid - they're good questions. It's not at all obvious
what is going on with the various git commands when starting out.
I find th
Hi Mindy,
Mindy Beseler wrote:
> git pull ssh://mbese...@openocd.zylin.com:29418/openocd refs/changes/11/2411/2
>
> On a branch that's pointing to the 0.9.0 tag I expected the only
> diffs to be what's listed in the commit message.
>
> I'm just focusing on the mips files. I ok with other files
Hi Mindy,
Mindy Beseler wrote:
> I'm working on reviewing the mips patches
Thanks for that.
> and just started with a couple easier/simpler patches, these three
> patches now have all issues addressed: 2305, 2350, and 2400.
> What's needed to move these patches to a +2?
Spare time of unpaid vo
Matt Campbell wrote:
> this seems like a very simple case.
Sure, I'm not opposed, but am saying that software needs to be a
factor in the hardware decision, because that's too rare and so a
lot of life is wasted on pragmatic workarounds for sometimes quite
unneccessary problems.
//Peter
---
Daniel Glöckner wrote:
> I guess you are on Freescale's v3.14.28 release? Yeah, it sucks
> that they don't bother to merge linux-stable into their official
> tree.
Don't bother with (and don't support!) vendors who don't do mainline.
//Peter
-
Matt Campbell wrote:
> They output '0' from the 'value' sysfs entry when low, but they only
> seem to gaurentee non-zero output for high. It looks like they are
> simply masking the gpio value register with the requested gpio
> position and returning that (e.g. 0x400 rather than getting 1
..
> +++
Bernard Dautrevaux wrote:
> By the way Remi Prud'Homme is the guy at ST that develops the changes needed
> to OpenOCD and transfer us the various patches to apply to OpenOCD to add
> support for their new chips. He also pushes these patches through Gerrit so
> that they may be included in the offic
Duane,
Duane Ellis wrote:
> Before we say “violation” and run around as if our hair was on fire
> fire, we need to ask them where the source code is (Gently) and
> give them time to respond.
Please read the GPL more carefully. Freddie's mail makes it quite
clear to me that this is a violation of
Ellis, Duane wrote:
> Specifically looking for means to
> Build MingGW - on a linux host
You need to study how to cross-compile packages which use autotools
(autoconf and automake) and pkg-config.
This isn't a topic that the OpenOCD community can or should teach you
on, it's out
Peter Stuge wrote:
> the responsibility and yes burden for contribution really lies with
> the contributor.
It's essentially the same human behavior as in other (offline) groups.
A person entering into an unknown group consciously or unconsciously
demonstrates their compatibility wit
Hi,
Albert ARIBAUD wrote:
> > > This doesn't sound very encouraging for the project in general. :-(
> >
> > It's essentially the contributor's task to make it effortless for
> > maintainers to accept contributions.
>
> Maybe not effortless but as easy as reasonable, certainly.
Yes effortless.
David Ung wrote:
> This doesn't sound very encouraging for the project in general. :-(
It's essentially the contributor's task to make it effortless for
maintainers to accept contributions.
That can be really difficult if contributions touch on complex issues.
//Peter
Ellis, Duane wrote:
> Duane> Can somebody explain why the 64bit changes have not yet been merged
> into the main line?
>
> Duane> What are the roadblocks to making this happen?
>
> Duane> What can be done to make these changes "mainline"?
>
> Any comments?
All open source projects work exactly
De Cesaris, Ivan wrote:
> It's normal, in the lifetime of new Si, that information
> classification (how sensitive is the IP) starts from a high level
> even if the product will eventually become public.
I think this is the real problem that you need to resolve..
> By having the license we have
Ellis, Duane wrote:
> Any other comments?
Just to make a proposal if you want to work on something.
//Peter
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring s
Felipe Balbi wrote:
> "generic" libraries with well defined API.
Yes.
> I don't mind having turing-complete expressions. In fact I find it very
> nice that we can pretty much program openocd to do whatever we want.
It's not really possible to refactor the language operators if the
expressions c
Ellis, Duane wrote:
> You've been around for a while, and are active now what do you
> think the road map should be? What do you think is doable? And supportable?
I'd start clean with an accurate model of the various debug IPs, with
one of the design goals being to reuse as much interface and targ
Ellis, Duane wrote:
> good roadmap decision
OpenOCD is almost completely grown software. It was originally pure
student code, and has been modified a little here and a little there
by many different contributors with generally little investment, over
a long period of time.
//Peter
-
Ellis, Duane wrote:
> We are interested in learning what your plans are more formally.
I don't think there are such plans, nor a roadmap.
I think you should consider that your ideas amount to a rewrite of a
large portion of OpenOCD, and then it might be better to simply start
from scratch.
//Pe
Freddie Chopin wrote:
> What's the deal with openocd.de website? Is this official?
Both .de and .org are registered by an old contributor.
//Peter
--
Dive into the World of Parallel Programming The Go Parallel Website,
Ed Beroset wrote:
> I'm trying to get this working for a class I'm teaching next week
> and I'd rather use real hardware than an emulator. Unfortunately,
> without reset and resume working, I don't seem to be able to use
> gdb with this part. If there's a workaround or something else I
> should tr
Paul Fertser wrote:
> > 1. Do all developers (contributors and core developers) have to
> > submit a code review for every change? I’m asking because many
> > projects only review changes made by contributors.
>
> Every (except for the two special "new release" and "restore normal
> development")
Liviu Ionescu wrote:
> > What is harmful and useless to me is a feature to someone else. :\
>
> hmmm... harmful means "causing or likely to cause harm";
>
> > I think you should remove --enable-legacy-ft2232_libftdi because the
> > ft2232 driver really shouldn't be used anymore.
>
> is this harm
Liviu Ionescu wrote:
> I appreciate that we finally agreed on something, but, in practical
> terms, what is the complete options list to be used, with harmful
> and useless options removed?
I don't think there's a one-size-fits-all. What is harmful and
useless to me is a feature to someone else. :
Liviu Ionescu wrote:
> - which options are harmful and should be removed?
I think you should remove --enable-legacy-ft2232_libftdi because the
ft2232 driver really shouldn't be used anymore.
> - are there any other options that might be added?
> (I would explicitly use all options available, even
Andreas Fritiofson wrote:
> perhaps it makes sense to add a --with-libusb1 etc, that requires
> successful detection of the libraries
Very much so.
//Peter
--
Dive into the World of Parallel Programming. The Go Parallel
Liviu Ionescu wrote:
> > libusb-win32 isn't really neccessary for you to build - it is only
> > neccessary for the kernel driver.
>
> it was required by openocd, when using the configure options I
> mentioned previously.
Ah, all right. Normally, libusb-compat-0.1 would be preferable to
libusb-win
Liviu Ionescu wrote:
> my experience with windows drivers is close to null,
Then study.
> and, after reading your links, my understanding is that now some of
> the devices no longer work unless Zadig is installed. can you confirm this?
Zadig is a tool which can be used to install drivers. It is
Uwe Bonnes wrote:
> They all stack on each other, so compiling them independand will fail.
Each commit along the way needs to build and work correctly, as long
as previous commits have been applied.
Paul is right that Gerrit does track dependencies, but the UI could
be better.
//Peter
Hello and welcome,
strong qu wrote:
> If we plan to contribute changes to OpenOCD, is there a test suite we can
> run trhough to verify our changes? Say if we implement ARMv8/AArch64
> support, how can we make sure the change won't break other device/platform?
This is a very good question, but un
Jens Bauer wrote:
> ... I think it would make sense if OpenOCD reads the OPTCR register
> and checks that it contains the right value.
Certainly, and anyone trying to say otherwise is not helping. I'm
sadly unsurprised that the check is missing in OpenOCD.
> If not, it could either...
> 1: Tell t
Kent Brinkley wrote:
> When and how to patches get merged into the trunk?
When someone has reviewed the change, given it +2 code-review and
submitted it.
> Any updates on the release date of 0.9.0?
It could be any number of years.
Don't worry too much. If you nag a bit on the list and maybe a
Kent Brinkley wrote:
> would like to get feedback if this is the way I should stage the release.
You should have a local branch with several commits on top of the
latest commit in origin/master.
Each commit should make one logical change to the codebase.
The codebase should build and work at eac
Kent Brinkley wrote:
> Do I make up my own number or are there rules I need to follow?
You don't neccessarily need a number. The only gotcha would be that
there is some kind of heuristic in the code which relies on this
number rather than actually knowing what is going on.
That would be incredibl
Kent Brinkley wrote:
> Sorry - What I was asking is where does one get the magic number
> from, I in the process of adding support for the m14k cores and
> believe I need to use a different number than the one defined for
> m4k core.
The number has no connection to the hardware. It is only ever se
Kent Brinkley wrote:
> What is the common_magic number used in for example in mips_m4k.h
I recommend using git grep:
$ git grep -n MIPSM4K_COMMON_MAGIC
mips_m4k.c:916: mips_m4k->common_magic = MIPSM4K_COMMON_MAGIC;
mips_m4k.c:1033:if (mips_m4k->common_magic != MIPSM4K_COMMON_MAGIC) {
mips
Hi,
vichy wrote:
> I have some questions.
> in below commit, http://openocd.zylin.com/#/c/2299/ , I found there is
> some format error and create patch B to fix it.
> Should I merge (A+B)=C, then commit C to gerrit again?
Yes, the term is to "amend" your original commit.
After doing this, you wi
Kent Brinkley wrote:
> I pulled a new copy of the repository using the instruction and
> re-applied my changes but I still not able to push them. I included
> the error message and new copy of .git/config file:
>
> openocd@ubuntu:~/openocd$ git push review
> Permission denied (publickey).
This er
Anders Oleson wrote:
> 1. Based on USB ID detect the LPC Link-2 and apply this workaround
Does the LPC Link-2 with JLink firmware have anything distinct in the
descriptors that would allow it to be distinguished from other JLink
adapters?
The driver may or may not have a good reason to do the set
Flemming Futtrup wrote:
> Is there a clever way that OpenOCD can automatically detect
No, the OpenOCD codebase just is not capable of that. As Andreas
hints to changing that would take a fair bit of work restructuring
internals to a model that matches reality. :\
Work around the problem in true U
Andrey Yurovsky wrote:
> I don't know about you but most of my logic analyzer usage is just checking
> things on a simple serial bus (SPI, I2S, I2C, UART, etc.) and the last
> thing I want to do is waste time "writing my own decoder in Python".
Flemming Futtrup wrote:
> I however still appreciate
Flemming Futtrup wrote:
> If anyone has problems understanding why JTAG is not properly
> running with their new system or want to know why commercial
> debuggers work on certain microprocessors (Renesas H8SX), I
> recommend the Salea logic analyzer.
I recommend strongly against Saleae, because th
Jens Bauer wrote:
> >> What's required in order to get rid of the "Error: session's transport
> >> is already selected." message in for instance lpc1788.cfg ?
> >
> > This suggests that lpc1788.cfg is trying to select transport *again* ?
>
> That was my impression too, but I can't seem to find wh
Jens Bauer wrote:
> What's required in order to get rid of the "Error: session's transport
> is already selected." message in for instance lpc1788.cfg ?
This suggests that lpc1788.cfg is trying to select transport *again* ?
//Peter
---
Michael Schwingen wrote:
> -AM_CONDITIONAL([USB_BLASTER_DRIVER], [test $build_usb_blaster_ftd2xx =
> yes -o $build_usb_blaster_libftdi = yes -o $use_libusb1 = yes])
>
> I am completely at a loss why this is there
Me too. I think it's bogus.
//Peter
-
Duane,
Peter Stuge wrote:
> > we could now creat a unified scripting language that is first class,
> > the same language constructs that work *end*to*end* across the debug
> > landscape.
>
> I'd like to see that happen, but I think it should start from scratch.
Duane Ellis wrote:
> we could now creat a unified scripting language that is first class,
> the same language constructs that work *end*to*end* across the debug
> landscape.
I'd like to see that happen, but I think it should start from scratch.
//Peter
--
Paul Fertser wrote:
> My personal opinion: screw environments that are not C99-conforming.
Then you can't build for MS CRT, ie. not actually a Windows program.
//Peter
--
Learn Graph Databases - Download FREE O'Reilly B
Paul Fertser wrote:
> I wouldn't be against merging it even this late
It would be a very big mistake not to include a fix.
//Peter
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definiti
Andreas Fritiofson wrote:
> I guess the bootloader is very dependent on how the copying is done
Recommend use mtools.
//Peter
--
___
OpenOCD-devel mailing list
OpenOCD-devel@l
Andreas Fritiofson wrote:
> I don't think installing a tarball should mess with the system
> configuration, which is what udev rules are.
I agree.
It's not a bad thing to install the udev file somewhere package-specific,
like $docdir (/usr/local/share/doc/openocd-*/) though.
//Peter
--
ger...@openocd.zylin.com wrote:
> jtag/aice/aice_usb: remove unused constants
Maybe there's a better way to pacify clang? It seems sad to delete
constants which might become useful later on?
//Peter
--
_
Jens Bauer wrote:
> On Sat, 29 Mar 2014 22:50:42 +0100, Andreas Fritiofson wrote:
> > Of course SWD? I thought at least LPC13xx speaks JTAG too...
>
> As far as I understand when reading the datasheet, it does not seem
> to support Flash-programming and Debugging via JTAG.
Yes, that's correct. On
Franck Jullien wrote:
> >> commit d1333b5a7b0211280fe65181de4e9b68eca6950d
> >> Author: Franck Jullien
> >> Date: Tue Mar 18 20:04:30 2014 +0100
> >>
> >> cfg: or1k_generic: allow TAP_TYPE override
> >>
> >> This patch allows users to specify TAP_TYPE from
> >> the command line when
ger...@openocd.zylin.com wrote:
> commit d1333b5a7b0211280fe65181de4e9b68eca6950d
> Author: Franck Jullien
> Date: Tue Mar 18 20:04:30 2014 +0100
>
> cfg: or1k_generic: allow TAP_TYPE override
>
> This patch allows users to specify TAP_TYPE from
> the command line when using or
Brad Riensche wrote:
> I am happy to report that the config generally works, and is noticeably
> faster than the ft2232 equivalent. However, the LED does not come on, nor
> does it blink during debugging as the ft2232 driver did. I confirmed that
> the bitmask in the config file is correct.
>
>
Andreas Fritiofson wrote:
> And by now, the same logic can be applied to the ftdi-configs. We
> wouldn't want to move them to interface/ at this point.
I think replacing the ones in interface/ with the ones in ftdi/ is
long overdue but oh well.
> By the way, it's useful to place an 'interface.cf
Spencer Oliver wrote:
> >> I'd prefer to avoid changing any project openocd.cfg configs again
> >
> > ..remember that you are an early adopter. What about the users who
> > have interface/$file.cfg in their configs? They'll get a warning..
>
> Except they would have to change the driver used.
Not
Paul Fertser wrote:
> > I think it's a bad thing to teach any users to use ftdi/ if that
> > directory is intended to ever go away.
>
> I'm not anyone to decide, but my personal preference would be for it
> to stay forever. ... I think it's easier to have them grouped
> together for OpenOCD-relate
Paul Fertser wrote:
> > Maybe clean out the ft2232 ones?
>
> I hope the runtime warning as proposed by Andreas will be enough;
I think it's a bad thing to teach any users to use ftdi/ if that
directory is intended to ever go away.
> those users that are already using ft2232 are not having real i
Paul Fertser wrote:
> > > IPv4-only is not something I'm ready to tolerate, IPv6-only is ok IMHO.
> >
> > And I think v4-only is fine until there's a good getaddrinfo() patch.
>
> I'm afraid I'm missing the point here, can you please elaborate?
Hm, I think I said it all already? :)
I think it's
Paul Fertser wrote:
> IPv4-only is not something I'm ready to tolerate, IPv6-only is ok IMHO.
And I think v4-only is fine until there's a good getaddrinfo() patch.
//Peter
--
Managing the Performance of Cloud-Based Appl
Paul Fertser wrote:
> You need to be using interface/ftdi/jtagkey2.cfg config, not the one
> in interface/.
Maybe clean out the ft2232 ones?
//Peter
--
Managing the Performance of Cloud-Based Applications
Take advantage
Peter Stuge wrote:
> > git fetch http://briens...@openocd.zylin.com/openocd refs/changes/27/1427/4
> > && git checkout FETCH_HEAD
> >
> >
> >
> > git commit -s -a
>
> Here you should also include --amend on the commit command line.
git commit
Hi Brad,
Brad Riensche wrote:
> I am relatively new to git, and very new to Gerrit, so some of this
> stuff is very confusing to me.
I'd be happy to explain the git data model if you want.
> I am obviously doing something wrong, but I can't figure it out.
> Can someone please show me the corre
Paul Fertser wrote:
> There certainly should be a better option, anyone?
I run a modified version of SimpleID, which is written in PHP.
PHP isn't inherently a problem just because there are lots of bad
code written in the language.
Unsure why there aren't more nice implementations of OpenID.. Ma
Hi all,
I've removed the libusbx-devel list since Pete Batard banned[1] me
after I wrote that I considered the libusbx code to have a bug[2].
Pete Batard wrote:
> It is my great pleasure
The "hostile fork"[3] is a success; you can now call libusbx libusb,
since Nathan Hjelm removed me from the
ger...@openocd.zylin.com wrote:
> ft2232: Mark interface driver as deprecated
Why not just remove it?
//Peter
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing Cen
Paul Fertser wrote:
> Probably Gerrit devs meant it as "please do not merge it as is",
> probably something else, I don't know, it sounds odd for any
> interpretation I can come up with.
"submit" is Gerrit terminology for the action when a maintainer
includes a commit into the official repository.
ger...@openocd.zylin.com wrote:
> cfg: LPC17xx default to using SYSRESETREQ to reset target
>
> Originally the LPC17xx user guide (UM10360 Rev 2) stated that SYSRESETREQ
> was not supported, so this was the default cortex_m reset mode.
>
> Rev 3 of the same user guide stat
Peter Andersson wrote:
>I am compiling using libftdi.
>$ pkg-config --modversion libftdi
>0.19
I'd suggest to upgrade libftdi to 1.0 instead.
>Here's the sequence:
>
>$ ./bootstrap
>...
>$ ./configure --enable-ft2232_libftdi
Please don't use the ft2232 driver anymor
ger...@openocd.zylin.com wrote:
> Since users are used to numbered releases it's probably high time we
> start cooking a new one. As there were no radical user-visible changes
> I consider it to be an incremental step from 0.7.0, hence I'm
> proposing 0.7.5 version number.
Maybe fi
Robert P. J. Day wrote:
> what's the openocd policy of timelines for removing stuff
As Andreas already wrote there is no policy. I'm personally in favor
of deleting everything old immediately.
//Peter
--
CenturyLink Clo
ger...@openocd.zylin.com wrote:
> This is an automated email from Gerrit.
>
> Heinz Schweiger (open...@htl-steyr.ac.at) just uploaded a new patch set to
> Gerrit, which you can find at http://openocd.zylin.com/1869
How much of this patch is pure copypaste and how much is actually new code?
Coul
Freddie Chopin wrote:
> In case anyone is interested - JTAG-VPI driver cannot be compiled
> using MinGW, at least I cannot "just" do it.
The code isn't portable. Someone wrote it without caring or knowing
how to make the same sockets code work across both *ix and Windows.
Windows is very differen
Drasko DRASKOVIC wrote:
> Why do we have libusb dependencies in this case?
Because unfinished work by an inexperienced student was included into
the repo in spite of review (mine) pointing out a number of problems
including this one.
OpenOCD doesn't really agree with your expectations of configur
Andreas Fritiofson wrote:
> The solution to this issue is simple: Instead of mutilating jtag_reset,
> create a separate command handler (not necessarily placed in jtag/tcl.c) to
> provide some generic base functionality that can be used to code the
> sequence in Tcl. Or just code the MSP430 specifi
ger...@openocd.zylin.com wrote:
> +++ b/src/target/hla_target.c
> @@ -5,7 +5,7 @@
> * Copyright (C) 2011 by Spencer Oliver *
> * s...@spen-soft.co.uk *
> *
Spencer Oliver wrote:
> Shall we treat HIDAPI as a submodule or let the user worry about
> this like we currently do with libusb.
HIDAPI is packaged at least in some distributions now. Detect it
as needed, ideally using pkg-config, and document that it's a
requirement for CMSIS-DAP support.
//Pe
Andreas Fritiofson wrote:
> > I'm going to do some more BE testing now when I have an environment set up
> > (it's dead slooow, though).
>
> For info, arm7tdmi memory access is apparently completely broken on a
> big-endian host. I have no plans to fix it.
Is that the only target which does byte-
Jens Bauer wrote:
> Yes, my guesses was round the USBLib
libusb (please note the name, it's neither USBLib nor LibUSB) had a
big-endian bug with descriptors fixed three years ago by someone with
a BE x achine; that's the last BE issue I've seen.
And transfered data isn't touched, it is just passe
Andreas Fritiofson wrote:
> If anybody could tell me an easy way to test or know a *cheap* and
> commonly available BE machine with USB that runs a modern linux
> with little or no setup, please do.
Are the MIPS WLAN routers all little-endian?
//Peter
---
Laszlo Papp wrote:
> would it be possible to configure a dedicated pin for SRST which is
> initially not a dedicated SRST pin, but unused?
Laszlo Papp wrote:
> No, all the pins are important for others purposes
This makes no sense whatsoever. You really have to decide - either
you have an availab
Laszlo Papp wrote:
> >> Again, please read the thread on the TI forum.
> >> I am sure you will understand more thereafter.
That doesn't make sense. As Andreas points out, if you want to
discuss something or request some help, then it's up to you to
provide information for that discussion or reques
Greg Ungerer wrote:
> The script is the following. It is pretty simple.
Maybe you could push a commit to gerrit? Please see the HACKING file
in the source tree for detailed instructions.
Thanks!
//Peter
--
October Webi
Jörg Fischer wrote:
> A patch is already in the jimtcl git, so there is an easy workaround:
>
> cd jimtcl
> git checkout master
..
> I don't know how to update the submodule reference in OpenOCD,
> so can a git expert provide a patch please?
cd ..
git add jimtcl
git commit -sm "Update jimtcl to $
Nader wrote:
> please if you were able to compile
..
> beta releases can be helpful in eliminating unnecessary issues.
You should build it yourself so that you can help eliminate
unneccessary issues.
//Peter
--
October
Sergey A. Borshch wrote:
> > ! [remote rejected] HEAD -> refs/publish/master (not Signed-off-by
> author/committer/uploader)
> >error: failed to push some refs to
> 'ssh://sb...@openocd.zylin.com:29418/openocd.git'
>
> Here is top lines from my commit message:
> topic: fix lpc2000 flash progra
Hello,
徐光晓 wrote:
> I did not post a bug report, because I did not check the real
> reason of this bug. The new line character reason is only from
> my suspection.
It sounds likely to me.
> Please somebody in charge of this module consider about this
> modification and update it in new version.
Tim Wescott wrote:
> I suppose one is just supposed to know
No, certainly not.
In my opinion, what is supposed to happen is that my (libusb
maintainer) constructive and quite detailed review of code by a
student who had not contributed to OpenOCD and seemingly not used
libusb-1.0 before which add
Spencer Oliver wrote:
> I just mentioned libusb-1.0 as that is the back-end I have dome all my
> tests with. But for info under linux you can also use the hidraw driver.
As explained you really should use the hidraw driver.
> > What makes me upset is not that people do not know - nobody knows a
Spencer Oliver wrote:
> > Do you see any speed regression between HIDAPI and libusb-1.0
>
> HIDAPI is just a wrapper for HID access, so under Linux uses
> libusb-1.0 anyway.
No, that's not true.
Please PLEASE look into these things before spreading disinformation.
What makes me upset is not tha
Paul Fertser wrote:
> The real issue here is that
>
> i686-w64-mingw32-gcc -std=gnu99 -o conftest.exe -g -O2
> -D__USE_MINGW_ANSI_STDIO conftest.c -lusb-1.0 -lftdi -lusb
>
> says "undefined reference to `libusb_error_name'".
That's exactly right.
> Why doesn't mingw see that cross-compile
Laszlo Papp wrote:
> > So can we remove the notice from flyswatter.cfg now? Have you verified
> > that both SRST and TRST are working?
>
> Unfortunately no because I am unable to use flyswatter for my board.
> I need to use a TI compatible jtag
Why? Please do not leave out the details, because th
Laszlo Papp wrote:
> I am facing the issue below when using the ftdi/flyswatter.cfg file
> interface:
> WARNING!
> This file was not tested with real interface, it is based on schematics and
> code
> in ft2232.c. Please report your experience with this file to openocd-devel
> mailing list, so it c
Xiaofan Chen wrote:
> Take note now that libusbx/libusb will be merged
Xiaofan, please hold off on reporting about the future until it has
actually happened.
The behavior of just about everyone involved in the libusbx fork
continues to blow my mind, but let's stay on topic.
Of course writing abo
Evan Foss wrote:
> It appears I will be going my own way.
..
> I was going to write a library in C and add a little bit of code to
> OpenOCD to connect to it. I would rather do an outside library for
> BSDL
I think that's awesome! Please do say when it's getting ready! I'm
looking forward to this.
Freddie Chopin wrote:
> > rcs mean nothing.
>
> ... to you. The package with rc2 was downloaded from my website 100
> times in a week, while these -dev packages I post get downloaded at a
> much lower rate (package from 13 weeks ago was downloaded 700 times).
> But of course I'm Wrong and you a
Freddie Chopin wrote:
> > Can we revert the changes that went into 0.7.0 and resubmit them to Gerrit?
>
> I'm confused... This discussion is about patches that are NOT in 0.7.0
> (fixes for building OpenOCD for ARM platform)
No Freddie, the discussion is about the brokenness in 0.7.0 which
those
1 - 100 of 364 matches
Mail list logo
