On Wed, Mar 06, 2013 at 09:44:36AM +0800, Xiaofan Chen wrote:
>
> 0.7.0 is not a bad them. And that is a small thing not really worth
> arguing about.
Just to say I wasn't arguing. I am saying it would help others if the
reason for a release is clear from the release so users (including new
ones
>>> I think that the process discussion is interesting and very
>>> important, everyone in a project must agree on process, otherwise
>>> it's not really possible to cooperate. Let's continue that
>>> discussion!
>> Let's not waste time on such endless discussions that lead nowhere.
>> No everyone
Hello,
On 26.02.2013 16:12, John wrote:
> On Tue, Feb 26, 2013 at 12:15:27PM +0200, Vladimir Zapolskiy wrote:
>> Hello,
>>
>> still there is no review or response on the patch, wouldn't it be
>> good to have support of one more target in OpenOCD?
>>
>> If any problems are found with the change, pl
On 6 March 2013 08:52, Vladimir Zapolskiy wrote:
> Hello,
>
> On 26.02.2013 16:12, John wrote:
>> On Tue, Feb 26, 2013 at 12:15:27PM +0200, Vladimir Zapolskiy wrote:
>>> Hello,
>>>
>>> still there is no review or response on the patch, wouldn't it be
>>> good to have support of one more target in
Le 05.03.2013 20:52, Peter Stuge a écrit :
> Freddie Chopin wrote:
>>> but why 0.7.0 ? for me this is a non-sense !
>> Any better ideas?
> If it's supposed to be a time based release, then identify it as
> such. Think ubuntu.
>
>
> //Peter
>
> ---
2013/3/6 Laurent Gauch :
>
I think that the process discussion is interesting and very
important, everyone in a project must agree on process, otherwise
it's not really possible to cooperate. Let's continue that
discussion!
>>> Let's not waste time on such endless discussions th
On 6 March 2013 01:44, Xiaofan Chen wrote:
> On Wed, Mar 6, 2013 at 8:41 AM, John wrote:
>> On Tue, Mar 05, 2013 at 11:35:28PM +0100, Freddie Chopin wrote:
>> I can't see why you right now want a new release at all.
>>
>> If you do, it appears to be a time-based one.
>
> There is nothing wrong to
On 6 March 2013 10:27, Franck Jullien wrote:
> 2013/3/6 Laurent Gauch :
>
>> I like the Peter's idea, but it is not realist !
>> As LibUsb story, OpenOCD need to respect the patch publisher and merge
>> the patches faster. If not, you do not respect the patch publisher and
>> you will lost quickly
From: FengGao
This patch set add mips64 support, and common 64bit support.
I defined the target_ulong to support 32bits and 64bits address
as the same time, which come from QEMU.
FengGao (6):
use target_ulong instead of uint
add mips64 core files
add mips64 pracc space to transfer data
a
From: FengGao
Add mips64 common support.
Signed-off-by: FengGao
---
src/target/mips64.c | 814 +++
src/target/mips64.h | 299 +++
2 files changed, 1113 insertions(+)
create mode 100644 src/target/mips64.c
create mode 100644 sr
From: FengGao
Add mips64 ejtag commands handling functions into mips_ejtag.c and
mips_ejtag.h
Add mips64 stubs into Makefile.am
Signed-off-by: FengGao
---
src/target/Makefile.am | 12 +++-
src/target/mips_ejtag.c | 174 +++
src/target/mips_ejtag.
From: FengGao
Add dma access for mips64 arch
Signed-off-by: FengGao
---
src/target/Makefile.am |3 +-
src/target/mips64_dmaacc.c | 634
src/target/mips64_dmaacc.h | 52
3 files changed, 688 insertions(+), 1 deletion(-)
create mode 1
From: FengGao
Add mips5kc target.
Signed-off-by: FengGao
---
src/target/Makefile.am |1 +
src/target/mips64_5kc.c | 1351 +++
src/target/mips64_5kc.h | 57 ++
src/target/target.c |2 +
4 files changed, 1411 insertions(+)
create mode 1
On Wed, Mar 6, 2013 at 7:22 PM, Feng Gao wrote:
> From: FengGao
>
> This patch set add mips64 support, and common 64bit support.
> I defined the target_ulong to support 32bits and 64bits address
> as the same time, which come from QEMU.
>
> FengGao (6):
> use target_ulong instead of uint
> ad
On Wed, Mar 6, 2013 at 7:08 PM, Spencer Oliver wrote:
> On 6 March 2013 10:27, Franck Jullien wrote:
>> 2013/3/6 Laurent Gauch :
>>
>>> I like the Peter's idea, but it is not realist !
>>> As LibUsb story, OpenOCD need to respect the patch publisher and merge
>>> the patches faster. If not, you d
Hi Freddie,
Freddie Chopin wrote:
>
> There are some docs about MPU in ARM documentation (nothing in ST
> docs), or in LPC17xx manuals (probably easier to read than ARM's).
>
> 4\/3!!
I think you have pointed all the thing that was afraid of. Our code now is
near 500K coompiled. I'm sure it wi
1) I've got a SabreLite board (i.MX6) from Boundary
Devices.
2) I don't have the adapter for the fine pitch JTAG/SWD
header on the board. Furthermore, I'm not going to
pay the exorbitant price for the adapter board from
Boundary Devices. I'm also not willing to hack up an
This is an automated email from Gerrit.
Spencer Oliver (s...@spen-soft.co.uk) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/1199
-- gerrit
commit a9f80f4c9268a1d974682719ca4067d2332aedf0
Author: Spencer Oliver
Date: Wed Mar 6 14:07:02 2013 +
On Wed, Mar 6, 2013 at 9:24 PM, Øyvind Harboe wrote:
> We *do* have a fast-lane for *all* trivial patches. Anyone can go in and
> review the patch and find out if it is ready to go in and then vote for it
> to go in.
>
> You don't have to be a maintainer to review a patch.
>
> E.g. add a +1 and a
We *do* have a fast-lane for *all* trivial patches. Anyone can go in and
review the patch and find out if it is ready to go in and then vote for it
to go in.
You don't have to be a maintainer to review a patch.
E.g. add a +1 and a comment: "this patch is trivial, it can't possibly
cause any colla
On 6 March 2013 14:08, Xiaofan Chen wrote:
> On Wed, Mar 6, 2013 at 9:24 PM, Øyvind Harboe wrote:
>> We *do* have a fast-lane for *all* trivial patches. Anyone can go in and
>> review the patch and find out if it is ready to go in and then vote for it
>> to go in.
>>
>> You don't have to be a mai
Xiaofan Chen wrote:
> >> You will probably have infrequent release like every two years or
> >> every 10 years...
> >
> > I already wrote that I tend to prefer feature based releases, so
> > it's odd that you suggest that I prefer time based releases.
>
> No actually I do not think you even prefer
Xiaofan Chen wrote:
> > We *do* have a fast-lane for *all* trivial patches. Anyone can go in and
> > review the patch and find out if it is ready to go in and then vote for it
> > to go in.
> >
> > You don't have to be a maintainer to review a patch.
> >
> > E.g. add a +1 and a comment: "this patch
W dniu 2013-03-06 09:10, John pisze:
> I would like to express surprise at the sudden announcement of a new
> release and the short time stated. Not meant as a vote for or against,
> just to register how astonishing it was.
Well, first announcement has to be a surprise - there's no roadmap of
fu
Freddie Chopin wrote:
> Well, first announcement has to be a surprise - there's no roadmap of
> future releases.
No need for surprise if doing time based releases from master. That
just needs a cronjob.
//Peter
--
Syma
On Wed, Mar 6, 2013 at 11:58 PM, Peter Stuge wrote:
> I generally prefer feature based releases over time based releases.
Nothing wrong with that actually. I mentioned in my previous
reply that a few conditions for a release.
1) Major feature
2) Major bug fixes or regression
3) If not (1) and (2)
On Thu, Mar 7, 2013 at 12:13 AM, Peter Stuge wrote:
> Xiaofan Chen wrote:
> Don't confuse review with testing. They are completely different things.
>
> Review is static analysis - studying a change, understanding what it
> does and why, and how that affects any surrounding code.
>
> Testing is dy
Xiaofan Chen wrote:
> > Review is static analysis - studying a change, understanding what it
> > does and why, and how that affects any surrounding code.
> >
> > Testing is dynamic analysis - observing the results of a change,
> > usually either trying to confirm progressions or detect regressions.
Hi,
Am 28.02.2013 21:17, schrieb Jonathan Dumaresq:
> Hi all,
>
> I try to find a problem in our code. And I wonder if I can use a sort of
> dynamic watchpoint.
>
> Like __asm("BKPT #0\n").
>
> Is there an opcode that I can use to set and remove a watchpoint on a
> cortex-M4 ?
I might have mis
On Wed, Mar 6, 2013 at 10:40 PM, Spencer Oliver wrote:
> On 6 March 2013 14:08, Xiaofan Chen wrote:
>> What I am talking about is not about trivial patches, for trival patches,
>> it seems to me usually they are actually being picked quite fast.
>> I am talking about those patches which are rathe
On Mon, Mar 4, 2013 at 2:12 PM, Woody Wu wrote:
> So I think what I had is a double problem: an unexpected reset and a
> failed intended reset.
>
> Really hope someone can help me.
Just wondering if you are using the latest openocd.git? You may
want to try it out to see if that helps.
As for the
31 matches
Mail list logo
