Re: [Openocd-development] General SWD Support in OpenOCD

2011-07-28 Thread Tomek CEDRO
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 function set :-)

Best regards! :-)
Tomek

[1] http://stm32primer2swd.sf.net/
[2] http://repo.or.cz/w/openocd/libswd.git

This is the program invocation and debug messages output:
%./openocd -c noinit
Open On-Chip Debugger 0.5.0-dev-g7ad8d2e-dirty (2011-07-25-15:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : accepting 'telnet' connection from 
Info : only one transport option; autoselect 'swd'
Info : New SWD context initialized at 0x2843B280
10 kHz
Info : KT-LINK SWD-Mode initialization complete...
Info : max TCK change to: 3 kHz
Info : clock speed 10 kHz
SWD_I: Executing swd_dap_activate(0x2843b280, SWD_OPERATION_EXECUTE)
SWD_I: Executing swd_dap_reset(0x2843b280, SWD_OPERATION_EXECUTE)
SWD_I: Executing swd_dp_read_idcode(0x2843b280, SWD_OPERATION_EXECUTE)
SWD_I: swd_dp_read_idcode() succeeds, IDCODE=EE2805D8
(111011100010110111011000)
Info : SWD transport initialization complete. Found IDCODE=0xEE2805D8.
Warn : gdb services need one or more targets defined
User : 42 75811 command.c:557 command_print(): debug_level: 3
Debug: 43 78630 command.c:151 script_debug(): command - ocd_command
ocd_command type ocd_transport init
Debug: 44 78630 command.c:151 script_debug(): command - ocd_transport
ocd_transport init
Debug: 46 78630 transport.c:263 handle_transport_init(): handle_transport_init
Debug: 47 78630 swd.c:129 oocd_swd_transport_init(): entering function...
SWD_I: Executing swd_dap_activate(0x2843b280, SWD_OPERATION_EXECUTE)
Debug: 48 78630 swd_libswd_drv_openocd.c:174 swd_drv_mosi_trn():
OpenOCD's swd_drv_mosi_trn(swdctx=@0x2843B280, bits=1)
Debug: 49 78630 interface.c:41 oocd_interface_signal_find(): Searching
for signal RnW
Debug: 50 78630 interface.c:62 oocd_interface_signal_find(): Signal
RnW already exists.
Debug: 53 78631 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432CA0,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 70 78646 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432CC0,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 87 78662 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432CE0,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 104 78778 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D00,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 121 78792 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D20,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 138 78808 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D40,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 155 78824 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D60,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 172 78840 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432D80,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 189 78856 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432DA0,
data=0x0079, bits=8, nLSBfirst=0x01)
Debug: 206 78872 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432DC0,
data=0xFFE7, bits=8, nLSBfirst=0x01)
SWD_I: Executing swd_dap_reset(0x2843b280, SWD_OPERATION_EXECUTE)
Debug: 223 7 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432DE0,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 240 78904 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E00,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 257 78920 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E20,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 274 78936 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E40,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 291 78952 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E60,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 308 78968 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432E80,
data=0x, bits=8, nLSBfirst=0x01)
Debug: 325 78984 swd_libswd_drv_openocd.c:61 swd_drv_mosi_8():
OpenOCD's swd_drv_mosi_8(swdctx=@0x2843B280, cmd=@0x28432EA0,
data=0x, bits=8, 

Re: [Openocd-development] General SWD Support in OpenOCD

2011-07-28 Thread Tomek CEDRO
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, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-13 Thread Øyvind Harboe
Hi Tomek,

it's great that your focusing on functionality. Cracking the
technical problems and making a patch series that's right
for OpenOCD are two hard problems. Perhaps better
attack one at the time?

One hard thing about SWD is to crack the technical problems,
the other hard thing is to create a series of patches where
as many as possible of the list are able to follow what was
done to OpenOCD. This is crucial as otherwise you would
be the only one able to modify the code, at which point the
value of your patches would drop sharply.

Your contributions to OpenOCD can never be greater than
that of one man, but if you enable the rest of the community
to work on SWD then you have reached another level entirely.

There is an optimal size of git patches where the maximum number
of people are able to follow what was done to the code. That's
the size we should aim for. Generally this means small patches with
one change per commit.

Note that with interactive git rebase you can create the
history after you have the solution.

At this point, I think we're ready to accept the first commit,
which would do the following:

-creation of src/transport directory for transport layer
-creation of src/interface directory for interface layer
-moving transport.{c,h} from src/jtag into src/transport and updating
the headers and Makefile.am

You can then rebase your work on top openocd master and
your next commit would be much smaller.

-- 
Øyvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 87 40 27

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-13 Thread Tomek CEDRO
On Mon, Jun 13, 2011 at 8:25 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 it's great that your focusing on functionality. Cracking the
 technical problems and making a patch series that's right
 for OpenOCD are two hard problems. Perhaps better
 attack one at the time?

exactly. producing smaller patches only complicates things...

 One hard thing about SWD is to crack the technical problems,
 the other hard thing is to create a series of patches where
 as many as possible of the list are able to follow what was
 done to OpenOCD. This is crucial as otherwise you would
 be the only one able to modify the code, at which point the
 value of your patches would drop sharply.

no fear! i have commented my changes and code inside even doxygen
style so there is nothing hard to understand - changes are clean, does
not complicate existing code and the code is self explanatory and
commeted where necessary, as they should be :-) the problem itself
with understanding program flow or function operation may be the whole
program issue, not only my changes, as it took me few months to get
familiar with the code.. and i think it should be reorganized.. but as
you said - one thing at time - after we make swd working, maybe there
is time for code cleanup and refactorization (ie. fix program flow,
move globals into common context passed as function parameter, etc)
:-)

if you prefer so, okay we can work on my fork for the moment swd if
operational, then i produce best patches possible, now i know how to
do this :-)

Best regards! :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-12 Thread Tomek CEDRO
I have deleted ols meddy openocd-swd branch and pushed new branch with
the same name openocd-swd, this one:
-use fresh openocd master head
-is already rebased openocd master with changes from my fork
-has already squashed commits of my work (less commits than before,
more changes at once, no need to split patches as this produce
unnecessary additional work)
-it is ready to become branch v0.5 of openocd git repository

Please do not apply those patches on current HEAD as they reorganize
code a bit (byte maybe). Current head should become branch v0.4 to
save current work. You can repository into branch v0.5 as there are
people already eager to test the code :-) Or simply I can make this
branch a head of my repository and we can work over there until stable
functionality - as you like maybe the second will be safer and I can
handle maintenance :-)

Best regards!
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-12 Thread Peter Stuge
Tomek CEDRO wrote:
 Im afraid there is not much sense in that interactive rebasing for
 such big change - it took me so many hours to split patches and in
 result now there are even more patches some new patches patched by old
 patches ;] This is far from perfect.

You know that interactive rebase can also be used to reorder commits?

So you would move the commits that belong together after each other,
have the first be pick, and then use squash or fixup for the others.

To be able to use this feature it is an absolute requirement that
each commit in the repo only changes one logical thing, or there will
be massive complications. This is only one of the many reasons why it
is so important to have each commit be only a single logical change.


 I can see git wants to keep the commit history at all cost,

For a public repository it is the prefered way, but it's not a hard
requirement, especially not if you announce in advance that there
will be history changes in the repository, or maybe only in certain
branches.


 so the cructial thing here is producting good commits.

This is important. Not because git wants it, but rather because it is
the only way that allows to take full advantage of features in git,
which makes further work in the repo really easy.


 how to produce good patches from git diff (i.e. something as
 git format-patch)... or the git diff is enough?

I'd be happy to help you with this but I think email is not so
convenient. I would prefer IRC or jabber, and probably some
pastebinning. I just joined #openocd on irc.freenode.net.


//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-12 Thread Tomek CEDRO
Hello Peter!

Thank you for all hints :-) Now I know it, but few months ago when I
started using GIT I did not (yet) :-P The changes introduced by my
work could be applied to current openocd/master repository as I wanted
because changes are too big, so I gave up and simply squashed logical
patches with interactive rebase to move along with work. Rebase and
branches are really great feature that makes git unique from other
revision control systems !!! The work of rebasing is now done and we
can work on my fork to get stable results and then push it into branch
v0.5 of openocd :-) I consider replacing head of my repository with
the openocd-swd branch (rebased) to make work even simpler...

Best regards! :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-12 Thread Øyvind Harboe
Hi Tomek,

for others to be able to review your work, it is essential
that it is a sequence of small logical changes. This will
also create a much greater degree of continuity in the
official master branch, which is very important to the
maintainers.

We also want to reorder your commits, so that we can
get all changes that are non-swd related pushed to
the master repository before we push any swd specific
changes.

For instance, we could probably move things into the
transport folder first and then you can rebase your
branch on top of the master branch.

Are you familiar with git remote add/rm? You can
have both the official and your git repository commits
in your local repository.

You probably want to delete all branches in your git
repository, except for the swd branch and then
continue to rebase your swd branch and forcing a
push of the updated swd branch as we move manage
to take out small parts of your work in commits that
we push to the master branch.

Can you summarise what kind of changes in your
branch that has nothing to do with swd as such and
could probably be out as separate
commits and committed to the master branch already?

Moving files into the transport folder seems like a good
candidate.

-- 
Øyvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 87 40 27

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-12 Thread Tomek CEDRO
Well, the changes are bigger than only moving files, because this
impacts code in many different places (i.e. headers inclusion). This
is why I did not split the patches into single step because this takes
too much time that I want to spend on code development and in fact
makes no sense - we simply introduce some change and thats it, no need
to split it apart. But we should not touch the current 0.4 branch as
0.4 should stay the way 0.4.0 was. This is why I suggest to create
v0.4 branch to save changes.

The main changes are:
-creation of src/transport directory for transport layer
-creation of src/interface directory for interface layer
-moving transport.{c,h} from src/jtag into src/transport and updating
the headers and Makefile.am
-adding libswd git submodule to enable libswd build and inclusion by default
-adding stuff into src/transport
-adding stuff into src/interface
-changes in src/jtag/interface.* src/jtag/interfaces.* and
src/jtag/driver/ft2232.c - lots of them: ft2232_swd inetrface creatio,
ft2232_ktlink_init_{swd, jtag} separation, initialization routines for
ktlink, bitbang functionality, transport functionality.
-changes in src/jtag/core.c - adding interface_signal tcl handling
routines (this should be moved into src/interface)
-change in openocd.c - to register bitbang tcl command
-configure.in was updated to build the libswd
-moved git submodule routines before autotools invocation as autotools
work on submodules that should be already there

There are probably more minor changes related to header inclusion and
Makefile.am. Probably the first commits should be spilt-up. The rest
is work on new things that were not present before. Sorry, I am short
on time so need to concentrate on swd implementation and verification,
but I promise to produce better commits as I already know how things
are ;-)

Bets regards! :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-11 Thread Øyvind Harboe
Hi Tomek,

thank you so much for being willing to do the work of rebasing,
splitting into patches, etc. This saves maintainers a lot of work
and opens up for everybody being able to pitch in and make
suggestions for improvements to your work. I plan to look at the
SWD stuff, but it will not be in the immediate future, but it looks
like you're picking up some interest here on the list now anyway...

-- 
Øyvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 87 40 27

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-11 Thread Tomek CEDRO
Sure thing I want to support in an useful way! This is also good
skills training for me :-) Thank you all for useful hints -
interactive rebasing seems to be what I need, as presented on
http://book.git-scm.com/4_interactive_rebasing.html

You can also rebase interactively. This is often used to re-write
your own commit objects before pusing them somewhere. It is an easy
way to split, merge or re-order commits before sharing them with
others. You can also use it to clean up commits you've pulled from
someone when applying them locally.

Thank you and have great weekend! :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-11 Thread Tomek CEDRO
Im afraid there is not much sense in that interactive rebasing for
such big change - it took me so many hours to split patches and in
result now there are even more patches some new patches patched by old
patches ;] This is far from perfect.

I think we should simply use the default rebase patches to synchronize
the repositories, then work on common code and simply send better
patches since then... Those patches are the full history of what and
how I have done things, not always good as they evolved, but they are
good at the end ;-) I can see git wants to keep the commit history at
all cost, so the cructial thing here is producting good commits.

Another approach I can see is to simply copy resulting code of
openocd-swd and try to produce patches for each file/functionality
that is different for openocd-master. Then we avoid long history of
unnecessary changes and get only what we need for current
openocd-master. So the question is - how to produce good patches
from git diff (i.e. something as git format-patch)... or the git diff
is enough?

I will try the second approach and let you know. If it fails I will
simply send patches from rebase of my fork and openocd-master.

Regards :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-10 Thread Tomek CEDRO
Done. I have created new branch in my repository, just in case, it is
named openocd-swd, it is already rebased with actual openocd/master
branch :-)

It builds fine. The interface_signal and bitbang works fine, I will
prepare patches in a moment. The rest of functionality is not yet
verified! beware! :-)

The problem with core.c was the patch I have made myself and was
introduced later in the code.

Also I have changed bootstrap a bit - the git submodule is now moved
before autotools invocation, as autotools work on those submodules (so
they must be there already).

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-10 Thread Tomek CEDRO
Oyvid,

I have also created branch openocd-master to have up-to-date openocd
repository at site to produce patches.

Now when I do git format-patch openocd-master file I get bunch of
patch files based on my local commits. This is nasty as brings
unnecessary commits. I would rather produce one patch that contains
only important changes.. or you prefer the way format-patch produces?
How to produce good patch with description etc from git diff
result? :-)

Best regards,
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-10 Thread Tomek CEDRO
Do you think its time to create and work on 0.5 branch?

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-10 Thread Rodrigo Rosa
On Fri, Jun 10, 2011 at 3:53 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
 Oyvid,

 I have also created branch openocd-master to have up-to-date openocd
 repository at site to produce patches.

 Now when I do git format-patch openocd-master file I get bunch of
 patch files based on my local commits. This is nasty as brings
 unnecessary commits. I would rather produce one patch that contains
 only important changes.. or you prefer the way format-patch produces?
 How to produce good patch with description etc from git diff
 result? :-)


if by unnecessary you refer to a bunch of little things that could fit
into a single patch, then this link may be of use:
http://book.git-scm.com/4_interactive_rebasing.html
i found it pretty useful for playing around with commits. you can
edit the commit messages and turn a bunch of commits into one,
remove the ones you don't want, etc.
i'm also new at git, hope this is of use to you :)

 Best regards,
 Tomek

 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
 ___
 Openocd-development mailing list
 Openocd-development@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/openocd-development




-- 
Rodrigo.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-10 Thread Peter Stuge
Tomek CEDRO wrote:
 Now when I do git format-patch openocd-master file I get bunch of
 patch files based on my local commits. This is nasty as brings
 unnecessary commits. I would rather produce one patch that contains
 only important changes.. or you prefer the way format-patch produces?

A mix is best. Please turn it into as many patches as make sense. One
logical change per patch is the best. Maybe it will indeed only be a
single commit, but maybe there are some preparatory changes that are
not related to SWD itself, then they should go in a commit each.


 How to produce good patch with description etc from git diff
 result? :-)

Have a look at how to use interactive rebase. (rebase -i)

When you have a branch off master with a couple of commits you can
run:

git rebase -i origin/master

to start an interactive rebase of all commits since the last commit
you have from the remote repository.

Check out the man page git rebase --help and/or the
http://progit.org/ book. Please ask if you have some questions.


//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-09 Thread simon qian
Great, I'll add SWD driver of versaloon when it's testable.

2011/6/8, Øyvind Harboe oyvind.har...@zylin.com:
 On Tue, Jun 7, 2011 at 7:05 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
 On Tue, Jun 7, 2011 at 5:02 PM, Øyvind Harboe oyvind.har...@zylin.com
 wrote:
 First thing I tried was to rebase your master branch on
 top of origin/master and that didn't work...

 Uhm, this is based on a version from March or April... and there are
 also some unnecessary changes that should be filtered out I guess.

 Could you rebase it on top of master branch and force a push?

 Sure - that wont destroy anything at my side?

 You can safely try it locally. You'll have to learn about
 about rebasing before this is done...


 --
 Øyvind Harboe

 Can Zylin Consulting help on your project?

 US toll free 1-866-980-3434 / International +47 51 87 40 27

 http://www.zylin.com/zy1000.html
 ARM7 ARM9 ARM11 XScale Cortex
 JTAG debugger and flash programmer
 ___
 Openocd-development mailing list
 Openocd-development@lists.berlios.de
 https://lists.berlios.de/mailman/listinfo/openocd-development



-- 
Best Regards, SimonQian
http://www.SimonQian.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-09 Thread Tomek CEDRO
On Tue, Jun 7, 2011 at 5:02 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 First thing I tried was to rebase your master branch on
 top of origin/master and that didn't work...

 Could you rebase it on top of master branch and force a push?

I also have problem with merge conflict in src/jtag/core.c :-( How can
I check what has changed against openocd/master and eventually fix
those changes?

I did:
git clone ssh://...@repo.or.cz/srv/git/openocd/libswd.git
git remote add openocd
git fetch openocd
git rebase openocd/master
...
CONFLICT(content): Merge conflict in src/jtag/core.c
..
Failed to merge in changes.
Patch fail at 0005 ...

Help :-) I am new to git :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-07 Thread Øyvind Harboe
Hi Tomek,

thanks for working on SWD for OpenOCD.

This is obviously a big change and I hope that everybody on
the list understands that even if this was ready as-is it we
would have to allow plenty of time for everybody to review
this code before it goes into the master branch.

I hope that we can find a sequence of small enough patches
that most people can get their head around each one of the
changes with the time they have available to review the changes
and follow OpenOCD.

-- 
Øyvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 87 40 27

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-07 Thread Tomek CEDRO
Sure thing Oyvind! I am working on the separate repository that is
publicly available, so anyone can take a look at the code, also the
migration using git should be possible easily. When I consider the
work is definitely finished (soon I hope), I will work on providing
small patches :-)

You may stay relaxed because the changes are not that big.. at least
non-invasive - all old stuff should stay untouched except places where
changes were absolutely necessary :-)

The main interest should go to 'src/transport', 'src/interface' (only
new stuff there) and possibly 'src/jtag/drivers/ft2232.c'. Thats all
:-)

The new motto for today is: everything should be done as clean as
possible! :-P

Best regards :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-07 Thread Tomek CEDRO
On Tue, Jun 7, 2011 at 5:02 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 First thing I tried was to rebase your master branch on
 top of origin/master and that didn't work...

Uhm, this is based on a version from March or April... and there are
also some unnecessary changes that should be filtered out I guess.

 Could you rebase it on top of master branch and force a push?

Sure - that wont destroy anything at my side?

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Re: [Openocd-development] General SWD Support in OpenOCD

2011-06-07 Thread Øyvind Harboe
On Tue, Jun 7, 2011 at 7:05 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
 On Tue, Jun 7, 2011 at 5:02 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
 First thing I tried was to rebase your master branch on
 top of origin/master and that didn't work...

 Uhm, this is based on a version from March or April... and there are
 also some unnecessary changes that should be filtered out I guess.

 Could you rebase it on top of master branch and force a push?

 Sure - that wont destroy anything at my side?

You can safely try it locally. You'll have to learn about
about rebasing before this is done...


-- 
Øyvind Harboe

Can Zylin Consulting help on your project?

US toll free 1-866-980-3434 / International +47 51 87 40 27

http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development