Re: [Openocd-development] Advanced Reset Process
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
On Mon, Jun 29, 2009 at 8:24 AM, David Brownelldavi...@pacbell.net 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
Ø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. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
On Mon, Jun 29, 2009 at 7:21 PM, David Brownelldavi...@pacbell.net 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
On Monday 29 June 2009, Øyvind Harboe wrote: On Mon, Jun 29, 2009 at 7:21 PM, David Brownelldavi...@pacbell.net 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
... 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
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
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
On Mon, Jun 29, 2009 at 9:32 PM, David Brownelldavi...@pacbell.net 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
(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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
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. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
Does it seem to you like the reset process is flexible enough yet? The idea is that those targets where the tcl reset proc doesn't cut it would implement their own tcl reset proc from scratch. That seems undesirable when some key improvements can be more generically available. Like for starters, either a TAP event on TLR entry or a settable parameter saying how many TCK cycles must be issued in TLR before issuing JTAG commands. What we have now is jtag_ntrst_delay milliseconds, without clocks going. jtag_ntrst_clocks would address documented ICEpick and PXA255 constraints. And there are no doubt other similar small tweaks. Note the scaing problem with needing target-specific rewrites of ocd_process_reset: it's impractical to combine two such targets on one board... 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 ... :) 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. I'm thinking .. no: - All those reset events go to debug targets ... but there's at least the ICEpick example, where a JRC needs 100+ TCK cycles after entering TLR, and it's easy to find others. Loading an FPGA, for one. Those aren't targets; so no events... I'm not even sure that the reset concept even applies to an FPGA. For Altera Nios I'd first like to program the FPGA, then reset the CPU. 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 was looking at DM355 documentation and it clearly distinguishes cold resets -- both TRST and SRST get cycled -- from warm ones -- SRST only. We don't seem to have a clean way to do warm today. soft_reset_halt? No, that's a different beast. It applies to the current target and doesn't involve SRST. One reason to want a warm reset is that it leaves all the debug/jtag stuff alone. Maybe you tweaked some settings so that some things become observable during the reset/reinit sequence. [I've deleted those items where I had no useful input at this time] And I suspect that if I looked around a bit, I'd find more such cases where the reset model isn't (yet!) advanced enough. Thoughts? A target/board config file can reimplement the reset proc from scratch. How far does that get you? As a user, way deeper into the undocumented innards of OpenOCD than I want to be. ;) As a developer, it's hard to say without doing it. My initial reaction is that the reset processes are not yet factored well enough to support everything that I've happened across. But experimenting with a few individual targets should help identify more of the holes. What I'd like to see is a kind of reset toolkit which would make that practical. But it's not really there yet. Reimplement ocd_process_reset is not a scalable approach. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
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.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
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
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
On Thu, Jun 25, 2009 at 12:06 AM, David Brownelldavi...@pacbell.net wrote: On Wednesday 24 June 2009, Duane Ellis wrote: So maybe you can answer this ... What does the arp_ prefix in various commands represent? Address Resolution Protocol was my first reaction ... but that doesn't seem relevant to JTAG. ;) That name arp_ was coined by my self an Oyvind last year when we where trying to introduce Reset events and all the other Jim type events. The ARP - stood for: Advanced Reset Process - On Wednesday 24 June 2009, Ųyvind Harboe wrote: The idea is to have a prefix to low level fn's that the higher level tcl reset proc uses. As such the choice of prefix is arbitrary. OK, first question answered. Thanks. Next ... Does it seem to you like the reset process is flexible enough yet? The idea is that those targets where the tcl reset proc doesn't cut it would implement their own tcl reset proc from scratch. 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 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. I'm thinking .. no: - All those reset events go to debug targets ... but there's at least the ICEpick example, where a JRC needs 100+ TCK cycles after entering TLR, and it's easy to find others. Loading an FPGA, for one. Those aren't targets; so no events... I'm not even sure that the reset concept even applies to an FPGA. For Altera Nios I'd first like to program the FPGA, then reset the CPU. - I was looking at DM355 documentation and it clearly distinguishes cold resets -- both TRST and SRST get cycled -- from warm ones -- SRST only. We don't seem to have a clean way to do warm today. soft_reset_halt? [I've deleted those items where I had no useful input at this time] And I suspect that if I looked around a bit, I'd find more such cases where the reset model isn't (yet!) advanced enough. Thoughts? A target/board config file can reimplement the reset proc from scratch. How far does that get you? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
