On Fri, Jul 17, 2009 at 1:29 PM, Qiang Wang wrote:
> I built the openocd with the newest version yesterday.
> It seem to be fine.I even use it to debug my board.
> I use the full version of cygwin.
>
Glad to hear that.
--
Xiaofan http://mcuee.blogspot.com
__
On Thu, Jul 16, 2009 at 9:57 PM, Leonard Heins wrote:
> I’ve just joined the list as I have been unsuccessful in building 0.2.0
> today. I accept that my question is not really a development one, but I
> don’t know where else to post right now. If this posting is offensive, I
> apologise in advance
On Thursday 16 July 2009, Zach Welch wrote:
> On Thu, 2009-07-16 at 13:48 -0700, David Brownell wrote:
> > On Thursday 16 July 2009, Spencer Oliver wrote:
> > >
> > > Infact looking at the new implementation it is broken.
> >
> > Hmmm, interesting.
> >
> > Of course, that's why I sent the patch
On Thu, 2009-07-16 at 13:48 -0700, David Brownell wrote:
> On Thursday 16 July 2009, Spencer Oliver wrote:
> >
> > Infact looking at the new implementation it is broken.
>
> Hmmm, interesting.
>
> Of course, that's why I sent the patch around first for testing
> and comments ... :)
Since we're
On Thursday 16 July 2009, Spencer Oliver wrote:
> Before i start diving in, has anyone attempted to use openocd cfi driver
> with a similar config:
> data nor flash (2x8MB total 16MB - one lower 16bit data, the other upper
> 16bit data) connected on a 32bit mcu data bus?
Partly similar (pair of 16
On Thursday 16 July 2009, Spencer Oliver wrote:
>
> Infact looking at the new implementation it is broken.
Hmmm, interesting.
Of course, that's why I sent the patch around first for testing
and comments ... :)
> I have just tried to change CONTROL[0] using reg 20 0x100, it fails.
> The ca
On Thu, 2009-07-16 at 15:39 -0300, Alain Mouette wrote:
> Zach Welch escreveu:
> >
> > Please repost to the list, so I can provide help for the community
> > rather than personal support for you. :) I have an answer ready.
>
> Done :)
>
> This was a stupid mistake. I sometimes do that because m
Sure, I have two boards setup this way. Both ARM926 core based. One has
two Spansion S29GL parts for a total of 128M NOR flash and another ARM926
based board with two Numonyx M29EW parts with a total of 64M flash.
Regards,
Brian
On Thu, Jul 16, 2009 at 3:11 PM, Spencer Oliver wrote:
> Hi,
>
>
Hi,
Before i start diving in, has anyone attempted to use openocd cfi driver
with a similar config:
data nor flash (2x8MB total 16MB - one lower 16bit data, the other upper
16bit data) connected on a 32bit mcu data bus?
Some changes will be needed, just wondering if anyone has attempted this.
It
On Thu, 2009-07-16 at 15:37 -0300, Alain Mouette wrote:
[snip]
> Could you explain which SVN version is the same as 0.2.0 ???
Is there something wrong with the archives that I posted ??? :)
> Reading SVN-history I was thinking that it should be 2519, because 2520
> is 0.2.1 ...
SVN is a little s
> >
> > The code is in cortex_m3.c.
> > The original code used 4 virtual regs to let the user see
> each special
> > register.
>
> I didn't see anything to morph the "real" register into four
> "virtual" ones though... the code was treating it as having
> for unique DCRSR identifiers, which i
Zach Welch escreveu:
>
> Please repost to the list, so I can provide help for the community
> rather than personal support for you. :) I have an answer ready.
Done :)
This was a stupid mistake. I sometimes do that because most list answer
automáticaly back to the list.
Is this taboo (it is f
Zach Welch escreveu:
> Actually, I think it hurts; it skips 0.2.0 in favor of SVN.
> An important point of regular releases is to get users off of the
> repository and using releases. Packagers are the first place that
> should start. Which patches did you really need, which were committed
> b
On Thursday 16 July 2009, Spencer Oliver wrote:
> > > Even though the early trm's still say this i queried arm and they
> > > confirmed that all revisions use this register 20. This is why I
> > > changed magnus's original code (using MRS/MSR) over a year ago.
> >
> > Did they tell you why the
> -Original Message-
> From: David Brownell [mailto:davi...@pacbell.net]
> Sent: 16 July 2009 17:29
> To: Spencer Oliver
> Cc: openocd-development@lists.berlios.de; zwe...@mail.berlios.de
> Subject: Re: [Openocd-development] [Openocd-svn] r2543 -
> trunk/src/target
>
> On Thursday 16
On Thursday 16 July 2009, Spencer Oliver wrote:
> A few comments as i have not had time to look over the original patch.
>
> > * Four of the registers are actually not exposed that way. Before
> >Cortex-M3 r2p0 they are read/written through MRS/MSR instructions.
> >In that ne
Hello All
I've just joined the list as I have been unsuccessful in building 0.2.0
today. I accept that my question is not really a development one, but I
don't know where else to post right now. If this posting is offensive, I
apologise in advance and will unsubscribe.
ANYWAY: I am using MS
On Thu, Jul 16, 2009 at 7:47 AM, Xiaofan Chen wrote:
>> Except for the last, these warnings probably come from using an older
>> version of Doxygen; I have 1.5.8 here. The warning about config.h is
>> confusing though; that file should exist, if you have the Makefile.
>> Perhaps it is created in t
A few comments as i have not had time to look over the original patch.
> * What the Core Debug facility exposes is
> *implementation-specific*
>not architectural. These values aren't fully
> portable. They match
>Cortex-M3 ... so no current implementation will make
> trou
19 matches
Mail list logo
