Several of the sites now using target_type_name() really
ought to be using an instance-specific name. Create a
function called target_name(), accessing the instance's
own (command) name.
Use it in several places that really should be displaying
instance-specific names. Also in several places which
were already doing so, but which had no wrapper to call.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
There are two names that may matter on a per-target basis.
One is a per-instance name (for example, "at91sam7s.cpu").
The other is the name of its type (for example, "arm7tdmi"),
which is shared among multiple targets.
Currently target_get_name() returns the type name, which is
misleading and is rarely appropriate for target diagnostics.
Rename that as target_type_name().
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The container_of macro is useful as a general solution. It belongs
in types.h, rather than target.h where it was introduced. Requires
the offsetof macro, which comes from <stddef.h> (moved as well).
Lots of files still include it, often through needless
duplicate inclusion of "log.h"; sigh.
This cleans up the inclusion graph a bunch, so there are
fewer inclusion paths, but it doesn't change much otherwise.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Most files in the tree seem to have ended up including this,
and *quite* needlessly ... only code implementing or using
downloadable algorithms actually needs these declarations.
So take it out of the header files which included it, and put
it in files which use it ... reduce needless interdependencies.
Also: "algorithm.h" doesn't need to include "types.h" again;
it already comes from a different header.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Most files in the tree seem to have ended up including this,
and *quite* needlessly ... only code implementing or using
breakpoints actually needs these declarations.
So take it out of the header files which included it, and put
it in files which use it ... reduce needless interdependencies.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Previously this flag was stored in "target_type", so that for example
if there were two ARM7TDMI targets in a scan chain, both would claim
to have been examined although only the first one actually had its
examine() method called.
Move this state to where it should have been in the first place, and
hide a method that didn't need exposure ... the flag is write-once.
Provide some doxygen. The examine() method is confusing, since it
isn't separating one-time setup from the after-each-reset stuff. And
the ARM7/ARM9 version is, somewhat undesirably, not leaving the debug
state alone after reset ... probably more of an issue for trace setup
than for watchpoints and breakpoints.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Provide a cleaner way to handle single inheritance of targets
in C, using the same model Linux does: structs containing other
structs, un-nested via calls to a "container_of()" macro that
are packaged in typesafe inline functions.
Targets already use this containment idiom, but make it much
more complicated because they un-nest using embedded "void *"
pointers ... in chains of up to five per target, which is all
pure needless complication. (Example: arm92x core, arm9tdmi,
arm7_9, armv4_5 ... on top of the base "target" class.)
Applying this scheme consistently simplifies things, and gets
rid of many error-prone untyped pointers. It won't change any
part of the type model though -- it just simplifies things.
(And facilitates more cleanup later on.)
Rule of thumb: where there's an X->arch_info void* pointer,
access to that pointer can and should be removed. It may be
convenient to set up pointers to some of the embedded structs;
and shrink their current "*_common" names (annoyingly long).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Fixed bug: if virtual address for working memory was not specified
and MMU was enabled, then address 0 would be used.
Require working address to be specified for both MMU enabled
and disabled case.
For some completely inexplicable reason this fixes the regression
in svn 2646 for flash write in arm926ejs target. The logs showed
that MMU was disabled in the case below:
https://lists.berlios.de/pipermail/openocd-development/2009-November/011882.html
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
- Move definition of 'struct target_type_s' into new 'target_type.h' file.
- Forward delclaration remains in target.h, with comment pointing to new file.
- Replaces #define with #include in source files.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1971 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Add DEFINE_TARGET_TYPE_S symbol in files that need it defined.
- Forward declare 'struct target_type_s' only, unless that symbol is defined.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1969 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replaces all calls to target->type->{add,remove}_{break,watch}point.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1967 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replaces all accesses to target->type->name.
- add documentation in target_s to warn not to access field directly.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1966 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replaces all calls to target->type->get_gdb_reg_list.
- add documentation in target_s to warn not to invoke callback directly.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1964 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replaces all calls to target->type->bulk_write_memory.
- add documentation in target_s to warn not to invoke callback directly.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1963 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- replace all checks of target->type->examined with target_was_examined().
- replace all setting of target->type->examined with target_set_examined().
- replace clearing of target->type->examined with target_reset_examined().
- add documentation in target_s to warn not to access field directly.
git-svn-id: svn://svn.berlios.de/openocd/trunk@1962 b42882b7-edfa-0310-969c-e2dbd0fdcd60
