Zachary T Welch [Wed, 11 Nov 2009 09:31:34 +0000 (01:31 -0800)]
add documention for writing built-in commands
This documentation update provides an introduction to the command
handling facilities provided by command.[ch]. A primer walks the user
through the elements of a pointedly pedantic module: src/hello.c.
A summary of the API is provided in the OpenOCD Architecture section.
Zachary T Welch [Wed, 11 Nov 2009 09:20:49 +0000 (01:20 -0800)]
add src/hello.c to augment new command tutorial
The hello module provides the 'hello' command, printing a greetings
to the command console. It can grow to serve as pedagogical example
of services that OpenOCD developers should use: a runnable style guide.
Zachary T Welch [Tue, 10 Nov 2009 08:02:18 +0000 (00:02 -0800)]
command_handler_t: make argc unsigned
The number of command arguments will always be 0 or more, so use
the right type in handlers. This has a cascading effect up through
the layers, but the new COMMAND_HANDLER macros prevented total chaos.
Zachary T Welch [Wed, 11 Nov 2009 06:23:07 +0000 (22:23 -0800)]
use CALL_COMMAND_HANDLER instead of direct calls
By using CALL_COMMAND_HANDLER, parameters can be reordered, added, or
even removed in inherited signatures, without requiring revisiting
all of the various call sites.
Zachary T Welch [Tue, 10 Nov 2009 09:39:30 +0000 (01:39 -0800)]
add FLASH_BANK_COMMAND_HANDLER macro
The FLASH_BANK_COMMAND_HANDLER provides an extended command handler
using the __COMMAND_HANDLER macro, whereby changing that macro is
sufficient to update flash handlers with the new signature. It also
enforces uniform style and scope when implementing this handler.
Zachary T Welch [Wed, 11 Nov 2009 03:00:01 +0000 (19:00 -0800)]
add command_handler_t type
This patch adds new typedefs for command handler callback functions.
Users of this type signature were updated to use these new types.
It uses the new __COMMAND_HANDLER macro to prevent duplication.
Zachary T Welch [Wed, 11 Nov 2009 02:51:32 +0000 (18:51 -0800)]
add COMMAND_HANDLER and COMMAND_HELPER macros
The COMMAND_HANDLER and COMMAND_HELPER macros allow commands to be
defined in a manner that decouples them from the exact order and type of
their parameters. Once converted, incremental changes to the command
handler type can be addressed in incremental patches that do not need to
touch the entire tree.
These macros' implementation, __COMMAND_HANDLER, is used to define the
new command_handler_t type, and additional patches will use it to derive
new macros to define extended command types (e.g. flash, nand, pld).
The CALL_COMMAND_HANDLER provides a means of calling helpers or nested
handlers from withing a command handler.
This patch uses C99 varadic macro expansion. Please report compilers
that cannot handle this code.
Zachary T Welch [Fri, 13 Nov 2009 05:19:41 +0000 (21:19 -0800)]
nand: rename device to nand
To be more informative (and consistent with flash and pld trees), change
'device' parameter name to 'nand' in NAND source files. This change
eliminates confusing 'device->device->' instance from the code, and
it simplifies the forthcoming command handler patches.
David Brownell [Fri, 13 Nov 2009 04:24:41 +0000 (20:24 -0800)]
ETM: start support for ETMv2+
ARM11 and newer cores include updated ETM modules. Recognize
their version codes and some key config differences. Sanity
checked on an OMAP2, with an ETM11RV r0p1 (ETMv3.1).
This still handles only scan chain 6, with at most 128 registers.
Newer cores (mostly, Cortex) will need to use the DAP instead.
Note that the newer ETM modules don't quite fit the quirky config
model of the older ones ... having more port widths is easy, but
the modes aren't the same. That still needs to change.
Fix a curious bug ... how did the register cache NOT get saved??
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Jonas Horberg [Thu, 12 Nov 2009 20:39:37 +0000 (12:39 -0800)]
parport: add support for the jtag_khz command.
Add the khz and speed_div functions to the parport interface driver.
Add the parport_toggling_time function that tells the parport driver
how long (in nanoseconds) it takes for the hardware to toggle TCK.
[dbrownell@users.sourceforge.net: tweak doc for clarity, mention
multimeter, and whitespace fixes]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
David Brownell [Thu, 12 Nov 2009 05:57:44 +0000 (21:57 -0800)]
ETM: remove old mid-level ETM handle
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>
David Brownell [Thu, 12 Nov 2009 05:55:19 +0000 (21:55 -0800)]
ETM: use new toplevel ETM handle
Make ETM itself use the new toplevel ETM handle, instead
of the to-be-removed lower level one. As of this patch,
nothing should be using the old ARM7/ARM9-specific handle.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
David Brownell [Thu, 12 Nov 2009 05:49:14 +0000 (21:49 -0800)]
ARM: start generalized base type
Rename "struct armv4_5_common_s" as "struct arm". It needs
a bit more work to be properly generic, and to move out of
this header, but it's the best start we have on that today.
Add and initialize an optional ETM pointer, since that will
be the first thing that gets generalized.
The intent being: all ARMs should eventually derive from
this "struct arm", so they can reuse the current ETM logic.
(And later, more.) Currently the ARM cores that *don't* so
derive are only ARMv7-M (and thus Cortex-M3) and ARM11.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Zachary T Welch [Wed, 11 Nov 2009 17:40:28 +0000 (09:40 -0800)]
add help regardless of callback
Add help for commands regardless of whether a handler is involved.
With this, all sorts of new commands can be found in 'help' text.
Hopefully, all of them have been documented....
Sadly, the lsort function appears to handle nested lists poorly, such
that sub-commands do not group with their parents.
Zachary T Welch [Wed, 11 Nov 2009 13:26:17 +0000 (05:26 -0800)]
add command_name helper
The command_name function returns a malloced string for a given
command and its parents. This can be used to display a message
to the user, but it is used internally to handle registration
and syntax errors. This helps permit arbitrary command nesting.
Zachary T Welch [Tue, 10 Nov 2009 12:27:15 +0000 (04:27 -0800)]
add const keyword to some APIs
Add 'const' keyword to 'char *' parameters to allow command handlers to
pass constant string arguments. These changes allow the 'args' command
handler to be changed to 'const' in a subsequent patch.
Zachary T Welch [Tue, 10 Nov 2009 10:43:11 +0000 (02:43 -0800)]
change argv to args in command handlers
Subsequent patches expect all command handlers to use a uniform
parameter naming scheme. In the entire tree, these two files used
standard 'argv' instead of our non-standard 'args'. This patch opts
to reduces the noise required to unify the command handlers, using
dominant 'args' form.
A future patch may be used to convert us back to the standard argv, but
that requires coordination with all developers to minimize disruptions.
Zachary T Welch [Tue, 10 Nov 2009 12:27:02 +0000 (04:27 -0800)]
makefiles: improve build order
Separates various groups of files to be built in logical succession.
In each layer, the core module (target.c, nand.c, etc.) is built _after_
their helper modules (e.g. image.c, nand_ecc.c) but _before_ any of
their drivers (e.g. arm966e.c, mx3_nand.c).
This allows problems introduced at the bottom of the stack to result
in build failures as soon as possible, as the helpers and core should
wrap portions of them.
David Brownell [Wed, 11 Nov 2009 12:42:50 +0000 (04:42 -0800)]
ETM cleanup
Various cleanups of ETM related code.
- Saner error return paths
- Simplify arm7_9 init ... no need for extra zeroing!
- Shrink some lines
- Tweak some diagnostics
- Use shorter name for ETM struct type.
- Don't exit()
and similar. The diagnostics look forward to having
this ETM code work with more than just ARM7/ARM9.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
David Brownell [Tue, 10 Nov 2009 19:58:31 +0000 (11:58 -0800)]
target: MMU-aware init for memory read/write
Start switching MMU handling over to a more sensible scheme.
Having an mmu() method enables MMU-aware behaviors. Not having
one kicks in simpler ones, with no distinction between virtual
and physical addresses.
Currently only a handful of targets have methods to read/write
physical memory: just arm720, arm920, and arm926. They should
all initialize OK now, but the arm*20 parts don't do the "extra"
stuff arm926 does (which should arguably be target-generic).
Also simplify how target_init() loops over all targets by making
it be a normal "for" loop, instead of scattering its three parts
to the four winds.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Thomas Kindler [Tue, 10 Nov 2009 17:16:12 +0000 (09:16 -0800)]
stm32.cfg: remove reset_config
Here's a patch for the double-reset problem on STM32. I've tested
downloading and debugging with GDB and Eclipse, and everything seems
to work fine.
This effectively sets reset_config to none. trst_only would also
be ok, but that's better left to a board configuration file since
not all boards wire it up.
The NVIC is used to trigger reset, which at least on this chip also
pulses nSRST so the whole system does get rest -- exactly once.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
David Brownell [Tue, 10 Nov 2009 10:01:20 +0000 (02:01 -0800)]
Target: minor cleanup
- improve some names -- a "default" prefix is not descriptive
- add doxygen @todo entries for some issues
- avr8 isn't ever going to need those MMU hooks
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Zachary T Welch [Tue, 10 Nov 2009 05:21:06 +0000 (21:21 -0800)]
jtag: remove useless declarations
Contrary to my previous assessment, some opportunities to remove forward
declarations were overlooked. Remove them by moving the definitions
of the command registration and interface structure to the end of files.
David Brownell [Mon, 9 Nov 2009 22:46:23 +0000 (14:46 -0800)]
Revert "target: add target->type->has_mmu fn"
This patch introduced a bug preventing flash writes from working
on Cortex-M3 targets like the STM32. Moreover, it's the wrong
approach for handling no-MMU targets.
The right way to handle no-MMU targets is to provide accessors
for physical addresses, and use them everywhere; and any code
which tries to work with virtual-to-physical mappings should use
a identity mapping (which can be defaulted).
And ... we can tell if a target has an MMU by seeing if it's
got an mmu() method. No such methood means no MMU.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
David Brownell [Mon, 9 Nov 2009 21:16:32 +0000 (13:16 -0800)]
finish removing deprecated/obsolete commands
It's been about a year since these were deprecated and, in most
cases, removed. There's no point in carrying that documentation,
or backwards compatibility for "jtag_device" and "jtag_speed",
around forever. (Or a few remnants of obsolete code...)
Removed a few obsolete uses of "jtag_speed":
- The Calao stuff hasn't worked since July 2008. (Those Atmel
targets need to work with a 32KHz core clock after reset until
board-specific init-reset code sets up the PLL and enables a
faster JTAg clock.)
- Parport speed controls don't actually work (tops out at about
1 MHz on typical HW).
- In general, speed controls need to live in board.cfg files (or
sometimes target.cfg files), not interface.cfg ...
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Zachary T Welch [Sun, 8 Nov 2009 07:20:33 +0000 (23:20 -0800)]
Overhaul time support API
This patch changes the duration_* API in several ways. First, it
updates the API to use better names. Second, string formatting has
been removed from the API (with its associated malloc). Finally, a
new function added to convert the time into seconds, which can be
used (or formatted) by the caller. This eliminates hidden calls to
malloc that require associated calls to free().
This patch also removes the useless extern keyword from prototypes,
and it eliminates the duration_t typedef (use 'struct duration').
These API also allows proper error checking, as it is possible for
gettimeofday to fail in certain circumstances.
The consumers have all been chased to use this new API as well, as
there were relatively few cases doing this type of measurement.
In most cases, the code performs additional checks for errors, but
the calling code looks much cleaner in every case.
David Brownell [Sun, 8 Nov 2009 20:44:28 +0000 (12:44 -0800)]
ARM: minor simulator cleanup
Make several functions be static. Shrink some of the overlong
lines. Use pure tab indents in some places that mixed in spaces.
This gives a minor object code shrink (about 2% on amd64).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
David Brownell [Sun, 8 Nov 2009 16:52:40 +0000 (08:52 -0800)]
target.cfg: remove "-work-area-virt 0"
The semantics of "-work-area-virt 0" (or phys) changed with
the patch to require specifying physical or virtrual work
area addresses. Specifying zero was previously a NOP. Now
it means that address zero is valid.
This patch addresses three related issues:
- MMU-less processors should never specify work-area-virt;
remove those specifications. Such processors include
ARM7TDMI, Cortex-M3, and ARM966.
- MMU-equipped processors *can* specify work-area-virt...
but zero won't be appropriate, except in mischievous
contexts (which hide null pointer exceptions).
Remove those specs from those processors too. If any of
those mappings is valid, someone will need to submit a
patch adding it ... along with a comment saying what OS
provides the mapping, and in which context. Example,
say "works with Linux 2.6.30+, in kernel mode". (Note
that ARM Linux doesn't map kernel memory to zero ...)
- Clarify docs on that "-virt" and other work area stuff.
Seems to me work-area-virt is quite problematic; not every
operating system provides such static mappings; if they do,
they're not in every MMU context...
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
David Brownell [Fri, 6 Nov 2009 22:57:21 +0000 (14:57 -0800)]
target: don't swap MMU/no-MMU work areas
Resolve serious bug inserted by the "target: require working
area for physical/virtual addresses to be specified" patch.
It forced use of (invalid) virtual addresses when the MMU
was disabled, and vice versa.
Observed to break at least Cortex-M3, ARM926, ARM7TDMI whenever
work areas are used, such as during bulk writes to flash, DDR2,
SRAM, and so on.
Also, fix overlong lines and whitespace goofs.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>