"David Brownell" napisał(a):
> I think Freddie's comment (that it does have
> something to do with it) made confusion, then.
Which comment?
> That would be explained by my trusting Freddie's
> comment to be accurate, i while it was instead
> ncorrect at the levels I was commenting on.
?
4\/3!
"David Brownell" napisał(a):
> Which ones are useless? Which are wrong? And
> for the latter , why haven't we seen specific bug reports, followed by
> trivial patches?
C'mon - we both know that everyone thinks srst_pulls_trst is mandatory for LPC
parts and my findings
https://lists.berlio
"Rolf Meeser" napisał(a):
> On 12/05/2010 11:00 PM, Freddie Chopin wrote:
> > So how about this idea of removing useless and wrong occurences of
> > srst_pulls_trst from lpc config files?
> >
> Are you sure this is correct?
>
> Copy protection of LPC controllers relies on the fact that i
On Mon, Dec 6, 2010 at 12:35 AM, Rolf Meeser wrote:
> On 12/05/2010 11:00 PM, Freddie Chopin wrote:
>> So how about this idea of removing useless and wrong occurences of
>> srst_pulls_trst from lpc config files?
>
> If your findings were correct, you would have discovered an easy way to
> circumve
--- On Sun, 12/5/10, Freddie Chopin wrote:
> So how about this idea of removing
> useless and wrong occurences of srst_pulls_trst from lpc config files?
Which ones are useless? Which are wrong? And
for the latter , why haven't we seen specific bug reports, followed by trivial
patches?
The
On Sun, Dec 5, 2010 at 10:38 PM, Steve Bennett wrote:
> tclsh is used during building. jimsh isn't used because of the
> chicken-and-egg problem.
>
> Actually, in the normal case it isn't even needed. You could
> replace 'tclsh' with 'echo' as a workaround if you don't want to
> install Tcl.
>
> I
On 12/05/2010 11:00 PM, Freddie Chopin wrote:
So how about this idea of removing useless and wrong occurences of
srst_pulls_trst from lpc config files?
Are you sure this is correct?
Copy protection of LPC controllers relies on the fact that it is not
possible to halt the processor right afte
So how about this idea of removing useless and wrong occurences of
srst_pulls_trst from lpc config files?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On 05/12/2010, at 11:36 PM, 1 0 wrote:
> Hello,
>
> I gotta problem with building GIT version of OpenOCD on my FreeBSD box
> - there is some error with JimTcl and tclsh (should come from
> jimtcl?):
>
> tclsh .././jimtcl/parse-unidata.tcl .././jimtcl/UnicodeData.txt
>> unicode_mapping.c
> tclsh:
> > --- On Sun, 12/5/10, Øyvind Harboe
> wrote:
> >
> >> Does anyone have any objections to
> >> getting rid of the
> >> concept of a default JTAG clock rate?
> >
> > NO. But let's see a proposed patch ... :)
>
> Could you clarify a bit what you are against?
I'll know it if I see it. :)
My co
More generally, if there is something that user must specify
that he hasn't and the script is working by chance, then it
would be great if we could robustly detect this situation and
require the user to specify that option.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll fr
On Sun, Dec 5, 2010 at 5:43 PM, David Brownell wrote:
>
>
> --- On Sun, 12/5/10, Øyvind Harboe wrote:
>
>> Does anyone have any objections to
>> getting rid of the
>> concept of a default JTAG clock rate?
>
> NO. But let's see a proposed patch ... :)
Could you clarify a bit what you are against
--- On Sun, 12/5/10, Øyvind Harboe wrote:
> Does anyone have any objections to
> getting rid of the
> concept of a default JTAG clock rate?
NO. But let's see a proposed patch ... :)
I recall some discussions a while back about
how JTAGKEY2 was broken because its driver was
embedding a defaul
On 12/05/2010 01:45 PM, Øyvind Harboe wrote:
> Does anyone have any objections to getting rid of the
> concept of a default JTAG clock rate?
>
> Basically, I'd like OpenOCD to refuse to start until the
> script defines the clock rate.
Sounds good to me.
cu
Michael
___
On 2010-12-05 14:46, Øyvind Harboe wrote:
Try with the currently committed stuff:
openocd -c "set CCLK 12345; source [find target/lpc2478.cfg]"
Well, it works, but I can't say that it's convenient to run OpenOCD this
way, when one "global CCLK" makes it easier. I prefer to do it "the
normal
Try with the currently committed stuff:
openocd -c "set CCLK 12345; source [find target/lpc2478.cfg]"
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG deb
Hello,
I gotta problem with building GIT version of OpenOCD on my FreeBSD box
- there is some error with JimTcl and tclsh (should come from
jimtcl?):
tclsh .././jimtcl/parse-unidata.tcl .././jimtcl/UnicodeData.txt
>unicode_mapping.c
tclsh: not found
Here is the full build output: http://pastebin
OK, now I have something that will probably reunite us all.
This patch allows OpenOCD to be run with this target script but define
CCLK via command line:
openocd -c "set CCLK 12345" -f target/lpc2478.cfg
It has only one downside, as I've noticed that OpenOCD prints the
value... The more funn
Does anyone have any objections to getting rid of the
concept of a default JTAG clock rate?
Basically, I'd like OpenOCD to refuse to start until the
script defines the clock rate.
The actual mechanism needs a bit of though, because it
is possible to set jtag clock rate in reset-start and in my
bo
On Sun, Dec 5, 2010 at 6:42 PM, Starkeeper wrote:
> Just to let you know, I still have the problem, that I can not program the
> external flash ;)
>
> I am wondering that most of the other non cfi flash drivers require the
> correct clock rate as parameter. How does the cfi driver computes the
> t
Merged.
I like the concept of mandatory instead of default values for
target scripts. A default value that works everywhere is great,
but it doesn't exist for this LPC chip.
I've actually been thinking about modifying OpenOCD to complain
if a board + target script does not define a JTAG clock fre
> I'm happy with the previous set of patches I submitted (nov 30),
> it's been working well for me for the past couple of weeks
> with no issues.
I had to make some fixes to make it compile.
Could you read over the patch now and write up a commit comment?
To create a patch, try:
git add .
git c
Paul Richards writes:
> Are there any plans to add support for the Marvell Armada processor
> family to Open OCD? (A hybrid of Feroceon and XScale processors from
> what I understand).
>
> I've had a little success customising scripts to communicate with an
> Armada PXA168 target via a FT4232 in
Just to let you know, I still have the problem, that I can not program the
external flash ;)
I am wondering that most of the other non cfi flash drivers require the
correct clock rate as parameter. How does the cfi driver computes the
timings without knowledge of the current clock?
-Ursprüng
Oh - another solution is creating a board file that defines all that is
necessary. Such board file could also define some default values of
reset_config, adapter_khz etc. I'm starting to like that idea (; The
only problem is the amount of new files that would be created this way...
4\/3!!
On 2010-12-05 10:13, Andrew Leech wrote:
On 05/12/2010, at 7:49 PM, Freddie Chopin wrote:
On 2010-12-04 19:29, Michael Schwingen wrote:
Just because the current files are hard-wired in a way that suits you
does not mean they work fine for everyone.
Have you considered opposite approach? Just
On 05/12/2010, at 7:49 PM, Freddie Chopin wrote:
> On 2010-12-04 19:29, Michael Schwingen wrote:
>> Just because the current files are hard-wired in a way that suits you
>> does not mean they work fine for everyone.
>
> Have you considered opposite approach? Just because the need of creating
>
On 2010-12-04 19:29, Michael Schwingen wrote:
Just because the current files are hard-wired in a way that suits you
does not mean they work fine for everyone.
Have you considered opposite approach? Just because the need of creating
another file suits you does not mean this is fine for everyone
28 matches
Mail list logo
