Menu
▾
▴
openocd-devel
|
From: Duane E. <op...@du...> - 2009-06-27 21:23:04
|
>> This avoids switching
>> programming paradigm from procedural to
>> event based, i.e. we could add events until
>> the cows go home and still miss that crucial
>> event for the next target.
>>
>
> I'd call the current reset "events" procedural
> hooks, myself. Heck, they don't even accept
> any parameters ... :)
>
The original idea/concept for the events was Tck/Tk "bind" - what i
wanted to do was add support for "%T" for target, and a host of other
things - much like Tk has "%w" for window name, and %x and %y for event
location - stuff like that. But never got around to it. Mostly because I
wanted the event stuff to 'gel' a little.
>> I don't believe that it is possible to *ever*
>> add a reset event that is flexible enough for
>> all future targets. I'm in favour of adapting OpenOCD
>> as we go along rather than create a hugely complicated
>> monster reset scheme that still won't catch the next
>> jtag router from hell problems.
>>
>
> Routers weren't the only, or even the main, set
> of motivating examples...
>
> But you seem to agree that the reset process
> still has holes that need fixing ("adapting");
> so that question is answered.
>
>
Why don't we re-describe the reset process completely.
ie: We define a few models - ie: (A), and (B) - and call those complete.
(That would handle probably 90% of the simple situations).
Then - allow the "reset" command to be 100% re-written, perhaps what we
need is:
proc reset { } {
jtag assert TRST SRST
jtag sleep-msecs 250
jtag de-assert TRST
jtag ... scan command
jtag .. scan command
jtag .. scan command
jtag de-assert SRST
}
This would *DE*COUPLE* the entire process.
We could then - add a few *TARGET* specific commands, ie:
$TARGET reset-action NAME ... parameters
For example - ARM7/9 - support to do "reset-halt", where you stop the
CPU @ the reset vector.
--
Today - the C code *controls* and *drives* the reset sequence.
I'm suggesting we turn that inside out - and make the TCL code - drive
the reset sequence - via commands above.
There would be a few *default* reset sequences - in tcl... that one
could point "proc reset" at.
-Duane.
|
|
From: David B. <da...@pa...> - 2009-06-27 22:35:07
|
On Saturday 27 June 2009, Duane Ellis wrote:
> Today - the C code *controls* and *drives* the reset sequence.
>
> I'm suggesting we turn that inside out - and make the TCL code - drive
> the reset sequence - via commands above.
That's a good direction, I think. Details TBD, but
certainly getting the current hard-coded SRST/TRST
reset policies from C into Tcl seems essential.
Tcl code would need to be able to query some of the
quirk flags -- srst pulling trst etc -- to figure out
how to diddle SRST and TRST in certain cases.
> There would be a few *default* reset sequences - in tcl... that one
> could point "proc reset" at.
I think I'd prefer to avoid that particular level of
need-to-rewrite. But maybe one having that handful of
standard models would remove the need for that, if the
models were sanely factored. (Initial design task:
come up with that factored handful of models.)
I'm not sure all the current events should be discarded,
for example, and the easiest way to preserve them would
involve less-than-wholesale replacement.
So for example, your:
> proc reset { } {
> jtag assert TRST SRST
> jtag sleep-msecs 250
To my taste, "msleep 250". ;)
> jtag de-assert TRST
I'd like to see some "jtag verify" options here,
so that part of the reset sequence is likewise
not hard-wired in C code.
So maybe "jtag verify from_trst [NBITS]" would
verify the IR length of NBITs total against the
declared TAPs, and then the DR values for TAPs
that have an IDCODE instruction. And, harder,
do something sensible when there's no match...
today everything just continues to bull through.
> jtag ... scan command
> jtag .. scan command
> jtag .. scan command
> jtag de-assert SRST
> }
That seems more like a component that should be plugged
into the reset sequence than a reset itself. (And it's
a good example of getting work done while SRST is
still asserted... something not all TAPS handle, but
some require.)
Doing a bit of brainstorming ... I think that should
be instead a "proc hard_reset", with those scans
packaged not unlike the current *target* event ops,
except done as *TAP* events. Each TAP might need
different setup too.
That way for example if you've got a system that has
no SRST and must instead issue resets through JTAG ops,
just hard_reset would get overridden.
And from the user interaction perspective, my initial
thought is that being able to customize behavior of
resets by permitting "reset hard", "reset soft", and
other operations ("reset fred", "reset usb", etc)
would seem a bit nicer than needing to define a bunch
of custom operations. But those models can be argued.
- Dave
|
|
From: Øyvind H. <oyv...@zy...> - 2009-06-28 20:27:45
|
(I saw Duane is following up on this one and he's pretty much the expert on it...) > If I've got an FPGA *not* programmed with a Nios core, > that model doesn't work. :) > > That issue isn't entirely "reset". It's "initialization", > which is a separable chunk of reset processing. For a > Nios core you could have "system reset" requiring both > "FPGA init" loading the core, and then "core reset". > But other FPGA bitstreams might not have a target. I'd like to be able to fire up a GDB debug session without having to worry about first configuring the FPGA. E.g. there might be default parameters set in the FPGA that resetting the Nios core does not reset, so I may very well want to reconfigure the FPGA upon each GDB session. On rewriting the reset routine: if we have 1000 targets that can be handled via parameters & events, then I'm OK with having one weird target rewrite the reset tcl proc. It's just an option available to targets that would unnecessarily complicate the more common targets. On adding options/events, then open source target support :-) is the ultimate configuration power/flexibility, we can add new options/events or change the default tcl reset proc as needed. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com |
|
From: Duane E. <op...@du...> - 2009-06-29 02:56:50
|
So - if we are to turn reset "inside-out" - what commands do we need?
1) ablity to control SRST & TRST externally.
jtag interface assert SIGNALNAME
jtag interface deassert SIGNALNAME
2) Ablity to know SRST & TRST configuration.
set foo [jtag interface cget -trst-srst-config ]
What is that list? Should this have some numeric (bit wise) value?
3) Do we want a "macro" player at that point - ie: something we can do
as a macro like thing?
Do we really want to code 'reset halt' for an ARM7 in tcl?
Or do we just want to say perform complex operation X, on tap Y *now*.
What are those "complex operations"?
By target....
That list is a non-trivial list of things.
-Duane.
|
|
From: David B. <da...@pa...> - 2009-06-29 08:24:52
|
On Sunday 28 June 2009, Øyvind Harboe wrote:
> How about if the target added new commands, such as
> "configure FPGA". This would then be distinct from resetting
> the CPU, but it could still be placed into the .gdbinit sequence.
Target? What target?
We shouldn't require *debug* support ("targets" list non-empty)
in order to use OpenOCD.
Sure, for GDB it's sort of inherent. But using GDB is optional.
So anything that's required only to make GDB happy shoould also
be optional...
- Dave
|
|
From: Øyvind H. <oyv...@zy...> - 2009-06-29 08:29:08
|
On Mon, Jun 29, 2009 at 8:24 AM, David Brownell<da...@pa...> wrote:
> On Sunday 28 June 2009, Ųyvind Harboe wrote:
>> How about if the target added new commands, such as
>> "configure FPGA". This would then be distinct from resetting
>> the CPU, but it could still be placed into the .gdbinit sequence.
>
> Target? What target?
I meant that the target configuration script added a tcl command
that would be available to the .gdbinit sequence(or from Telnet for
that matter).
I would like OpenOCD support for Altera Nios because ByteBlaster
performance sucks.
Another thing I'd like to see is the FPGA configure tool built more
naturally into the development cycle.
> We shouldn't require *debug* support ("targets" list non-empty)
> in order to use OpenOCD.
Agreed, I just explained badly in my last email and I'm not advocating
making GDB support required in any way.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
|
|
From: Øyvind H. <oyv...@zy...> - 2009-06-29 07:22:05
|
On pondering the configure FPGA vs. reset script problem. How about if the target added new commands, such as "configure FPGA". This would then be distinct from resetting the CPU, but it could still be placed into the .gdbinit sequence. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com |
|
From: Duane E. <op...@du...> - 2009-06-29 12:42:38
|
Øyvind Harboe wrote: > On pondering the configure FPGA vs. reset script > problem. > > How about if the target added new commands, such as > "configure FPGA". This would then be distinct from resetting > the CPU, but it could still be placed into the .gdbinit sequence. > > Why is this not "pay svf" file? -duane. |
|
From: Øyvind H. <oyv...@zy...> - 2009-06-29 13:38:19
|
On Mon, Jun 29, 2009 at 12:42 PM, Duane Ellis<op...@du...> wrote: > Ųyvind Harboe wrote: >> >> On pondering the configure FPGA vs. reset script >> problem. >> >> How about if the target added new commands, such as >> "configure FPGA". This would then be distinct from resetting >> the CPU, but it could still be placed into the .gdbinit sequence. >> >> > > Why is this not "pay svf" file? I guess it would be. Possibly with a few other operations thrown in. Perhaps power cycling ;-) The point is that the target configuration script would define a tcl proc that would use e.g. play svf file. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com |
|
From: David B. <da...@pa...> - 2009-06-29 19:21:24
|
On Monday 29 June 2009, Øyvind Harboe wrote: > The point is that the target configuration script would define > a tcl proc that would use e.g. play svf file. There's a missing hook too. No way for a non-target to invoke "svf file.name" or "xsvf tap.name file.name" during the reset process. |
|
From: Øyvind H. <oyv...@zy...> - 2009-06-29 19:27:49
|
On Mon, Jun 29, 2009 at 7:21 PM, David Brownell<da...@pa...> wrote: > On Monday 29 June 2009, Ųyvind Harboe wrote: >> The point is that the target configuration script would define >> a tcl proc that would use e.g. play svf file. > > There's a missing hook too. No way for a non-target to > invoke "svf file.name" or "xsvf tap.name file.name" during > the reset process. With an FPGA there is a step which brings the CPU into existence. Resetting the CPU is much like resetting any normal CPU. I'm not sure that configuring the FPGA(bringing the CPU into existence) should be done during the reset CPU tcl procedure.... -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com |
|
From: David B. <da...@pa...> - 2009-06-29 19:48:58
|
On Monday 29 June 2009, Øyvind Harboe wrote:
> On Mon, Jun 29, 2009 at 7:21 PM, David Brownell<da...@pa...> wrote:
> > On Monday 29 June 2009, Ųyvind Harboe wrote:
> >> The point is that the target configuration script would define
> >> a tcl proc that would use e.g. play svf file.
> >
> > There's a missing hook too. No way for a non-target to
> > invoke "svf file.name" or "xsvf tap.name file.name" during
> > the reset process.
>
> With an FPGA there is a step which brings the CPU into existence.
>
> Resetting the CPU is much like resetting any normal CPU.
... that's *IF* one task of that FPGA is implementing a CPU.
(And if it's not one of the FPGAs with on-chip storage for
that particular config bitstream.)
> I'm not sure that configuring the FPGA(bringing the CPU into existence)
> should be done during the reset CPU tcl procedure....
If it's implementing a CPU, then one of the post-reset event
handlers should _be able_ to handle that. Whether that's the
best place for it is another issue.
I happen to think the problems here would become a lot more
clear if one just took CPUs ("debug targets", the stuff that
GDB understands) out of the picture entirely and just looked
at what's missing from the JTAG facilities.
- Dave
|
|
From: Øyvind H. <oyv...@zy...> - 2009-06-29 20:26:56
|
> ... that's *IF* one task of that FPGA is implementing a CPU. > (And if it's not one of the FPGAs with on-chip storage for > that particular config bitstream.) Really what is required is a target .cfg file for *each* FPGA bit file, just like a .cfg file is required for each target. An FPGA screws with our concept of "target hardware" because with an FPGA it could be anything. The "reset" tcl proc really is *very* CPU oriented. It doesn't make much sense to talk about resetting an FPGA into the halted state.... -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com |
|
From: David B. <da...@pa...> - 2009-06-29 21:12:59
|
On Monday 29 June 2009, Øyvind Harboe wrote:
> The "reset" tcl proc really is *very* CPU oriented. It doesn't make
> much sense to talk about resetting an FPGA into the halted
> state....
Right, and that's a problem. As I noted earlier, there
need to be reset hooks that kick in at just the TAP layer.
In some cases, just to be able to issue
Without going into command structure, I think the
following tasks are necessary:
* After entering test-logic-reset but before leaving
that state to verify the scan chain using IR or DR
(and preventing all JTAG state transitions!):
- Issue N cycles of TCK ... for cases like ICEpick
or PXA255 where they're needed to wake up JTAG;
- Issue N pulses TMS with TCK held high ... for that
MSP430 case, forcing a fuse check
* After exiting test-logic-reset by verifying the
scan chain against the expected record:
- Arbitrary JTAG operations ... "svf file.name" to
load an FPGA, "jtag tapenable tapname" to make
sure a target's TAP is always enabled. (For now
I'd avoid the notion of automagic TAP enabling.)
* Before running a tap-enable handler:
- Arbitrary JTAG operations ... in particular,
enabling the ETB before enabling a TAP whose
ETM requires it
Seems to me all of those can be done with a few
new TAP events: "pre_verify", "post_verify" for
the first two (following the existing model for
target events), "pre_enable" for the latter.
And for that MSP430 thing, if it starts to matter,
a new lowlevel primitive would be needed.
- Dave
|
|
From: David B. <da...@pa...> - 2009-06-29 21:32:21
|
On Monday 29 June 2009, Øyvind Harboe wrote:
> Really what is required is a target .cfg file for *each* FPGA bit
> file, just like a .cfg file is required for each target.
You mean, to handle cases like the config bitstream
linking in more TAPs to the one provided by the FPGA
vendor?
Maybe. We have the model of enabling/disabling TAPs
already, via JRC. That model is a bit weak, in that
it doesn't understand more than one TAP being added
at a time ... and is very fragile, since the code has
no good way to validate the chain.
But basically something like
jtag newtap fpga.cpu0 ... -disable
jtag newtap fpga.cpu1 ... -disable
jtag newtap fpga.cpu2 ... -disable
...
jtag configure fpga.tap -event post-verify {
xsvf fpga.tap bitstream_file_0
jtag tapenable fpga.cpu0
jtag tapenable fpga.cpu1
...
}
should solve the technical problem. And it could be
made properly conditional, so that bitstream_file_1
and bitstream_file_1 enable different TAPs, and are
chosen based on the task at hand.
If someone wanted to package those into different
config files, that could work; but I wouldn't want to
require board files use that model for substructure.
- Dave
|
|
From: Øyvind H. <oyv...@zy...> - 2009-06-29 23:00:37
|
On Mon, Jun 29, 2009 at 9:32 PM, David Brownell<da...@pa...> wrote: > On Monday 29 June 2009, Ųyvind Harboe wrote: >> Really what is required is a target .cfg file for *each* FPGA bit >> file, just like a .cfg file is required for each target. > > You mean, to handle cases like the config bitstream > linking in more TAPs to the one provided by the FPGA > vendor? Even simpler than that: an FPGA could implement one or more CPUs. The only way to *know* what to write in a target configuration file is to embed some knowledge about the # of CPUs and how to set them up in the target configuration script. > should solve the technical problem. And it could be > made properly conditional, so that bitstream_file_1 > and bitstream_file_1 enable different TAPs, and are > chosen based on the task at hand. Note that a bitstream and the target configuration file will be unique to a single company or even developer, so I'm not a believer in a generic scheme to "discover" how to set up a target configuration script. Really each bitstream would be a different board+target configuration under the current OpenOCD thinking. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com |
|
From: David B. <da...@pa...> - 2009-06-29 23:22:00
|
On Monday 29 June 2009, Øyvind Harboe wrote: > I'm not a believer in a generic scheme to "discover" how > to set up a target configuration script. > > Really each bitstream would be a different board+target > configuration under the current OpenOCD thinking. Different board.cfg or user.cfg is what I was saying. By pointing out the conditional loading, I meant no more than the usual sort of project-specific setup that most developers need. "Load/run diagnostics" being very different from "load beta2 bits as the backup in case this beta4 fix still doesn't work". - Dave |
Thanks for helping keep SourceForge clean.
X