| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Change-Id: I8839f2cf0faf1b5ba9f99901c5ee028b199fabd2
Reviewed-on: http://openocd.zylin.com/35
Tested-by: jenkins
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
The Toshiba TMPA900 series (TMPA900/901) only has internal RAM regions
RAM-0 (16kB) and RAM-1 (8kB) which we can use as working area.
This is probably a copy-paste error from tmpa910.cfg, which has the
correct values and sizes for the TMPA910 series (TMPA910/911/912/913):
there are RAM-0, RAM-1, and RAM-2 (each 16kB).
Also, change "built-in RAM" to "internal RAM" to match what the
datasheet uses.
Change-Id: I993cd6b7fadc28cf34e5cc18426bb2bb42597670
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Reviewed-on: http://openocd.zylin.com/34
Tested-by: jenkins
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
|
|
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>
|
|
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>
|
|
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>
|
|
git-svn-id: svn://svn.berlios.de/openocd/trunk@2781 b42882b7-edfa-0310-969c-e2dbd0fdcd60
|
|
Toshiba TX09 familiy
git-svn-id: svn://svn.berlios.de/openocd/trunk@2756 b42882b7-edfa-0310-969c-e2dbd0fdcd60
|
