Minor typos found by the new checkpatch boosted by the dictionary
provided by 'codespell'.
While there, fix one indentation.
Change-Id: I72369ed26f363bacd760b40b8c83dd95e89d28a4
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/6214
Tested-by: jenkins
Drop useless double-space occurences, drop trailing whitespace, and fix
some other minor whitespace-related issues.
Change-Id: I6b4c515492e2ee94dc25ef1fe4f51015a4bba8b5
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/137
Tested-by: jenkins
There are many "force an error till we get a good number" comments in
target/board files. This refers to the use-case where a config script
sets _CPUTAPID to 0xffffffff (which presumely gets overridden later):
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# Force an error until we get a good number.
set _CPUTAPID 0xffffffff
}
However, the same comment was also copy-pasted in many files which do
_not_ set _CPUTAPID to 0xffffffff, where the comment doesn't make any
sense at all. Drop those comments. Also, add one missing comment, and
fix small whitespace and grammar issues.
Change-Id: Ic4ba3b5ccba87ed40cea0d6a7d66609fbdfa3c71
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Reviewed-on: http://openocd.zylin.com/136
Tested-by: jenkins
Reviewed-by: Peter Stuge <peter@stuge.se>
End of line comments fixed with ';' before '#'.
Added few additional 'space' to keep indentation in
multi-line comments.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Globally rename "jtag_nsrst_delay" as "adapter_nsrst_delay", and move it
out of the "jtag" command group ... it needs to be used with non-JTAG
transports
Includes a migration aid (in jtag/startup.tcl) so that old user scripts
won't break. That aid should Sunset in about a year.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Globally rename "jtag_khz" as "adapter_khz", and move it out of the "jtag"
command group ... it needs to be used with non-JTAG transports
Includes a migration aid (in jtag/startup.tcl) so that old user scripts
won't break. That aid should Sunset in about a year. (We may want to
update it to include a nag message too.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Remove more remnants of the old "jtag_device" syntax.
Don't [format "%s.cpu" $_CHIPNAME] ... it's needless complexity.
Remove various non-supported "-variant" target options; they're not
needed often at all.
Flag some of the board files as needing to have and use target files
for the TAP and target declarations.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Rename the "armv4_5" command prefix to straight "arm" so it makes
more sense for newer cores. Add a simple compatibility script.
Make sure all the commands give the same "not an ARM" diagnostic
message (and fail properly) when called against non-ARM targets.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
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>