Uhm, I have found a solution :-) The problem is that C (or GCC) can
only change variable out of function using *variable=value
construct. This *variable syntax is essential. This is the only
possible way of using pointer to pass information outside function.
But this way it is only possible to
Hmm, things seems to be more suble :-)
I have tried a trick with using int *a; fun(int* a); and it indeed
works but the address is trimmed no matter what type a is (int*,
long*, void*) and this causes problems.
21 int a1=0, a2=0;
(gdb) s
22 double *a3;
(gdb)
23 a3=NULL;
(gdb)
With current design of OpenOCD it is impossible to queue read
operations as results are returned using single pointers, the read
operation needs to be performed inside of a function that will return
a result, otherwise we can only get a value given at queue time but
not a flush time.
LibSWD can
On Thu, Nov 3, 2011 at 10:43 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
I have to perform execute queue on read operation.
Luckily it only requires minor change of SWD_OPERATION_ENQUEUE into
SWD_OPERATION_EXECUTE parameter :-P :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Wed, Nov 2, 2011 at 8:03 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Should we?
What does these scripts do? Will they work on FreeBSD? :-P :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
On Wed, Nov 2, 2011 at 8:09 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
On Wed, Nov 2, 2011 at 9:06 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
On Wed, Nov 2, 2011 at 8:03 PM, Øyvind Harboe oyvind.har...@zylin.com
wrote:
Should we?
What does these scripts do? Will they work on FreeBSD
Hey,
I have some problems with pointers and need some support plz ;-)
int swd_bus_read_ack(swd_ctx_t *swdctx, swd_operation_t operation, char **ack){
swd_cmd_enqueue_miso_ack(swdctx, ack);
}
int swd_cmd_enqueue_miso_ack(swd_ctx_t *swdctx, char **ack){
if (swdctx==NULL) return
Hello Andreas :-)
On Thu, Nov 3, 2011 at 12:36 AM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
This won't even compile. You pass a pointer-to-int, but swd_bus_read_ack
expects a pointer-to-pointer-to-char.
naah this is only typo in mind-shortcut, code builds well, but i dont
get it
Hey does this code is related anyhow to arm_adi_v5 or this is totally
alternative solution?
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Thu, Oct 20, 2011 at 4:59 AM, Peter Stuge pe...@stuge.se wrote:
1. Continue what David Brownell worked on for FT2232-based adapters
2. Try Tomek's libswd, which I think works so far primarily with
(only some?) FT2232-based adapters
These are now joined into one :-) Transport and driver
On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge pe...@stuge.se wrote:
It might be really easy to make the device speak SWD.
Devices already speaking SWD for some time, need some small support in
Target implementation :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Thu, Oct 20, 2011 at 1:52 AM, Tomek CEDRO tomek.ce...@gmail.com wrote:
On Thu, Oct 20, 2011 at 1:49 AM, Peter Stuge pe...@stuge.se wrote:
It might be really easy to make the device speak SWD.
JLink specification is open, from what Ive seen it should be
relatively easy to implement generic
On Tue, Oct 18, 2011 at 2:47 AM, Michael Ashton d...@gtf.org wrote:
Hi,
I'm wondering if anyone can say whether it's possible, or might ever be
possible, to use the Olimex ARM-JTAG-EW with SWD in OpenOCD?
I can't find any mention of SWD in arm-jtag-ew.c, but I'm not sure whether
that really
On Thu, Oct 13, 2011 at 9:47 PM, Uwe Hermann u...@hermann-uwe.de wrote:
Please configure gerrit so that the full patch is posted on the mailing
list additionally, as it used to be. I personally read lots of patches
and discussions offline (e.g. in a train) in my mail client, and I'm
pretty
On Sat, Oct 8, 2011 at 12:11 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
sourceforge does not offer gerrit. Is there a hosting service that does?
It is possible to ask SF staff to install it on their servers, take a
look at support page, also you can chat on IRC about this topic :-)
--
On Fri, Oct 7, 2011 at 5:48 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
http://code.google.com/p/gerrit/
I have no idea what it does, but I'm very excited! :-)
Looks interesting, I wonder if it has mailing list integration or
simply use emails for notifications :-) I am a bit afraid of the
On Thu, Oct 6, 2011 at 9:07 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
That log doesn't show that OpenOCD hangs after accessing flash. The Flash
bank access DONE part is wrong, the flash bank has only been set up in
OpenOCD, there hasn't been any communication with the target
On Thu, Oct 6, 2011 at 9:29 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
Of course I could, if it was me having the problem. Which it's not. :)
But it's a good idea, I'm sure Attila can try it if the debug log doesn't
show anything useful.
/Andreas
Ah sorry, I only read that
On Tue, Oct 4, 2011 at 1:26 PM, Spencer Oliver s...@spen-soft.co.uk wrote:
Due to the recent news about Berlios closure on 31.12.2011 we are
moving the mailing list to sourceforge.
http://lists.sourceforge.net/mailman/listinfo/openocd-devel - was
On Wed, Oct 5, 2011 at 1:08 PM, Spencer Oliver s...@spen-soft.co.uk wrote:
mmm - must have been a long day
Thanks for the correction
Have a great evening Spen! :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
On Fri, Sep 30, 2011 at 5:47 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
FYI,
My first instinct is to move the mailing list wholesale to sourceforge.
sf.net if ok, i use it for some projects, urjtag use is as well. sad
that another open source project meets void.
--
CeDeROM, SQ7MHZ,
On Mon, Sep 26, 2011 at 10:03 AM, Akos Vandra axo...@gmail.com wrote:
Is there a good reason why ft2232_transfer uses bit-by-bit mpsse transfer?
If not, I would be happy to rewrite it to use bytewise transfer, if
the number of bits to be transferred is divisable by 8.
Might make things a
On Mon, Sep 26, 2011 at 11:48 AM, Peter Stuge pe...@stuge.se wrote:
Akos Vandra wrote:
I suspect it is because I have an x64 system where pointers are 64bits in
size.
The lines listed below try to cast a pointer to an int (signed 32bit),
for producing log messages.
I think %p should work.
On Mon, Sep 26, 2011 at 9:37 PM, Akos Vandra axo...@gmail.com wrote:
Sorry, it seems like I wanted to do too much too fast.
yup :-) it takes me few months already to do everything from scratch,
if it was one day job it would have been (all)ready :-) now the road
is straight - the openocd's
On Mon, Sep 26, 2011 at 9:27 AM, Akos Vandra axo...@gmail.com wrote:
swd_libswd_drv_openocd.c: In function ‘swd_drv_mosi_8’:
swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
different size
swd_libswd_drv_openocd.c:61: error: cast from pointer to integer of
different size
On Mon, Sep 26, 2011 at 10:29 PM, Peter Stuge pe...@stuge.se wrote:
I really like the Versaloon project. It supports SWD, and the main
author in the project Simon is also quick to send OpenOCD patches for
the device.
Does Versaloon fully support ARM target, memory access and debug
already? If
On Mon, Sep 26, 2011 at 10:55 PM, Peter Stuge pe...@stuge.se wrote:
I haven't tried it yet, but I believe so. Simon has patches. I think
this may be the most up to date source:
http://www.versaloon.com/bbs/viewtopic.php?f=2t=2808
Hmm, looks interesting, mem_ap_read_buf_u32() in the
]. The documentation on the LibSWD website is a bit outdated as
it used SVN and I have switched to GIT meanwhile, but I will try to
sync repositories asap, you can clone the git repository and make
doxygen to have a fresh copy at glance.
Best regards :-)
Tomek Cedro
[1] http://libswd.sf.net
[2
Regarding the LibSWD and OpenOCD relationship:
OpenOCD use LibSWD git submodule from the libswd git repository tag
v0.2 which can differ a bit from the head. I am working on the v0.2
and periodically add those changes to head. v0.2 is meant to build off
the shelf as it has configure scripts
On Sun, Sep 25, 2011 at 4:39 PM, Akos Vandra axo...@gmail.com wrote:
Bingo, I am working on Ubuntu 10.10, x64, gcc 4.4.5 (shipped with ubuntu).
cool :-) i will prepare the vm then :-)
../../src/helper/types.h:140: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘be_to_h_u16’
Hello! :-)
I have found some interesting issue that openocd does not want to use
openocd.cfg that is a symbolic link. Are there any considerations
behind that? :-)
source openocd.cfg
couldn't read file openocd.cfg: Too many levels of symbolic links
Best regards,
Tomek
--
CeDeROM, SQ7MHZ,
to do it with high-level rlink
interface but there sooo many tasks on my head, it needs some time and
I need a vacation ;-P
Best regards! :-)
Tomek Cedro
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd
I can take a look at this as I'm finishing to solder a hardware that I
will finish the SWD implementation in upcoming days, but I would
rather not change interface/jtag/transport layer until SWD is done.
When its done and working then we can change internals, otherwise we
will have two different
2011/8/29 Michel Catudal michelcatu...@gmail.com:
Since we have bigger monitor than in the 70s and 80s why make the code
unreadable?
The only valid reason for using KR would be
1- You still expect to be stuck with a teletype at times and want to make
sure you can see many lines of code at
On Sat, Aug 27, 2011 at 3:25 PM, Jie Zhang jzhang...@gmail.com wrote:
Maybe making OpenOCD use UrJTAG as a library is more worth the effort
than just rewriting ftdi driver.
Regards,
Jie
I proposed this about two years ago but the idea was rejected. In my
opinion there is no sense in creating
On Sat, Aug 27, 2011 at 3:40 PM, Uwe Bonnes
b...@elektron.ikp.physik.tu-darmstadt.de wrote:
while not a cure for your openocd problem, what about xc3sprog?
svn co https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog xc3sprog
It is. I am using Xilinx FPGA right now and xc3sprog is great tool to
On Fri, Aug 26, 2011 at 5:10 PM, Sam Jansen sam.jan...@starleaf.com wrote:
In attempting to use openocd with an Amontec JTAG key to program a Xilinx
FPGA, I encountered a series of issues I though others might be interested
in. I don't have sensible proposed solutions for any of the problems I
Hello Gary :-)
On Tue, Aug 23, 2011 at 2:24 AM, Gary Carlson
gcarl...@carlson-minot.com wrote:
I have zero prior experience with the FT2232 so I took a very brief scan of
its driver code. I get the feeling that this type of device allows fairly
low-level access to interface port pins. If
Hello Gary :-)
On Tue, Aug 23, 2011 at 3:43 PM, Gary Carlson
gcarl...@carlson-minot.com wrote:
I think the solution with high-level interfaces is to allow them to do their
bitstream magic directly if they have that capability and for low-level
interfaces turn to libswd or other future
In one sentence, as my preference for future extendability I have
chosen approach that involves modular design with external submodules
(just like in object programming) rather than extending one big
structure (i.e. command queue) like it was done before. This should
allow adding new
Hello Carlson and thank you for your support! :-)
On Sun, Aug 21, 2011 at 9:09 PM, Carlson Gary
gcarl...@carlson-minot.com wrote:
I didn't realize there was a fork for SWD support, so my original attempt
was based on the master branch. Nevertheless I cloned the fork that you
indicated and
Thank you for this hint on printing pointers! :-) Although there is no
word about %p in the manual, it works on FreeBSD so it should also
work on MacOSX as it is derivative :-)
With LOG_INFO(New SWD context initialized at %p, (void
*)jtag_interface-transport-ctx); we get:
%telnet localhost
On Fri, Aug 19, 2011 at 1:09 AM, Carlson Gary
gcarl...@carlson-minot.com wrote:
(...)
Debug: 35 45 command.c:151 script_debug(): command - ocd_transport
ocd_transport select swd
Error: 36 45 target.c:435 get_current_target(): BUG: current_target out
of bounds
Hello Gary, did you try the
Some more information on details/usage in [1]. Target use TAP for JTAG
and DAP for SWD, so we need to create union containing both inside
with common API, or initialize only one of them at time and null other
to let know which one is in use, or create null pointer and cast it
based on transport
On Thu, Aug 11, 2011 at 10:08 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Please give Andreas Fritiofson a warm welcome as a new
OpenOCD maintainer!
Hello Andreas! Glad to have you onboard! :-)
Best regards,
Tomek Cedro
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Wed, Aug 10, 2011 at 3:40 PM, Vit Mares mares@gmail.com wrote:
The FTD2232 can be used not only as a JTAG dongle but it is also
very big helper for embedded developer. It can be used as a I2C or SPI
bridge between your PC and uC board, it can be used for Lattice FPGA
programming etc.
On Wed, Aug 10, 2011 at 4:13 PM, Manuel Borchers man...@matronix.de wrote:
The point he was trying to make is, that one _may_ need (or want to
stick to) the native FTDI drivers. This may be because one wants to
use the other channel as a normal UART (speak use the virtual com port)
or some
If we don't constantly show that some work has been done by
open-source some people will tend to think it was done for free, no
effort and they start to demand more results with less funds in
shorter time. This is why we should tell to develop open-source
instead buy expensive closed
Ugh, why this is a release not RC3? We did not test RC to have go for
a release... are we supposed to test on a release? :\
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Tue, Aug 9, 2011 at 8:53 AM, Jean-Christophe PLAGNIOL-VILLARD
plagn...@jcrosoft.com wrote:
On 07:50 Tue 09 Aug , Tomek CEDRO wrote:
Ugh, why this is a release not RC3? We did not test RC to have go for
a release... are we supposed to test on a release? :\
there was no patch during day
On Tue, Aug 9, 2011 at 11:08 AM, Xiaofan Chen xiaof...@gmail.com wrote:
If the project is willing to provide official Windows binary, that
would be the best. But if not, a link to Freddie Chopin's
website is still good.
I vote for Freddie to have his own place/mirror at project repository,
at
Cool :-) Congrautlations Jim! We wanted to do something like that as
more general wiki with Drasko, so now we have a place to develop :-)
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Hello Jean, please provide full featured RC package (generated by
make distcheck, containing configure scripts) to test it on FreeBSD,
as for now bootstrap fails, so the status is no-go.
Best regards,
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Hello! :-) Trying to bootstrap on FreeBSD 8.2-RELEASE fails with the
0.5.0-rc2 as given at:
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=snapshot;h=d4cd6f032015552f00bf4b5a90f25f5f958e9d9e;sf=tgz
This should probably never happen with the real package as configure
On Thu, Jul 28, 2011 at 12:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote:
I sort of like the x - but the majority rules.
Any more votes?
I also like the xxx :-P :-) :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development
Good news - libswd-openocd driver bridge is now ready and functional
[1] it reads out the IDCODE. I have already pushed the patches to the
repository [2]. Right now have to multitask to another task but at
weekend I will try to make arm_adi_v5 work with my swd target using
crafted drivers and swd
Everything went to master of the repository - I have cleaned it up so
i should be now easy to rebase with openocd/master when necessary.
Thank you for all hints on using git this is very nice tool and I seem
to get familiar with it already :-)
Best regards! :-)
Tomek
--
CeDeROM, SQ7MHZ,
On Thu, Jul 28, 2011 at 12:55 PM, Spencer Oliver s...@spen-soft.co.uk wrote:
This is a good idea to clean that up.
I think you can go one step further by dropping the 'x' (which has no
meaning) in order to rename:
- stm32x to stm32f1
- stm32f2xxx to stm32f2
Seriously speaking - no offense
Hello Drasko! :-)
It would be perfect to modularize code and join all modules together
in one openocd thread.. I have tried that but its too much work, first
need to finish swd framework. However hving modular design, maybe even
object-based, would improve readability and extend new
On Fri, Jul 22, 2011 at 9:59 AM, Peter Horn peter.h...@bluewin.ch wrote:
Besides the RLink I also have an Olimex ARM-USB-OCD adpater. On Windows,
stepping with the Olimex is considerably faster than with the RLink. On
Linux both adapters are on par. I'm Using the same STM32 board and
On Thu, Jul 14, 2011 at 12:58 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
(..) When I removed template drivers from libswd source tree so it
can be linked with drivers already compiled and provided by openocd,
there are some unresolved dependencies in libswd.la submodule. This is
the only
Hello Andreas!
Do you know what is the difference between JTAG (on Stm32Primer) and
SWD (on Stm32Primer2) RLink interface? Would they run on existing
driver? Do you have some kind of manual or technical specification?
Best regards! :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Hello!
Sorry for cross-posting but this somehow touches both applications.
LibSWD is a standalone library that can generate SWD operations, then
flush them into device driver. This driver (some function set) is
application specific, so it cannot be compiled in into libswd, but
rather linked with
On Tue, Jul 12, 2011 at 9:38 AM, simon qian simonqian.open...@gmail.com wrote:
4. Add SWD drivers, this should be the libswd. And call SWD drivers in
adi_v5_swd.
Hello Simon! This is almost done. Getting back to this today. When its
done, then I get to higher layers. The basic concept is that
On Tue, Jul 12, 2011 at 9:55 AM, Tomek CEDRO tomek.ce...@gmail.com wrote:
The basic concept is that both jtag
and swd can use arm_adi_v5 calls, depending on transport selected.
To be more exact - the arm_adi_v5 is the wrapper for low level jtag or
swd operations on jtag-dp or swd-dp. Target
On Sun, Jul 10, 2011 at 2:41 PM, Luca Bruno lu...@debian.org wrote:
As a sidenote, publishing tarball for -rc helps testing in conditions
similar to the final one, avoiding late bugs introduced by autotools
packaging or similar.
Totally agree on this - FreeBSD ports use automatic package
On Fri, Jul 8, 2011 at 5:59 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote:
i'm currently using the merge i made of the bitbang stuff with openocd.
(..)
nice work! :)
Thank you Rodrigo! Nice to hear you find it useful and that its
working as supposed :-) :-)
I have made some small progress
Hello Michael! :-)
On Fri, Jul 8, 2011 at 8:18 PM, Michael Schwingen
rincew...@discworld.dascon.de wrote:
Am 07/08/2011 08:30 PM, schrieb Tomek CEDRO:
(..) Still I don't know any sensible method
to make drills metalization at home to produce advanced two layer
pcb... maybe you guys know some
On Fri, Jul 8, 2011 at 8:59 PM, Michael Schwingen
rincew...@discworld.dascon.de wrote:
Note: don't put vias *in* SMD pads - they will wick away the solder when
doing automated production.
Yup :-)
Still, no solution/idea on how to make pads metalization at home
safely... there is a clear
On Thu, Jun 30, 2011 at 6:23 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Please give a warm welcome to Jean-Christophe as the release
manager.
Hello Jean-Christophe :-) You have been long awaited! Good luck and
have fun with OpenOCD project! :-)
Best regards! :-)
Tomek Cedro
--
CeDeROM
Cool, I will add new field into layout structure that will indicate
forbidden bits to bitbang, this field will be zero by default so all
bits are allowed, driver author can add some value of this field to
the specific layout - that value AND port mask to set/bitbang will be
checked in
On Tue, Jun 21, 2011 at 3:57 PM, Phil Fong fong...@yahoo.com wrote:
I think there is an misunderstanding here. My reading of Tomek's emails
indicates there is a layout specific mechanism to filter which pins can be
bitbanged. The interface config file will define which pins can be
bitbanged
Laurent,
1. If you create cable that have ADC onboard (like KT-LINK) then it is
easier to write simple TCL script to read ADC than rewrite whole
driver in the source code.
2. If you need to program I2C, SPI, or other kind of memory, you
simply write simple TCL script to do so, no need to rewrite
On Mon, Jun 20, 2011 at 6:14 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
(..) I would dearly like to see SWD done before
opening the floodgates to GPIO and other serial protocols.
SWD is packed-based half-duplex bus that defines TRN operation for bus
direction change and buffers
On Mon, Jun 20, 2011 at 7:46 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote:
i'm trying to apply these patches on the current head, and i get:
bitbang.c: In function ‘handle_bitbang_command’:
bitbang.c:90: error: implicit declaration of function ‘strnstr’
bitbang.c:90: error: assignment
On Mon, Jun 20, 2011 at 8:18 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Btw. is there any way in git to edit a commit? :-)
Yes:
git rebase -i origin/master
Aaaarg, could have figured that myself ;-P Tanks! :-)
I think I have found my problem - the bitbang can be used only after
cable is
I have found the issue - command init is mandatory for bitbang to
work as it initialize the interface (pretty obvious). On another place
I was using some configuration file that had this init inside and this
is why it worked there, I mislooked that :-(
So generally speaking the patches are
On Mon, Jun 20, 2011 at 9:19 PM, amotec-laurent_gauch
amotec-laurent_ga...@mail.axianet.ch wrote:
Your TCL bitbang will control the port of the FTDI from an higher level than
FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you
accept or not the use of the TCL procedure,
Here goes another patch to be applied on top of previous patches:
-it fixes strnstr() problem - sorry for that, man says clearly it is
FreeBSD specific!
-it changes command mode to COMMAND_EXEC so 'bitbang' is only
available after 'init'
-some minor string and constants fixes
Waiting for feedback
On Mon, Jun 20, 2011 at 11:33 PM, Rodrigo Rosa rodrigorosa...@gmail.com wrote:
i found a bug in interface_signal del, the name of the signal was
not passed down to the functions thats look for it, so it didn't work.
attached a patch :)
Tanks, I will take a look, but signal deletion worked for
On Sun, Jun 19, 2011 at 12:52 PM, Xiaofan Chen xiaof...@gmail.com wrote:
Just FYI, urjtag works fine with either libftdi or libftdi-1.0,
it also works with libusb-1.0.
Yes I remember such discussion some time ago ended with good solution,
maybe worth copying.. although never tested is as I
On Thu, Jun 16, 2011 at 9:42 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
a ? : b is equivalent to a ? a : b, unless evaluating a has side-effects or
if a is volatile, since it's only evaluated once in the former case and
twice in the latter.
Nice to know, thanks! Is that true
On Fri, Jun 17, 2011 at 7:57 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I am struggling a bit following the above, but I think we agree:
- development goes on in master like it always has done
- you create a fork at the openocd mirror and create a release branch there.
You pick whatever
On Thu, Jun 16, 2011 at 7:56 PM, Hans Petter Selasky hsela...@c2i.net wrote:
I was not able to reproduce the segfault.
This happens only with this particular source code, it is a result of
(non-finished) patching from my fork, that is working fine.
Non-hinished patching means that there are some
On Sat, Jun 18, 2011 at 12:32 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
(..) but it looks interesting to break libusb this way...
Short update on this - libusb (1.0.8-1) and libftdi (0.19-1) on linux
(arch 2.6.39) does not have this ussue.. ddaamn ;-P
source [find interface/kt-link.cfg
Hello Laurent :-)
On Thu, Jun 16, 2011 at 7:25 AM, Laurent Gauch
laurent.ga...@amontec.com wrote:
BAD ! and WHY it is too JTAG-ONLY?
ask guys that wrote it, you mentioned helped in this ;-)
For me the queue_flush and execute_queue should be the mechanism to be used
for ALL transport, JTAG
One more time - SWD transport and implementation is not yet finished!
The sources are available for you to get familiar the direction
changes are going, but they may change slightly as the work
progress... :-)
You know the interface signals invention and the bitband, so you can
work on new
Patches for new features to be integrated into openocd/master are
ready in most part. Its working in my trunk but does not yet in
openocd master, probably this is the problem with rebasing Oyvind
mentioned... work in progres.. the solution will appear as next patch:
More information on SWD work in general can be found at
http://stm32primer2swd.sf.net/
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
This is the patch pack that should add interface_signal() and
bitbang() functionality (binary backend + tcl frontend) to the
interface API + example implementation for FT2232 interfaces (layout
independent).
Patches can be applied on top of the current GIT HEAD. Please verify
their functionality
This patch fixes transport selection mechanism - if transport is
defined it will be selected. Before 'jtag' was always selected no
matter what transport in fact was supposed to be used.
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
This patch renames main2() in openocd.c into openocd_thread() that is
called from within openocd_main(). This minor function change may
suggest thread support/organization in future.
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
0007-OPENOCD-Renamed-ambiguous-main2-into-openocd_thread-.patch
replacing my bootloader to
grub2 lol).
On Thu, Jun 16, 2011 at 8:53 AM, Xiaofan Chen xiaof...@gmail.com wrote:
On Thu, Jun 16, 2011 at 4:20 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
Did anyone had similar problem?
Was anything changed recenlty in the code regarding
usb/libusb/libftdi/ft2232
On Thu, Jun 16, 2011 at 9:55 AM, Hans Petter Selasky wrote:
On Thursday 16 June 2011 11:09:19 Tomek CEDRO wrote:
Hi,
Hello Hans! Thank you for fast response! :-)
Are you using 8-stable?
%uname -a
FreeBSD c2. 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46
UTC 2011 r
On Thu, Jun 16, 2011 at 5:50 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I take it is just a bugfix?
Yes - it changes:
retval = allow_transports(CMD_CTX, jtag_interface-transports ? : jtag_only);
into:
retval = allow_transports(CMD_CTX, jtag_interface-transports ?
pepole interested in using is but noone even tare to try do the job
:-)
You have my support Jean :-) I would suggest to migrate
interface_signal and bitbang yet before releasing 0.4.1 to give users
time to play with that functionality and possible new features in
0.5.0 :-)
Best regards! :-)
Tomek
On Wed, Jun 15, 2011 at 5:34 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
The swd is some time away from being merged with master,
so I wouldn't want to see it in the next release of openocd, unless
the release drags out.
I would suggest 0.4.1 for the current code freeze, as there should
Hello Spencer :-)
I would use git submodule and simply include JimTCL with OpenOCD build
binary. This would save lots of problems and produce common
distribution. Anyone who want to use external library can build
his/her own binary. Ofcourse there is a situation to solve what to to
when JimTCL is
Hello Richard,
Seems to be nice feature, however:
It should be somehow related with interface driver bitbang..?
It should be possible to enabled/disabled by configure script.
Bets regards :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Wed, Jun 15, 2011 at 8:57 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
0.4.1 implies that it is a variant of 0.4. What we have now is *completely*
different from 0.4, so 0.5.0 is better
Yeah, isn't current HEAD somehow development/bugfix of 0.4.0? Are
there any totally new
1 - 100 of 198 matches
Mail list logo
