openocd-devel

[Openocd-development] Enable DCC memory by default or remove option entirely?

[Ø. H. <oyv...@zy...>]

I'd like to enable DCC memory downloads by default.

Perhaps this option should be retired entirely and always
be enabled?

This simplifies documentation in all that is required for decent
performance is working memory, which is in line with anyones
expectations after using other ARM JTAG debuggers.

Without working memory enabled, DCC memory downloads
are not used.

Any objections?


Index: C:/workspace/trunk/src/target/arm7_9_common.c
===================================================================
--- C:/workspace/trunk/src/target/arm7_9_common.c	(revision 600)
+++ C:/workspace/trunk/src/target/arm7_9_common.c	(working copy)
@@ -2625,7 +2625,7 @@
 	arm7_9->dcc_working_area = NULL;
 	
 	arm7_9->fast_memory_access = 0;
-	arm7_9->dcc_downloads = 0;
+	arm7_9->dcc_downloads = 1;

 	armv4_5->arch_info = arm7_9;
 	armv4_5->read_core_reg = arm7_9_read_core_reg;


-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

Re: [Openocd-development] Enable DCC memory by default or remove option entirely?

[Ø. H. <oyv...@zy...>]

Forgot arm7_9 fast_memory_access.

That would have to be enabled by default as well.



-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

Re: [Openocd-development] Enable DCC memory by default or remove optionentirely?

[Spen <sp...@sp...>]

> 
> I'd like to enable DCC memory downloads by default.
> 
> Perhaps this option should be retired entirely and always be enabled?
> 
> This simplifies documentation in all that is required for 
> decent performance is working memory, which is in line with 
> anyones expectations after using other ARM JTAG debuggers.
> 
> Without working memory enabled, DCC memory downloads are not used.
> 
> Any objections?
> 

fine with me, but i would want to keep the commands to disable this
behaviour if desired.

Cheers
Spen

Re: [Openocd-development] Enable DCC memory by default or remove optionentirely?

[Dominic R. <Dom...@gm...>]

We certainly can't remove these options, because memory writes might fail if the JTAG interface is too fast for a target's current core frequency. Atmel ARMs for example start up running from their slow oscillator (32.768kHz), and there it's easily possible that a JTAG interface is fast enough to outrun the target.

Both options turn on some optimization, and should only be enabled if it's guaranteed that the requirements are fulfilled.

Regards,

Dominic

-------- Original-Nachricht --------
> Datum: Mon, 21 Apr 2008 14:47:42 +0100
> Von: "Spen" <sp...@sp...>
> An: "\'Øyvind Harboe\'" <oyv...@zy...>, "\'Openocd-Dev\'" <ope...@li...>
> Betreff: Re: [Openocd-development] Enable DCC memory by default or remove	optionentirely?

> > 
> > I'd like to enable DCC memory downloads by default.
> > 
> > Perhaps this option should be retired entirely and always be enabled?
> > 
> > This simplifies documentation in all that is required for 
> > decent performance is working memory, which is in line with 
> > anyones expectations after using other ARM JTAG debuggers.
> > 
> > Without working memory enabled, DCC memory downloads are not used.
> > 
> > Any objections?
> > 
> 
> fine with me, but i would want to keep the commands to disable this
> behaviour if desired.
> 
> Cheers
> Spen
> 
> _______________________________________________
> Openocd-development mailing list
> Ope...@li...
> https://lists.berlios.de/mailman/listinfo/openocd-development

-- 
--
Dominic Rath <Dom...@gm...>

Re: [Openocd-development] Enable DCC memory by default or remove optionentirely?

[Ø. H. <oyv...@zy...>]

On Mon, Apr 21, 2008 at 3:49 PM, Dominic Rath <Dom...@gm...> wrote:
> We certainly can't remove these options, because memory writes might fail if the
> JTAG interface is too fast for a target's current core frequency. Atmel ARMs for
> example start up running from their slow oscillator (32.768kHz), and there
> it's easily possible that a JTAG interface is fast enough to outrun the target.

Does this apply to DCC as well?

Why is arm7_9 fast_memory_writes and dcc_downloads separate options?

If I changed the default, I'd want to add a small section troubleshooting
section of openocd.pdf.

>  Both options turn on some optimization, and should only be enabled
> if it's guaranteed that the requirements are fulfilled.

The problem is documentation, default behavior and how to minimize
the energy needed for users to get going with OpenOCD. I'm sure
they have other, more demanding and interesting problems, than
to tinker with OpenOCD configs :-)

The default options should be robust, yet at some point they
also need to give decent performance.

So, currently I'm thinking:

- make a single fast_memory_writes option. Does this need
to be arm7/9 specific?
- retire dcc memory downloads
- make fast_memory_writes = on default.
- add something in the troubleshooting section in openocd.pdf
to suggest disabling working memory &  fast_memory_Writes,
try different rest + post reset speeds, etc.


-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

Re: [Openocd-development] Enable DCC memory by default or remove optionentirely?

[Dominic R. <Dom...@gm...>]

On Monday 21 April 2008 17:10:36 Øyvind Harboe wrote:
> On Mon, Apr 21, 2008 at 3:49 PM, Dominic Rath <Dom...@gm...> wrote:
> > We certainly can't remove these options, because memory writes might fail
> > if the JTAG interface is too fast for a target's current core frequency.
> > Atmel ARMs for example start up running from their slow oscillator
> > (32.768kHz), and there it's easily possible that a JTAG interface is fast
> > enough to outrun the target.
>
> Does this apply to DCC as well?

Sure, there's no handshaking, which is why DCC and fast_memory_writes is 
faster. In theory there could be a DCC with handshaking, but that would be 
slower than the normal, handshaked memory write (4 byte vs. 14 x 4 byte per 
handshake).

> Why is arm7_9 fast_memory_writes and dcc_downloads separate options?

Because they're completely unrelated.

> If I changed the default, I'd want to add a small section troubleshooting
> section of openocd.pdf.

I don't think it's a good idea to change this default. Even if both options 
work in the majority of cases, this is something that could easily fail, 
because it relies on the JTAG interface being slow enough for the combination 
of target clock and target memory (e.g. more waitstates on external memory).

> >  Both options turn on some optimization, and should only be enabled
> > if it's guaranteed that the requirements are fulfilled.
>
> The problem is documentation, default behavior and how to minimize
> the energy needed for users to get going with OpenOCD. I'm sure
> they have other, more demanding and interesting problems, than
> to tinker with OpenOCD configs :-)

The OpenOCD works fine without those two options.

> The default options should be robust, yet at some point they
> also need to give decent performance.

Basically these two options are not just not robust, but technically wrong. 
They just happen to work, if used with care.

> So, currently I'm thinking:
>
> - make a single fast_memory_writes option. Does this need
> to be arm7/9 specific?

No idea about other targets. I remember a commit from you that made a 
separate "fast writes" (or was it reads?) access for XScales obsolete.

> - retire dcc memory downloads

We could get rid of the separate DCC option, but the code should then be 
changed to verify a working area is available, otherwise the log could be 
full of warnings.

I'm not sure if DCC downloads is completely free of side effects. For the 
target, DCC downloads are no different than normal execution, and therefor 
e.g. watchdogs that are disabled in halt mode could interfere with larger 
memory writes. If there's a chance of dcc downloads breaking anything we need 
to keep the option. The current fast_memory_writes option wouldn't be 
affected by this, hence we might need to keep them separate.

> - make fast_memory_writes = on default.
> - add something in the troubleshooting section in openocd.pdf
> to suggest disabling working memory &  fast_memory_Writes,
> try different rest + post reset speeds, etc.

No, please don't that, for all the reasons listed above.

Regards,

Dominic

Re: [Openocd-development] Enable DCC memory by default or remove optionentirely?

[Ø. H. <oyv...@zy...>]

Thanks for explaining the various options.

Looking at the target library, I believe that most of the targets
should use dcc memory downloads and fast_memory_writes.

By "should" I mean that turning on these two options will work
robustly on those targets.

Clearly if things could go faster without the user having to
read page up/down on how to make things go faster then that
would be a good thing.

If OpenOCD becomes unstable because of bad defaults, then
that's worse than a bit of performance degradation.

How about this approach:

- Add a new command line option to OpenOCD --fast 0/1.
This will turn on features that probably will work and will improve
performance if they do work. Probably a fast 0/1 command as
well.
- If the user has problems, he can omit the --faster option and
see if things work better.
- Leave the existing commands alone, except that they pick up
their default from --fast. Also, they will be listed as "subject to
change without notice" and that really the --fast 0/1 option
is normally the way to go.


A user would then follow this approach:

1. get the target script working without --fast option
2. try with --fast & maximum JTAG clk.
3. if --fast fails, he can either give up or tinker with
the individual options, tune down JTAG clk, etc.
4. debug_level would be orthogonal to --fast 0/1

This leaves a lot of room for maintainers of targets
to tinker with commands/options to eek out more
performance and retire those options if a more
robust and cleaner way is found.


-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit