On Wednesday 30 September 2009, Magnus Lundin wrote:
> David Brownell wrote:
> > I think that's not quite following the model which the code in
> > the src/helper/startup.tcl file is expecting ... a closer match
> > would use reset-assert-pre (or maybe "post") not reset-start.
>
> I have done some more testing and trying to understand the reset
> handling in OpenOCD.
> This is my understanding of the sequence
> -------------
> reset-start
>
> jtag-reset
> Here the omap3.dap tap is marked as disabled
Right, though note that more generally that "JTAG reset"
isn't just TRST ... it's also got an annoying SRST.
And in fact the command is "jtag arp_init-reset".
Because the DAP is disabled (and thus the Cortex-A8
target is disabled), this then skips an "arp_examine"
step; harmless here, it's already been done.
> reset-assert-pre
>
> target reset assert
> This is only called if the tap is enabled
> For CortexA8 we want to set target state to reset and invalidate all
> cached registers
That's "$target arp_reset assert $halt" to be accurate;
and as you note, it's not called here.
My previous proposal here is twofold"
1 - First, to make sure the TAP will have been
enabled! Add a new "post-verify" method to
kick in after the scan chain verification,
which can "jtag tapenable $TAPNAME".
2 - Then second, to call out to an optional Tcl
event method instead of relying on arp_reset
being able to kick in SRST. For OMAP3 it
could write PRM_RSTCTRL; on DaVinci boards
it might force a watchdog reset, assuming
no better docs appear. And boards with SRST
would of course want to use that...
But there are two things that also need to be teased
out. One is the register cache, as you note. The
other is setting whatever hardware debug hooks are
needed to ensure that the $halt hapens if needed.
On ARM9, or Cortex-M3, the $halt hooks are just setting
the right bit in the vector_catch register ... so
once the reset triggers, the CPU immediately enters
a debug state. I'd have to look in more detail, but
I think that the Cortex-A8 should be just as nice as
ARM9 or CM3 cips. :)
> reset assert post
>
> reset-deassert-pre
>
> target reset deassert
> This is only called if the tap is enabled
> For CortexA8 we want to halt the target for reset halt, this needs
> the tap to be enabled
Actually it's more of a bug-catchment to do anything with
halts here. "Normally" it was set up before chip reset.
However ISTR some chips do have bugs that need tending here.
> reset deassert post
You skipped two optional steps here:
- polling to make sure the CPU really halted, when
the halt was required.
- running the reset-init scripts ... for OMAP you can get
some examples by seeing what the GEL files from CCS do,
which pretty much matches X-Loader
> reset end
> ------------------
> My interpretation is:
>
> We must write the reset command to PRM_RSTCTRL before the jtag reset stuff.
> Otherwise the tap will be marked as disabled, even if is still
> enabled, since the reset has not yet happened, and the mww is impossible.
See my comments above about the twofold proposal. Given
the first (easier!) bit, PRM_RSTCTRL can be written in a
reset-assert-pre event handler (as a short term workaround).
> ( It actually kills OpenOCD with
> openocd: driver.c:243: interface_jtag_add_dr_scan: Assertion `field ==
> out_fields + scan->num_fields' failed. )
>
> The omap3_debugint must be called after the jtag reset stuff and before
> target reset assert
> Otherwise the CortexA8 reset assert will not be called since the tap is
> disabled
The dbginit stuff mixes several things though. One is just
enabling the TAP. The rest seems to be needed in two places:
(a) after each reset/SRST, since that clears the relevant
state; and (b) on OpenOCD startup.
> This gives the following reset event configurationb:
> omap3.cpu configure -event reset-start "omap3.cpu mww $PRM_RSTCTRL 2"
> omap3.cpu configure -event reset-assert-pre "omap3_dbginit"
Just as short term workarounds IMO. See above. Note also
that the PRM_RSTCTRL stuff isn't needd on boards which have
SRST accessible ... and the dbginit stuff really does mix
two things.
I think my best code contributions here will be to make sure
there's a good *JTAG* level event which can safely be used
to call "jtag tapenable omap3.dap". That calls for a bit of
re-shuffling and simplifying of the scan chain verification
code, which I've started.
- Dave
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
