Re: [Openocd-development] status of cortex-m0

[Xiaofan Chen]

On Thu, Oct 27, 2011 at 11:24 AM, Christopher Harvey
 wrote:
> I read a thread about somebody who apparently got cortex m0 cores working
> with OpenOCD. (based on the m3 code). Did that patch ever get posted
> somewhere? Anybody following/working on m0 right now?

The Cortex M0 support will most likely depend on the SWD support
which is now on progress.

Reference thread.
http://lists.berlios.de/pipermail/openocd-development/2011-June/019303.html

Not so sure about the status on Versaloon's swd implementation. You
can check with Simon Qian.
http://www.versaloon.com/index.html
http://lists.berlios.de/pipermail/openocd-development/2011-April/018838.html

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

[Openocd-development] status of cortex-m0

[Christopher Harvey]

I read a thread about somebody who apparently got cortex m0 cores 
working with OpenOCD. (based on the m3 code). Did that patch ever get 
posted somewhere? Anybody following/working on m0 right now?

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

Re: [Openocd-development] Does openocd support cortex A5?

[Xiaofan Chen]

On Thu, Oct 27, 2011 at 10:14 AM, Richard LIU  wrote:
> Thanks a lot, xiaofan.
> My chip is MSM7x27A. If it does not support, I try to port it.
>

Ah I see. This seems to be a very new chip and indeed seems to be
based on Cortex A5 core based on Google.
http://forum.beyond3d.com/showthread.php?t=60402

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

Re: [Openocd-development] Does openocd support cortex A5?

[Richard LIU]

Thanks a lot, xiaofan.
My chip is MSM7x27A. If it does not support, I try to port it.

Best Regards
Richard LIU

On Wed, Oct 26, 2011 at 5:01 PM, Xiaofan Chen  wrote:

> On Wed, Oct 26, 2011 at 11:04 AM, Richard LIU 
> wrote:
> > Does openocd support cortex A5?
>
> The answer seems to be no.
> Any public resource for A5 chips in real world other than the information
> from ARM?
>
> The only one seems to be from Freescale, A5 + M4 hybrid core.
>
> http://www.engadget.com/2011/10/25/freescale-joins-arm-a5-and-m4-cores-at-the-hip-for-performance-a/
>
> --
> Xiaofan
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] New patch to review for openocd: 3dec47d Remove use of undefined variable.

[gerrit]

This is an automated email from Gerrit.

Jim Norris (u17...@att.net) just uploaded a new patch set to Gerrit, which you 
can find at http://openocd.zylin.com/127

-- gerrit

commit 3dec47dff267332a638fc8d84702d3658344a51a
Author: Jim Norris 
Date:   Wed Oct 26 19:30:20 2011 -0500

Remove use of undefined variable.

Change-Id: Id8fd345438c360b2a42857525f05360ce2794d21
Signed-off-by: Jim Norris 

diff --git a/tcl/target/at91sam3nXX.cfg b/tcl/target/at91sam3nXX.cfg
index 29c5ddc..5392824 100644
--- a/tcl/target/at91sam3nXX.cfg
+++ b/tcl/target/at91sam3nXX.cfg
@@ -18,7 +18,7 @@ if { [info exists CPUTAPID ] } {
 jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 
$_CPUTAPID
 
 set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_m3 -endian $_ENDIAN -chain-position 
$_TARGETNAME
+target create $_TARGETNAME cortex_m3 -endian little -chain-position 
$_TARGETNAME
 
 set _FLASHNAME $_CHIPNAME.flash
 flash bank flash0 at91sam3 0x0040 0 0 0 $_TARGETNAME

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

Re: [Openocd-development] Can't push...

[jim norris]

jim norris wrote:

Pushing to ssh://jnor...@openocd.zylinx.com:29418/openocd.git

Typo, there's an extra x in the domain name. Run:

git config remote.review.url ssh://jnor...@openocd.zylin.com:29418/openocd.git

And then try git push review again.



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

Re: [Openocd-development] Can't push...

[Peter Stuge]

jim norris wrote:
> Pushing to ssh://jnor...@openocd.zylinx.com:29418/openocd.git

Typo, there's an extra x in the domain name. Run:

git config remote.review.url ssh://jnor...@openocd.zylin.com:29418/openocd.git

And then try git push review again.


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

Re: [Openocd-development] git gui

[Peter Stuge]

Pete Batard wrote:
> Git is just a tool, feel free to use it as you see fit, GUI or not.

Yes and no. Git is a tool, and of course there are good and bad GUIs,
but the point is that since it's common to work together with others,
and since this is also the setting where git really shines, it's a
good idea to make sure that one's use of git is a) useful for others
and b) the most efficient for self.

It's not a good idea to use git as one sees fit if that ends up being
unfit for others, and it's of course not a good idea to use anything
in an inefficient way.


> But please remember that, like all tools, it has its advantages and 
> limitations.

The only real limitation that I've come across after a few years is
that git really sucks at dealing with a large number of refs
(branches+tags).

I think it's difficult to find a setting where git doesn't offer some
significant advantages over other common choices. The flip side is
that because of those advantages git can also be very different from
said other choices, and that can in itself be enough of a problem to
cancel out all advantages. It depends on the people involved.


> Also don't try impose your views on others with regards to git 
> usage, unless you really have something to say about the quality of
> the patches they submit to mainline.

To clarify for those not following libusb, and to take a concrete
example: Pete's public libusb repo isn't rebased on the main libusb
repo merge queue, but is rather a fork of the main repo from when
Pete started working on libusb.

Pete applies commits from the merge queue and also generates patches
against the merge queue, no problem, except that the patches Pete
generates aren't in his repo. The repository gap is big, which is
a problem. It means that a) Pete has to do some work twice (first
for own repo, then for main repo) and b) everyone else can't really
relate Pete's ongoing work to the main repo using git, only using
patches or in terms of git diff output between files or blobs; no fun.

As with Gerrit, or when using git send-email (like Linux kernel
development) or with git push to say github, where work is based on
other work by someone else, git can be an integral part of the
workflow. In those cases it *is* important how git is being used
locally, because the output from local work is used as input by
others, and a common view is not only reasonable and accurate but
in fact neccessary.

Normal rebase is fundamental for interacting with other efforts.
Interactive rebase is fundamental for reworking patches based on
feedback. Both tasks are common, so I agree with Øyvind that these
git features need to be understood and practised for any sort of fun
and profit with git, and the git UI of choice has to support them.

We can blame git for bad situations that arise when people use it -
Pete's public libusb repo is just one example, the same situation
exists e.g. with Linux kernel ARM trees and within many corporations
with organizational problems - but git doesn't create gaps and forks;
people create gaps and forks, and it typically happens when people
use git as they see fit instead of according to the view of others.


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

Re: [Openocd-development] Can't push...

[Austin, Alex]

There's no "x" in the url.

openocd.zylin.com


> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of jim norris
> Sent: Wednesday, October 26, 2011 6:49 PM
> To: Spencer Oliver
> Cc: Openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] Can't push...
> 
> Here's the verbose output.
> 
> $ git push -v review
> Pushing to ssh://jnor...@openocd.zylinx.com:29418/openocd.git
> ssh: connect to host openocd.zylinx.com port 29418: Connection timed out
> fatal: The remote end hung up unexpectedly
> 
> 
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Can't push...

[jim norris]

Here's the verbose output.

$ git push -v review
Pushing to ssh://jnor...@openocd.zylinx.com:29418/openocd.git
ssh: connect to host openocd.zylinx.com port 29418: Connection timed out
fatal: The remote end hung up unexpectedly


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

Re: [Openocd-development] Can't push...

[Spencer Oliver]

On 27/10/2011 00:13, jim norris wrote:



try now


Nope. Still hangs.


working fine this end, so unsure what to suggest

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

Re: [Openocd-development] Can't push...

[jim norris]

try now


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

Re: [Openocd-development] Can't push...

[Spencer Oliver]

On 27/10/2011 00:10, jim norris wrote:


I'm trying to do a 'git push review' and it just hangs.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


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

[Openocd-development] Can't push...

[jim norris]

I'm trying to do a 'git push review' and it just hangs.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] git gui

[Uwe Hermann]

On Tue, Oct 25, 2011 at 06:52:39PM -0500, jim norris wrote:
> For those using a git gui, what are you using?

I find 'gitk' on Linux to be the best choice (for me) when I
need/want a GUI, but I do most stuff on the command line.


Uwe.
-- 
http://hermann-uwe.de | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] New patch to review for openocd: a6334c6 clang: fix warning about use of unitialized variable

[gerrit]

This is an automated email from Gerrit.

?yvind Harboe (oyvindhar...@gmail.com) just uploaded a new patch set to Gerrit, 
which you can find at http://openocd.zylin.com/126

-- gerrit

commit a6334c6b1313f2bb925f48da73ff6f3c66d5bc5f
Author: Øyvind Harboe 
Date:   Wed Oct 26 22:26:44 2011 +0200

clang: fix warning about use of unitialized variable

this was a false positive, silence it.

Change-Id: I432e0c466c94cf8fd6bbf0ea153c8501a8a261eb
Signed-off-by: Øyvind Harboe 

diff --git a/src/target/arm_simulator.c b/src/target/arm_simulator.c
index 0a34cfc..1723b43 100644
--- a/src/target/arm_simulator.c
+++ b/src/target/arm_simulator.c
@@ -519,7 +519,7 @@ static int arm_simulate_step_core(struct target *target,
/* load register instructions */
else if ((instruction.type >= ARM_LDR) && (instruction.type <= 
ARM_LDRSH))
{
-   uint32_t load_address = 0, modified_address = 0, load_value;
+   uint32_t load_address = 0, modified_address = 0, load_value = 0;
uint32_t Rn = sim->get_reg_mode(sim, 
instruction.info.load_store.Rn);
 
/* adjust Rn in case the PC is being read */

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

Re: [Openocd-development] git gui

[Pete Batard]

On 2011.10.26 16:29, Peter Stuge wrote:

Øyvind Harboe wrote:

my main problem has been that that I've found that those that use Tortoise
have no patience for the complexities and necessity of interactive rebase,
rather than Tortoise lack of support for this feature.


This might fit Pete. In another project I've learned that he prefers
not to use many of the features offered by git, among others indeed
interactive rebase


Well, what do you know. Apparently, and I must say much to my surprise 
as I have recently learned [1], it appears that I simply "decided to 
hate git", which of course should make it "impossible to discuss" such 
matters.


I can't help but wonder though how my usage of git, in my own branch, 
matters so much to Peter, when I don't remember that any of the patches 
I submitted to libusb-devel over the past 2 years to have been faulted 
on a git technicality, or from me apparently not using git the 
"established way". This is even more true as I have a very verifiable 
track record of being able to produce patches very quickly, when 
requested, even for a major headaches like an implementation that has 
evolved on its own, at a very rapid pace, for about a year and that must 
now be integrated. If anything, it should mean that whatever method I 
use to produce them wasn't that detrimental after all...


If you really want to disprove my approach, Peter, then please find some 
verifiable evidence that any part of what I have been doing so far for 
libusb has been detrimental to mainline (rather than try to impose your 
own *personal* views of what a "good" private branch should look like).


Also, since I am always eager to experiment, and as, if anything, it 
might turn out to be the only useful thing generated from this idiotic 
accusation, please do provide a list of the "many features offered by 
git" which myself and others should know about.


For the record, I did follow your last point about git grep and git 
blame on the tcl/slash issue. Right after you posted I actually tried to 
determine whether using git blame in this case might not have been an 
overkill. Turns out there were only 3 small commits in one year on that 
tcl file, which gitweb promptly returned. If anything then, I guess I'm 
still waiting for a better example of git blame and other commands which 
I don't use (regularly|at all) saving the day, just like I am waiting 
for a good example of how, on small projects such as libusb and OpenOCD, 
choosing to never revert anything, and splitting commits ad nauseam 
actually contributes to collectively reduce everybody's time in the long 
run, maintainers AND contributors included.


As with any tool, after careful consideration (especially with regards 
to the fact that libusb is a small project, that sees very few commits, 
that are far in between) and experimentation, I have drawn my own 
conclusion, as I am entitled to, as to what was I consider the most 
effective way. As long as the patches I submitted met the expected 
quality level, and I believe they do, I fail to see why I should have to 
defend myself with regards to how I use git. But anyway, if you want the 
short version, after many months of submitting patches, I found out that 
I was a lot more effective almost never using rebase --of course this 
only pertains to libusb: can't really comment on what I'd do for 
OpenOCD-- or, lately not even merge, but simply slapping patch serials 
or files from one branch into another and hack away (which, having a GUI 
actually makes very enticing, and which maybe you guys should also 
consider as the possible reason why the new generation may not use git 
the exact same way as grandpa does). This is how the latest Windows 
integration patches were produced and I'm still waiting to hear from you 
about how poor quality they truly were...


Should I infer then, that, when I voluntarily decided to contribute to 
libusb, not only did I unknowingly sign a contract that strips me from 
the right to use to use a tool exactly the way I see fit, and that I was 
instead supposed to adhere to the "one true way" to use git? I think I 
must have missed Git Indoctrination 101.


What I did not miss however were some of the deplorable action of 
mindless git worshippers, such as Peter, that pretty much sent us back 6 
months on libusb-devel, with regards to the obnoxious CRLF issue, with 
the oh-so-maintainer-commendable actions of:


1. Taking about 3 months to start looking into a patch that was clearly 
identified as possibly contentious with regards to git (but then again, 
having to wait months before any serious review started was the fate of 
most Windows patches).


2. Getting bitten from the git documentation when trying to prove a 
critical point (about how others must have simply misread the 
documentation) and ending up interpreting the documentation wrong.


3. When seeing their arguments disproved, resorting to a very 
unprofessional "I just don't want CRLF in the g

Re: [Openocd-development] git gui

[Austin, Alex]

> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Pete Batard
> Sent: Wednesday, October 26, 2011 6:26 AM
> To: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] git gui
> 
> On 2011.10.26 06:07, Øyvind Harboe wrote:
> > On Wed, Oct 26, 2011 at 2:12 AM, Peter Stuge  wrote:
> >> jim norris wrote:
> >>> For those using a git gui, what are you using?
> >>
> >> On which system?
> >>
> >> For Windows, there is Git Extensions and TortoiseGit. The Git
> >> Extensions looked less slick than TortoiseGit last time I looked, but
> >> TortoisGit on the other hand lacked fundamental functionality.
> >
> > I recommend Gerrit. Gerrit makes a lot of the nastier concepts,
> > like interactive rebasing and communication easier.
> >
> >  From my experience TortoiseGit is a step down the wrong path.
> >
> > It makes things easier than possible, i.e. it tosses hard concepts
> > out of the window. Where is the interactive rebase functionality?
> 
> You mean, this [1]?
> 
> For the record, I have been using TortoiseGit pretty much on a daily
> basis, for almost two years now and from my personal experience, not
> only have I found it filling pretty much all of my git needs (besides,
> it's based on msys-git, so commandline git is only one click away), but
> also, unlike Peter, I found that if there's one tool that benefits
> greatly from having a solid GUI, it has to be git. Who'd want to go back
> to using commandline for diffs, log, or branch switching, when you have
> a GUI with *easy* navigation at your fingertips [2]?.
> 
> Also, judging from the general praise for gerrit, which also provides a
> solid GUI frontend albeit web based (hence more complex for regular git
> users to setup on their own -- I wouldn't advocate it as a solution for
> a user who simply wants a GUI on their machine), I can only assume that
> many have come to share the view that some GUI ontop of git actually
> does wonders.
> 
> Thus, do you guys, who seem to be opposed to the use of TortoiseGit,
> have better evidence to back up your claims?
> 
> If not, I would advise Jim to take Øyvind and Peter's advice with a
> grain of salt, or at least also consider the advice of someone who,
> through nearly two years of continuous usage, has reason to believe that
> using TortoiseGit has actually increased their git productivity. Of
> course, just like Peter and Øyvind's, this is merely an opinion.
> 
> Regards,
> 
> /Pete
> 
> [1] http://img689.imageshack.us/img689/697/tgitinteractiverebase.png
> [2] http://img190.imageshack.us/img190/3281/tgitdiff.png
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development

I guess TortoiseGit has come a long way since I last looked. I have seen
it corrupt a repository[1], but that could be a known bug that's long-
fixed. I've always used Git on the command line, and when trying to use
Mercurial, I find it's command-line interface quite irritating in how
much it doesn't do.

I generally use the Git command-line interface alongside gitk, using
gitk like a GPS navigator of the repo history; It shows me where I've
been, where I am now, and gives me easy quick reference to where I want
to be, making command line tools far more palatable.

I do use the "git gui blame" tool. I also mentioned git gui before; It
seems to lack functionality upon first look, but has excellent display
and browsing ability.

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

Re: [Openocd-development] Amontec - Out of business?

[Ananda Regmi]

Just wanted to let everybody know that I received my Amontec JTAGKey Tiny
this morning. I never received any notification that it has been shipped or
any replies to any of my inquiries but I did receive the item.

-Ananda

On Tue, Oct 25, 2011 at 8:49 AM, Ananda Regmi wrote:

> Thanks for your input Christopher. Don't get me wrong. I have been using
> one right now and it's been working great. And I do already have the cable.
> The problem here is this cold, unresponsive customer service.
>
> -Ananda
>
>
> On Mon, Oct 24, 2011 at 3:06 PM, Christopher Harvey <
> ch...@basementcode.com> wrote:
>
>> On Mon, 24 Oct 2011 14:53:33 -0600, Ananda Regmi wrote:
>>
>>> Attila,
>>>
>>> I wouldn't mind giving them some time as long as they keep
>>> communicating with me. I am hitting a blank wall on Amontec's side. I
>>> have tried sending emails to their sales, customer service, their CEO
>>> and I don't get any thing back.
>>>
>>> Yegor,
>>>
>>>
>> When I ordered my JTagKey2 I didn't receive any notification of shipment.
>> I emailed them and Laurent got back to me within 24h saying that it was
>> shipped. This was about 4 months ago. It took a couple of weeks for it to
>> actually arrive. In the meantime you should check out 20 pin jtag connector
>> cables since my JTagaKey2 didn't come with onebut otherwise it's a fine
>> product.
>>
>> __**_
>> Openocd-development mailing list
>> Openocd-development@lists.**berlios.de
>> https://lists.berlios.de/**mailman/listinfo/openocd-**development
>>
>
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Another git question....

[Peter Stuge]

Øyvind Harboe wrote:
> On Wed, Oct 26, 2011 at 3:09 PM, jim norris  wrote:
> >
> >
> >  Assuming I've done my commits. How do I see what the
> >  patch will look like before I do the 'git push review'?
> 
> git format-patch origin/master
> 
> => produces patch files

I would recommend using git log rather than generating patch files,
since the output can be coloured to very clearly mark whitespace
issues and since no files need to be created.

git log -p origin/master..


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

Re: [Openocd-development] git gui

[Øyvind Harboe]

I have a problems with a GUI that makes git easy to use at the
cost of not enabling and teaching the user to use the more advanced
concepts.

Interactive rebasing is an absolute must when working with git. Anything
that leaves the user with the impression that he doesn't have to get
his head around interactive rebase is oversimplifying git(and DVCS
in general).

-- 
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] git gui

[Peter Stuge]

Øyvind Harboe wrote:
> my main problem has been that that I've found that those that use Tortoise
> have no patience for the complexities and necessity of interactive rebase,
> rather than Tortoise lack of support for this feature.

This might fit Pete. In another project I've learned that he prefers
not to use many of the features offered by git, among others indeed
interactive rebase and the quick and easy way to deal with branches -
and in that case TortoiseGit can of course work fine.

I've evaluated Tortoise together with multiple developers who use
Windows and it never ended up as the prefered tool, simply because
it didn't have wanted features. If it has all features *you* want
then of course it's as good a pick as any other, but at the time
we looked at it, it wasn't really useful for taking advantage of git,
and everyone picked Git Extensions or git bash instead. Some of the
guys especially like that Git Extensions integrates at all with
Visual Studio.


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

Re: [Openocd-development] git and gerrit questions

[Øyvind Harboe]

On Wed, Oct 26, 2011 at 3:14 PM, jim norris  wrote:
>
>
> How does gerrit determine whether a patch is a subsequent
> patch for a file?

You update the commit and keep the change-id in the commit
comment and do a git push review.

I don't know if that's what you're asking.

git rebase interative allows you to edit a commit if you will.



-- 
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] git and gerrit questions

[jim norris]

How does gerrit determine whether a patch is a subsequent
patch for a file? Or maybe the better question is: Are the steps
outlined by Alex the only means to submit an amended patch?


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

Re: [Openocd-development] gerrit comments as mail?

[Spencer Oliver]

On 26 October 2011 13:35, Attila Kinali  wrote:
> Moin,
>
> Would it possible to have gerrit comments as mails to the mailinglist
> as well?
>

This is down to taste - some would class lots of gerrit emails spam.

My suggestion is to watch the openocd project in gerrit, enabling emails there:
http://openocd.zylin.com/#settings,projects

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

Re: [Openocd-development] Another git question....

[Øyvind Harboe]

On Wed, Oct 26, 2011 at 3:09 PM, jim norris  wrote:
>
>
>  Assuming I've done my commits. How do I see what the
>  patch will look like before I do the 'git push review'?

git format-patch origin/master

=> produces patch files




-- 
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] gerrit comments as mail?

[Øyvind Harboe]

How about going to openocd.zylin.com and checking which patches are
still outstanding every few days?


-- 
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Another git question....

[jim norris]

 Assuming I've done my commits. How do I see what the
 patch will look like before I do the 'git push review'?

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

[Openocd-development] gerrit comments as mail?

[Attila Kinali]

Moin,

Would it possible to have gerrit comments as mails to the mailinglist
as well?

My usual way of working is to go over a developement mailinglist once
every few days (when time permits) and check what has been going on.
When i see a patch that looks interesting, i go and check what has
to be done with it. On projects that handle the whole patchmanagment
on the mailinglist, this is often not necessaary, as i see in the
discussion whether this patch has allready been accepted or not,
or whether there was no discussion at all. With gerrit i first have
to open up a browser with the link to the patch, just to figure
out that the patch has been already abandoned by the author.

Hence, if possible, i'd ask to send comments to the mailinglist as
well, with correct In-Reply-To field for propper threading.

If it's not possible.. just leave it :-)

Attila Kinali

-- 
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] jimtcl compile error

[billium]

On 25/10/11 15:20, Alexander Stein wrote:
> On Monday 24 October 2011 20:24:57 billium wrote:
>> I am trying to update openocd but it fails to build:
>>
>> In function `Jim_Nvp_name2value_obj':
>> jim-nvp.c:(.text+0xc7): undefined reference to `Jim_String'
>>
>> This is repeated four times for other instances of Jim_String.
>>
>> I am using amd64 on Gentoo, with the 999 ebuild which pulls from git.
>> Anybody come across this or know what I am doing wrong?
>>
>> Incidentally there is a member of the the Nashoba Valley Photo Club
>> (NVPC) called Jim
> As Peter already said, something was moved from jimtcl into openocd. You need 
> to recompile dev-lang/jimtcl- and openocd should compile again afterwards.
>
> Regards,
> Alexander
I changed dev-lang/jimtcl to ** (-) as Alexander suggested, and it
worked.
Many thanks for the answers.

Billy

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

Re: [Openocd-development] git gui

[Øyvind Harboe]

Hi Pete,

thanks for the corrections about my prejudice against Tortoise. I guess
my main problem has been that that I've found that those that use Tortoise
have no patience for the complexities and necessity of interactive rebase,
rather than Tortoise lack of support for this feature.

Gerrit is a piece to the GUI puzzle that is completely independent of what
Tortoise covers. Both are needed.

I know some Windows users who might be willing and interested in trying
out Tortoise. Much of the support I provide for git happens via email.
Documenting procedures and explaining what to do is much easier with
command line, than to try to explain how to use a web interface.

I don't use Windows myself, so from that point of view TortoiseGit is a
non-starter. I see that there is a tortoisehg for Linux.

-- 
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] git gui

[Pete Batard]

On 2011.10.26 06:07, Øyvind Harboe wrote:

On Wed, Oct 26, 2011 at 2:12 AM, Peter Stuge  wrote:

jim norris wrote:

For those using a git gui, what are you using?


On which system?

For Windows, there is Git Extensions and TortoiseGit. The Git
Extensions looked less slick than TortoiseGit last time I looked, but
TortoisGit on the other hand lacked fundamental functionality.


I recommend Gerrit. Gerrit makes a lot of the nastier concepts,
like interactive rebasing and communication easier.

 From my experience TortoiseGit is a step down the wrong path.

It makes things easier than possible, i.e. it tosses hard concepts
out of the window. Where is the interactive rebase functionality?


You mean, this [1]?

For the record, I have been using TortoiseGit pretty much on a daily 
basis, for almost two years now and from my personal experience, not 
only have I found it filling pretty much all of my git needs (besides, 
it's based on msys-git, so commandline git is only one click away), but 
also, unlike Peter, I found that if there's one tool that benefits 
greatly from having a solid GUI, it has to be git. Who'd want to go back 
to using commandline for diffs, log, or branch switching, when you have 
a GUI with *easy* navigation at your fingertips [2]?.


Also, judging from the general praise for gerrit, which also provides a 
solid GUI frontend albeit web based (hence more complex for regular git 
users to setup on their own -- I wouldn't advocate it as a solution for 
a user who simply wants a GUI on their machine), I can only assume that 
many have come to share the view that some GUI ontop of git actually 
does wonders.


Thus, do you guys, who seem to be opposed to the use of TortoiseGit, 
have better evidence to back up your claims?


If not, I would advise Jim to take Øyvind and Peter's advice with a 
grain of salt, or at least also consider the advice of someone who, 
through nearly two years of continuous usage, has reason to believe that 
using TortoiseGit has actually increased their git productivity. Of 
course, just like Peter and Øyvind's, this is merely an opinion.


Regards,

/Pete

[1] http://img689.imageshack.us/img689/697/tgitinteractiverebase.png
[2] http://img190.imageshack.us/img190/3281/tgitdiff.png
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Does openocd support cortex A5?

[Xiaofan Chen]

On Wed, Oct 26, 2011 at 11:04 AM, Richard LIU  wrote:
> Does openocd support cortex A5?

The answer seems to be no.
Any public resource for A5 chips in real world other than the information
from ARM?

The only one seems to be from Freescale, A5 + M4 hybrid core.
http://www.engadget.com/2011/10/25/freescale-joins-arm-a5-and-m4-cores-at-the-hip-for-performance-a/

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