No need to indirect from registered integers to pointers.
Just stash the pointers directly in the register struct,
and don't even bother registering.
This is a small code shrink, speeds register access just
a smidgeon, and gets rid of another rude exit() path.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Don't include it in more headers than necessary; just
use it in the few files that actually need it.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Same deal: "register.h" got needlessly included all over the
place because of being in a few widely included headers.
So take it out of the header files which included it, and put
it in files which use it ... reduce needless interdependencies.
Also, don't need that extra "types.h" inclusion.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
We have too many different registers, and too many version and
context dependent interpretations, for this type of bitfield
management to be scalable.
(Anyone who really wants bitfield interpretation *can* do that
in Tcl code...)
There are ... quite a few copies of the same ARM dummy registers.
There should eventually be one copy; this many is craziness.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Now that nothing uses the old ETM handle any more, remove it.
Add minimal header tweaks, letting non-ARM7 and non-ARM9 cores
access ETM facilities.
Now ARM11 could support standard ETM (and ETB) access as soon as
it derives from "struct arm" ... its scanchain 6 is used access
the ETM, just like ARM7 and ARM9.
The Cortex parts (both M3 and A8) will need modified access methods
(via ETM init parameters), so they use the DAP. Our first A8 target
(OMAP3) needs that for both ETM and ETB, but the M3 ETM isn't very
useful without SWO trace support (it's painfully stripped down), so
that support won't be worth adding for a while.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Make both useful ETM port drivers (etb, etm_dummy) use the new
toplevel ETM handle, instead of the to-be-removed lower level one.
Do the same for the "oocd-trace" prototype too; and fix its
error reporting paths: return failure codes, don't exit(), etc
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
- ETB
* report _actual_ hardware status, not just expected status
* add a missing diagnostic on a potential ETB setup error
* prefix any diagnostics with "ETB"
- ETM
* make "etm status" show ETM hardware status too, instead of
just traceport status (which previously was fake, sigh)
- Docs
* flesh out "etm tracemode" docs a bit
* clarify "etm status" ... previously it was traceport status
* explain "etm trigger_percent" as a *traceport* option
ETM+ETB tracing still isn't behaving, but now I can see that part of
the reason is that the ETB turns itself off almost immediately after
being enabled, and before collecting any data.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2790 b42882b7-edfa-0310-969c-e2dbd0fdcd60
this fn has something to do with the queue, which it does not as such.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2050 b42882b7-edfa-0310-969c-e2dbd0fdcd60