On Monday 05 October 2009, Nico Coesel wrote:
> Is the entire repository (including all branches and tags)
> moved to SF or just head?
Right now there are git-svn repositories that have whatever
could be imported, but I think just the trunk is at SF.
Is there anything in those branches/etc that'
On Monday 05 October 2009, Ronald Vanschoren wrote:
> Please keep in mind some people are using Windows here.
There are quite a few folk using git from Windows...
Not three hours ago I pulled a repository onto an XP
machine (via cygwin).
The build breakage was completely unrelated to GIT.
___
On Saturday 03 October 2009, John Rigby wrote:
> You were right about the ir lengths, but I also had to put back in the code
> that ignores non b01 for taps with 0 ids. The i.mx31 has the same weird tap
> with no id and no b01 in the capture.
Hmm. I changed the diagnostics a bit in a recent pat
Hi Dirk,
--- Dirk Behme schrieb am Mo, 5.10.2009:
> Rolf, could you try if
>
> git clone http://git.gitorious.org/u-boot-omap3/mainline.git
>
> works for you?
>
Yes, that works for me! I can successfully clone this very small project on
github, too: http://github.com/tekkub/addontemplate.gi
> 1. Berlios svn will be made read only and the svn head will be "deleted",
> leaving behind only a README w/reference to the openocd project at
> sourceforge. The entire svn history will remain available on Berlios
> indefinitely.
Question from a dumb-ass:
Is the entire repository (including all
I did not but I have now and tbh I'm not impressed. Sure git has some
advantages, but do we really care about the distributed nature, better
branch support, higher performance and other things? What I read was:
>Also not mentioned are Subversion's support for http(s) and
WebDAV,
and its excell
On Tue, Oct 6, 2009 at 8:23 AM, Ronald Vanschoren wrote:
>>!!! And if anyone objects to GIT, please speak up ASAP !!!
>
> Why are we moving to GIT anyway? What was wrong with SVN?
Did you read up on git?
http://git.or.cz/gitwiki/GitSvnComparsion
--
Øyvind Harboe
http://www.zylin.com/zy1000.htm
>!!! And if anyone objects to GIT, please speak up ASAP !!!
Why are we moving to GIT anyway? What was wrong with SVN?
gr.
Ronald
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd
The guess-rev.sh script is now a tweaked version of "setlocalversion" as
seen in Linux, U-Boot, and various other projects. When it finds source
control support (git, hg, svn) it uses IDs from there. Else it reports
itself as "-snapshot", e.g. from gitweb.
Also update the generic version strings
On Tue, Oct 6, 2009 at 8:05 AM, Antti P Miettinen wrote:
> Øyvind Harboe writes:
>> Other?
>
> Please keep gmane.org mirroring the list where ever it will be :-)
Is there such a thing as distributed mailing lists so it won't matter
if server go down? (I never looked into good old news... :-)
--
Øyvind Harboe writes:
> Other?
Please keep gmane.org mirroring the list where ever it will be :-)
--
http://www.iki.fi/~ananaza/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openo
On Tue, Oct 6, 2009 at 12:34 AM, Austin, Alex
wrote:
> Since many people seem to not be fond of sourceforge, have
> you considered GitHub? Just put a README.markdown in the
> project and it will become a nice webpage front for the
> project.
I want the web pages to be browsable offline, which
is
W.r.t. the choice of sourceforge for git:
- we already have it running and tested there
- there is no obviously superior alternative. If we switch
every time we find something that is 10% better, we'll
never get stability and a decision in place.
Does anyone know a git hosting alternative that is
On Monday 05 October 2009, Xiaofan Chen wrote:
> >> have you considered GitHub?
> >
> > In terms of GIT support is it significantly better
> > than SourceForge?
>
> I hear that it is better. Greg KH is using it for
> libusb mirror, usbutils and usbview.
I'm not sure that has anything to do with b
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: Monday, October 05, 2009 6:37 PM
> To: openocd-development@lists.berlios.de
> Cc: Austin, Alex
> Subject: Re: [Openocd-development] Moving to git
>
> On Monday 05 October 2009, Austin, Alex wrote:
> > Since
On Tue, Oct 6, 2009 at 7:37 AM, David Brownell wrote:
> On Monday 05 October 2009, Austin, Alex wrote:
>> Since many people seem to not be fond of sourceforge,
>
> AFAIK that's just the email. Which has issues like
> crappy archives, bad spam filtering, ads, and such.
>
>
>> have you considered G
And in case anyone wants suggestions about how to start
learning ...
http://git-scm.com/course/svn.html
That's addressed to folk more familiar with SVN than GIT.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https:/
On Tue, Oct 6, 2009 at 2:36 AM, Dirk Behme wrote:
>> 3. the mailing list will be disabled and all openocd subscribers will
>> receive an invitation to subscribe to the openocd mailing list at
>> sourceforge. The sourceforge mailing list is the least sucky
>> alternative for hosting mailinglists a
On Monday 05 October 2009, Austin, Alex wrote:
> Since many people seem to not be fond of sourceforge,
AFAIK that's just the email. Which has issues like
crappy archives, bad spam filtering, ads, and such.
> have you considered GitHub?
In terms of GIT support is it significantly better
than S
Le 05/10/2009 17:19, Øyvind Harboe a écrit :
> So the only thing we need to agree on *now* is to
> move git to sourceforge.
>
>
I am supportive of the move to sourceforge.
> No dissent heard so far on that one.
>
> I also believe there is a consensus that Berlios does
> not have the qualities
Hello Øyvind,
Monday, October 5, 2009, 11:28:45 PM, you wrote:
ØH> "Migrate away from Berlios" committe wants an alternative
ØH> to Berlios mailing lists.
ØH> Some alternatives so far:
ØH> - Set up seperate openocd.org server => not going to happen. We
ØH> don't have the resources and dedicatio
Since many people seem to not be fond of sourceforge, have
you considered GitHub? Just put a README.markdown in the
project and it will become a nice webpage front for the
project. They already provide source browsing and snapshots
available via HTTP, and make it trivially easy for anyone
to (a) fo
I was going to set up a mirror of the sourceforge git at
http://repo.or.cz/, except that it does not support mirroring
anything but http:// url's and sourceforge uses git:// for
public url's. G.
Other than that http://repo.or.cz/ looks *great*. No fluff,
just a mirror that's updated every
"Migrate away from Berlios" committe wants an alternative
to Berlios mailing lists.
Some alternatives so far:
- Set up seperate openocd.org server => not going to happen. We
don't have the resources and dedication to run it.
- sourceforge mailing lists apparently suck more than Berlios
mailing li
So the only thing we need to agree on *now* is to
move git to sourceforge.
No dissent heard so far on that one.
I also believe there is a consensus that Berlios does
not have the qualities we're looking for and that
we need to either move away now or get a plan
in place asap for migrating away.
On Monday 05 October 2009, Øyvind Harboe wrote:
>
> In short, the following will happen:
>
> 1. The source will be held in git.
>
> https://sourceforge.net/projects/openocd/
!!! And if anyone objects to GIT, please speak up ASAP !!!
So far the only issue raised with $SUBJECT seems to be
that
On Monday 05 October 2009, Øyvind Harboe wrote:
> > Switching mailing list servers is IMO something to do only when
> > we have a clearly better alternative lined up. Switching is such
> > a PITA that I think we're better off with Berlios for now.
>
> What alternative is better, short of running
> >> http://repo.or.cz/m/regproj.cgi
> >
> > Looks like it; yes. Will you set that up?
>
> Yes. We can also have a link from the sourceforge pages of
> the official mirror...
Let me know as soon as you've done that; I'm prepping a
patch to switch all the source tree references from SVN
to GIT,
> There was a suggestion for using Google groups to host the mailing list.
> I've had success with it in the past with projects like Symfony. As long as
> the mailing list isn't hosted on Yahoo groups, I won't complain (LEON3
> people do this and I don't like it).
OK. Google groups is one alterna
>
> >> 3. the mailing list will be disabled and all openocd subscribers will
> >> receive an invitation to subscribe to the openocd mailing list at
> >> sourceforge. The sourceforge mailing list is the least sucky
> >> alternative for hosting mailinglists at this point.
> >
> > It is my understandi
>> 2. The Berlios web page will be changed into a stub pointing
>> to sourceforge.
>
> It is my understanding that there are at least two votes for not doing this
> immediately.
We need more time to discuss web page + mailing list, but I don't
think there is anybody who has any objections to movin
Øyvind Harboe wrote:
> Zach, David and I as maintainers constitute the committee
> to move OpenOCD to sourceforge and make some choices
> about how things will be moved on behalf of the community.
>
> We want input from the community, but we also need a bit
> of leadership to execute the steps.
>
On Mon, Oct 5, 2009 at 8:12 PM, David Brownell wrote:
> On Monday 05 October 2009, Øyvind Harboe wrote:
>> > Lacking that, we might want a git mirror at a site which
>> > does have easier HTTP access.
>>
>> Like
>>
>> http://repo.or.cz/m/regproj.cgi
>>
>> ?
>
> Looks like it; yes. Will you set th
On Monday 05 October 2009, Øyvind Harboe wrote:
> > Lacking that, we might want a git mirror at a site which
> > does have easier HTTP access.
>
> Like
>
> http://repo.or.cz/m/regproj.cgi
>
> ?
Looks like it; yes. Will you set that up?
IMO having a public mirror is a Good Thing in any case.
Zach, David and I as maintainers constitute the committee
to move OpenOCD to sourceforge and make some choices
about how things will be moved on behalf of the community.
We want input from the community, but we also need a bit
of leadership to execute the steps.
In short, the following will happe
> Switching mailing list servers is IMO something to do only when
> we have a clearly better alternative lined up. Switching is such
> a PITA that I think we're better off with Berlios for now.
What alternative is better, short of running your own server?
Even with a free server, we don't have t
David Brownell wrote:
...
>> Has anyone solved the problem of git access from behind a
>> strict HTTP proxy?
...
> Lacking that, we might want a git mirror at a site which
> does have easier HTTP access.
Rolf, could you try if
git clone http://git.gitorious.org/u-boot-omap3/mainline.git
works fo
On Monday 05 October 2009, Dirk Behme wrote:
> As far as I can see as a user, I'm fine with Berlios mailing list and
> archive (except the outage the last days).
Yeah, I'm mostly OK with it ... except for it being a closed list,
which completely eliminates "casual" contact (not just spam) and
rem
> Lacking that, we might want a git mirror at a site which
> does have easier HTTP access.
Like
http://repo.or.cz/m/regproj.cgi
?
You can also clone/pull a repository to a usb stick from outside
a firewall.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG
On Monday 05 October 2009, Rolf Meeser wrote:
> Hi David,
>
> > Right now I think there seems to be general agreement to
> > switch to that GIT repository in the next couple of days.
> > (So I encourage everyone to switch ASAP ...)
>
> I felt encouraged immediately,
Yay!
> but now I'm stuck...
Hi,
On Mon, Oct 5, 2009 at 17:02, Øyvind Harboe wrote:
>> I'm not sure if we really want SourceForge, though. Especially for mailing
>> lists. U-Boot moved away from it because of pain:
>>
>> http://lists.denx.de/pipermail/u-boot/2008-August/038001.html
>>
>> (not mentioned there: Spam handling)
Øyvind Harboe wrote:
>> I'm not sure if we really want SourceForge, though. Especially for mailing
>> lists. U-Boot moved away from it because of pain:
>>
>> http://lists.denx.de/pipermail/u-boot/2008-August/038001.html
>>
>> (not mentioned there: Spam handling)
>
> What other free viable options
> Can Sourceforge be configured for HTTP access, or is the git
> protocol the only option?
With git mirrors are trivial. You can use any protocol, even
usb sticks...
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
> I'm not sure if we really want SourceForge, though. Especially for mailing
> lists. U-Boot moved away from it because of pain:
>
> http://lists.denx.de/pipermail/u-boot/2008-August/038001.html
>
> (not mentioned there: Spam handling)
What other free viable options are there?
sourceforge mailing
David Brownell wrote:
> On Monday 05 October 2009, Dirk Behme wrote:
>> What's about staying with all we have at Berlios (mailing list, home
>> page etc) and just switching the source code to git, e.g. at gitorious?
>
> We already have a GIT tree at SourceForge, it's been there
> for a month or t
Hi David,
> Right now I think there seems to be general agreement to
> switch to that GIT repository in the next couple of days.
> (So I encourage everyone to switch ASAP ...)
>
I felt encouraged immediately, but now I'm stuck...
Has anyone solved the problem of git access from behind a strict
Typed up patch attached that gives target script more control over
how OpenOCD sets up the interface + target before
examining.
Not tested. Feedback needed!
Change jtag_init to avoid the init without a prior reset:
proc jtag_init {} {
#Make sure we reset the hardware before we talk to it
> What's about staying with all we have at Berlios (mailing list, home page
> etc) and just switching the source code to git, e.g. at gitorious?
Berlios does not have the track record that I'm looking for
w.r.t. availability, posting public list of outages, etc.
I want to see the main git server
[ RESEND -- got a bounce from the Berlios list outage ]
On Sunday 06 September 2009, Øyvind Harboe wrote:
> > Public ICEpick docs are incomplete, but the ones I found
> > were not clear on whether the state mattered ... maybe the
> > issue is that it *does* matter somewhat, and clocking in
> > JTA
On Monday 05 October 2009, Dirk Behme wrote:
> What's about staying with all we have at Berlios (mailing list, home
> page etc) and just switching the source code to git, e.g. at gitorious?
We already have a GIT tree at SourceForge, it's been there
for a month or two now ... see the fairly stone-
Øyvind Harboe wrote:
> Berlios has been down for several days.
>
> There has previously been some talk about switching to git
> as a source control for all sorts of other reasons, but there
> never was a reason to do the work.
>
> While we are thankful for the hosting service Berlios has provided
I've started a new thread on how jtag_init() should be handled
to give the target script much more control.
Your patch allows for a particular type of change, but I'd rather
make it much more general.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger a
During the "init" command jtag_init() is invoked.
I'm thinking that how and when to handle jtag_init_inner() and
jtag_init_reset() should be under target script control, if they
are invoked at all.
When and how the target device becomes able to communicate
can be quite involved as we know from th
> Any objection if I restore the previous default, while still
> ensuring that the "reset_config" command can control this?
Sounds good to me. Thanks for spotting this and pitching in.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash progr
I updated it a bit more, mostly to catch user-visible
changes that made it into the User's Guide but not yet
into NEWS.
My two cents: if it's a user-visible change beyond a
trivial bugfix, it's worth having in NEWS. So please
scan the appended text to see if it's missing much of
significance...
On Tuesday 29 September 2009, jie zeng wrote:
> I cannot halt it but after type `regs' command it shows me almost
> registers are 0x.
> "debug_ctrl" is not zero(no log now). Others I'm not sure.
You would need to type "reg debug_ctrl" to check;
it won't read that otherwise
Another thing t
The problem I have with this patch is the concept that the
interface is in a particular sate when OpenOCD is not
running where it is possible to "smoothly"
transition into the "OpenOCD state".
How about allowing scripts to override the "init"
of OpenOCD to e.g. add a sleep after the device is
init
On Saturday 03 October 2009, John Rigby wrote:
> > is there; it looks bizarre, that *is* an LSB of b0001, it's
> > the next bits that are odd.
>
> This diagnostic is misleading. It does not give the position where it was
> expecting the 01. The string is the entire captured data. The right most
On Wednesday 16 September 2009, Øyvind Harboe wrote:
> --- src/target/arm7_9_common.c(revision 2714)
> +++ src/target/arm7_9_common.c(working copy)
> @@ -1021,6 +1021,17 @@
> return ERROR_FAIL;
> }
>
> + /* at this point trst has been asserted/deasserted once
Does this mail reach the list?
(Do not respond, I'll see it in the archives :-)
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@
David,
You were right about the ir lengths, but I also had to put back in the code
that ignores non b01 for taps with 0 ids. The i.mx31 has the same weird tap
with no id and no b01 in the capture. The i.mx25 config and patch are
attached.
John
On Sat, Oct 3, 2009 at 6:03 PM, David Brownell
David,
Thanks for the info. I'm slowly making progress.
On Fri, Oct 2, 2009 at 4:58 AM, David Brownell wrote:
..
>
> I'm not sure why that diagnostic
>
> Error: imx25.cpu: IR capture error; saw 0x3E1011 not 0x..1
>
> is there; it looks bizarre, that *is* an LSB of b0001, it's
> the next
I've changed my mind. It helps if I read through the patch. :-)
This patch makes it possible for a config script to skip
the reset on starting up OpenOCD. This makes a lot
of sense to me.
How and when to start communicating with the target after
launching OpenOCD *should* be under the target conf
Here is the patch on jtag_reset_on_init (again).
This fixes the problem with Olimex dongle (on power-on it drives srst
low) but will also fix libftd2xx.so library (asserts srst for > 250ms).
On Thu, 2009-10-01 at 07:32 +0200, Øyvind Harboe wrote:
> > 1. put reset_on_init patch that I submitted
On Friday 02 October 2009, David Brownell wrote:
> My previous proposal here is twofold:
>
> 1 - First, to make sure the TAP will have been
> enabled! Add a new "post-verify" method to
> kick in after the scan chain verification,
> which can "jtag tapenable $TAPNAME".
And for th
Add a new "jtag-setup" event; use for better DaVinci ICEpick support.
The model is that this fires after scanchain verification, when it's
safe to call "jtag tapenable $TAPNAME". So it will fire as part of
non-error paths of "init" and "reset" command processing. However it
will *NOT* trigger du
Berlios has been down for several days.
There has previously been some talk about switching to git
as a source control for all sorts of other reasons, but there
never was a reason to do the work.
While we are thankful for the hosting service Berlios has provided,
the OpenOCD maintainers are serio
67 matches
Mail list logo
