On Wednesday 23 September 2009, David Brownell wrote:
> foreach t $targets {
> $t invoke-event reset-assert-pre
> + }
> + foreach t $targets {
> # C code needs to know if we expect to 'halt'
> if {[jtag tapisenabled [$t cget -chain-position]]} {
> $t arp_reset assert $halt
Where "arp_reset assert ..." maps to a target "assert_reset" method,
which in turn basically does (a) setup for "halt", likely using a
vector_catch mechanism on ARM, then (b) trigger SRST.
Problem: boards without SRST support. BeagleBoard being one
very accessible example of that ... but also anything else using
the TI-14 pin JTAG adapter, which doesn't pass SRST. Or in fact,
any board accessed using just the minimal 4 JTAG signals. And,
hey, this DM365 board I've got where the SRST signal from the
ARM-20 pin JTAG adapter goes into a CPLD, which ignores it when
figuring whether to reset the CPU (sigh). And ... surely more.
Those boards support various other ways to trigger resets over
JTAG links, including:
- Systems using TI chips include some reset mechanisms that
rely on docs that are not generally available:
* ICEpick operations (JTAG router)
* ICEcrusher operations (ARM-side debug logic).
- Forcing a watchdog reset (which is FWIW what Linux does
on OMAP and DaVinci chips) ... it's likely that almost
any SoC can achieve this.
In short, an arbitrary number of semi-custom JTAG sequences
are needed to support target resets without using SRST.
Proposed solution:
- Split the assert_reset() method in two, (a) for setup
and (b) for SRST (as above).
- Only call the (b) part for targets that don't provide
a new TBD event handler; use that handler instead of
(b) whenever it's provided.
And that TBD handler would, at least on the boards I've
seen with these problems, force a watchdog reset. Some
boards could probably use a default handler which just
invokes "jtag_reset 0 1" ...
Similarly for the deassert_reset() side of things.
Comments?
- Dave
> }
> + }
> + foreach t $targets {
> $t invoke-event reset-assert-post
> }
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
