Logs are too big for the mailing list. Below is my e-mail without logs.
Regards,
Pieter
-Original Message-
From: Pieter Conradie
Sent: 02 November 2009 09:49 AM
To: 'Øyvind Harboe'
Cc: openocd-development@lists.berlios.de
Subject: RE: [Openocd-development] openocd-0.3.0-rc0 bug: Fail to w
On Mon, Nov 2, 2009 at 8:33 AM, David Brownell wrote:
> On Sunday 01 November 2009, Øyvind Harboe wrote:
>> > I've got the arm9 and armv7m sections of the type tree
>> > cleaned up and sanity tested with target_to_FOO(). When
>> > more is working, I'll post a branch somewhere.
>> >
>> > Later tas
On Sunday 01 November 2009, Øyvind Harboe wrote:
> > I've got the arm9 and armv7m sections of the type tree
> > cleaned up and sanity tested with target_to_FOO(). When
> > more is working, I'll post a branch somewhere.
> >
> > Later tasks can be making "arm926 is-a target" work;
> > and restructur
> CANDIDATES: [1] affecting writes to CFI flash, and
> possibly related to some FT2232H issues too.
[1] is an old bug pre 0.1 even I think. If I get enough testing
feedback soon(excellent so far, but this is a tough one) and I find
a clean fix, then I think we should include it.
--
Øyvind H
On Sun, Nov 1, 2009 at 11:56 PM, David Brownell wrote:
> On Sunday 01 November 2009, Ųyvind Harboe wrote:
>> > At any rate, upcasting is trivial (return &p->foo_struct)
>> > given the current single inheritance, and can't fail.
>>
>> Actually it can. If I pass an interface pointer to a polymorphic
So: We tagged RC0 about four days ago, and there seems to be
agreement that getting it out soon is the way to go.
And: all the committers have been pretty good (thanks!) about
not doing stuff that could destabilize things. Nothing big
enough to justify an RC1, so far...
We're aiming to release
On Friday 30 October 2009, Dimitar Dimitrov wrote:
> Working configuration is high-speed USB. I have only two
> patches in my repository and they were attached to my previous
> message. One is trivial interface configs.
Already merged into mainline...
> The other one
> increases (at least I thi
Mention the autoprobing as a tool that may be useful when
figuring out how to set up; and add a section showing how
to use that mechanism (with an example).
Strengthen the differences between config and run stage
descriptions; split out a section for the latter.
Mention Dragonite.
---
doc/openoc
On Friday 30 October 2009, David Brownell wrote:
> Objections if I merge this?
Merged it...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Sunday 01 November 2009, David Kaplan wrote:
> I'm trying to get u-boot running on a smdk2410-based board.
> I'm using openocd and jtag and am trying to load u-boot into ram as follows:
>
> load_image u-boot.bin 0x33f8
>
> Which *seems* to work:
> 103668 bytes written at address 0x33f8
On Sunday 01 November 2009, Øyvind Harboe wrote:
> > At any rate, upcasting is trivial (return &p->foo_struct)
> > given the current single inheritance, and can't fail.
>
> Actually it can. If I pass an interface pointer to a polymorphic
> routine that operates on that interface, that that impleme
On Sunday 01 November 2009, Øyvind Harboe wrote:
> >
> > So the only time "parent" really makes sense is when
> > talking about a particular integration history: in
> > this branch, it merged right here.
> >
> > Historically, source code patches have been decoupled
> > from base versions specifica
> At any rate, upcasting is trivial (return &p->foo_struct)
> given the current single inheritance, and can't fail.
Actually it can. If I pass an interface pointer to a polymorphic
routine that operates on that interface, that that implementation
can not upcast.
But that's a more general OO probl
On Sun, Nov 1, 2009 at 9:21 PM, David Brownell wrote:
> On Sunday 01 November 2009, Řyvind Harboe wrote:
>> >> Hmm how do I read out which version a git patch is relative to?
>> >
>> > git show --pretty=raw 818cedaff
>> >
>> > instead of just "git show" (or "git log" etc). That includes
>> >
On Sunday 01 November 2009, Øyvind Harboe wrote:
> >> Hmm how do I read out which version a git patch is relative to?
> >
> > git show --pretty=raw 818cedaff
> >
> > instead of just "git show" (or "git log" etc). That includes
> > parent IDs ... possibly more than one for merge commits, as in
On Sunday 01 November 2009, Øyvind Harboe wrote:
> > If by "waiting" you mean "want to see patches", I'll send
> > a larger preview at some point. But container_of() seems
> > already, as Nico noted, sufficient to current tasks... and
> > just simplifying (like above) will be a major win.
>
> I'd
On Sat, Oct 31, 2009 at 6:21 PM, David Brownell wrote:
> On Saturday 31 October 2009, Øyvind Harboe wrote:
>> Hmm how do I read out which version a git patch is relative to?
>
> git show --pretty=raw 818cedaff
>
> instead of just "git show" (or "git log" etc). That includes
> parent IDs ...
> If by "waiting" you mean "want to see patches", I'll send
> a larger preview at some point. But container_of() seems
> already, as Nico noted, sufficient to current tasks... and
> just simplifying (like above) will be a major win.
I'd like to see an interface scheme that allows for optional
int
On Sunday 01 November 2009, Freddie Chopin wrote:
> David Brownell pisze:
> > With "this" being the warning about "-irmask 1" ... since
> > you have that particular hardware, you can test to see if
> > the config files even need to include those two optional
> > parameters for those TAPs.
>
> I th
David Brownell pisze:
With "this" being the warning about "-irmask 1" ... since
you have that particular hardware, you can test to see if
the config files even need to include those two optional
parameters for those TAPs.
I thought it was more complicated than "trial & error" <: If the results
I'm trying to get u-boot running on a smdk2410-based board.
I'm using openocd and jtag and am trying to load u-boot into ram as follows:
load_image u-boot.bin 0x33f8
Which *seems* to work:
103668 bytes written at address 0x33f8
downloaded 103668 byte in 0.500045s
I then try to run it by
21 matches
Mail list logo
