On Tuesday 07 July 2009, Øyvind Harboe wrote:
> > You must be *trying* to make it sound complex. There is
> > no "negotiation" involved at all. Or "overriding" either...
> >
> > (a) there are four control knobs to diddle, and
> > (b) changing one knob doesn't change *ANY* other knob.
>
> Only
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> > It's very rare that any chip config file needs to say anything
> > about resetting ... since most of the time it's a function of
> > board wiring.
>
> Except lots of these chips have srst_pulls_trst wired on
> the *inside* of the CPU part
In w
On Wed, Jul 8, 2009 at 12:12 AM, David Brownell wrote:
> On Tuesday 07 July 2009, Ųyvind Harboe wrote:
>> What I'm arguing is that "none" should be default
>
> It is. Though it's never meant what you seem to think it means.
I've tried to read up on the documentation and the
code of reset_config.
On Tue, 2009-07-07 at 15:01 -0700, David Brownell wrote:
> [ GRR "send" pressed itself somehow ]
>
> On Tuesday 07 July 2009, Zach Welch wrote:
> >
> > I would intuitively expect to be able to write:
> >
> > reset_config none srst_only srst_pulls_trst
> >
> > The key bit is the 'none', which
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> What I'm arguing is that "none" should be default
It is. Though it's never meant what you seem to think it means.
> and that any clever overriding & negotiation between board/target
> scripts should happen in tcl.
You must be *trying* to make it
To convince me of the value of the current implementation,
explain to me why this "negotiation" belongs in the
low level reset_config command and not in
some higher level tcl utility proc.
This "negotiation" is a mechanism that a target/board
config script should be able to use if it wants to.
My
[ GRR "send" pressed itself somehow ]
On Tuesday 07 July 2009, Zach Welch wrote:
>
> I would intuitively expect to be able to write:
>
> reset_config none srst_only srst_pulls_trst
>
> The key bit is the 'none', which blows it back to a cleared state.
No, that should be an error. The "what
On Tuesday 07 July 2009, Zach Welch wrote:
>
> I would intuitively expect to be able to write:
>
> reset_config none srst_only srst_pulls_trst
>
> The key bit is the 'none', which blows it back to a cleared state.
No, that should be an error. The "what signals" options
are (quoting the manua
On Tue, Jul 7, 2009 at 11:50 PM, David Brownell wrote:
> On Tuesday 07 July 2009, Ųyvind Harboe wrote:
>> > Is there some problem the current scheme has?
>>
>> Yes.
>
> Not according to what you say below ...
>
>
>> Lets say I have no idea what the default target script does,
>> but I know *precise
> AFAIK, it was designed to allow a target file to specify chip-level
> behavior and a board file to specify board-level behavior. Without the
> current functionality, there is no way to create such layered support.
This is wrong. Clearly you can implement the reset_config
board/target negotiatio
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> > Is there some problem the current scheme has?
>
> Yes.
Not according to what you say below ...
> Lets say I have no idea what the default target script does,
> but I know *precisely* what my board needs: srst_only
> srst_pulls_trst.
There's no
On Tue, 2009-07-07 at 23:39 +0200, Øyvind Harboe wrote:
> > I would intuitively expect to be able to write:
> >
> > reset_config none srst_only srst_pulls_trst
> >
> > The key bit is the 'none', which blows it back to a cleared state.
>
> What I'm arguing is that "none" should be default
> and th
> I would intuitively expect to be able to write:
>
> reset_config none srst_only srst_pulls_trst
>
> The key bit is the 'none', which blows it back to a cleared state.
What I'm arguing is that "none" should be default
and that any clever overriding & negotiation between board/target
scripts shou
On Tue, 2009-07-07 at 23:18 +0200, Øyvind Harboe wrote:
> >> How about modifying reset_config to simply *set* the
> >> state based *only* on the arguments to reset_config,
> >> ignoring the current reset_config state?
> >
> > That makes it impossible to combine constraints that come
> > from differ
>> How about modifying reset_config to simply *set* the
>> state based *only* on the arguments to reset_config,
>> ignoring the current reset_config state?
>
> That makes it impossible to combine constraints that come
> from different spots, so I don't like that notion.
That assumption is false. T
On Tuesday 07 July 2009, Øyvind Harboe wrote:
> reset_config currently manipulates the current state rather
> than just sets the state by some scheme which I'm not
> able to decipher immediately.
It's what's documented. There are several categories of
options, and what you pass changes *only* the
On Tue, 2009-07-07 at 17:42 +0200, Øyvind Harboe wrote:
> Here is a patch of suggested modification, no longer
> take current reset_config state into account.
Do not apply. This would directly regress work that was done by David
Brownell for 0.2.0. Specifically, look at r1944.
Zach
Hi Oyvind,
I tried your patch. Unfortunately for at least my particular situation it
didn't solve my problem. I did notice that the latest subversion has more
logging information, however. The error output shows a few more message
details then the version I was using earlier:
Info : J-Link JT
Here is a patch of suggested modification, no longer
take current reset_config state into account.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/tcl.c
==
reset_config currently manipulates the current state rather
than just sets the state by some scheme which I'm not
able to decipher immediately.
There isn't a way to *read* the current state.
How about modifying reset_config to simply *set* the
state based *only* on the arguments to reset_config,
20 matches
Mail list logo
