It might be possible to get this target going without
RCLK, but it would require more careful analysis and
usage of the reset events.
Enable fast memory accesses.
Tested on an at91sam9260 custom board w/external DRAM
and flash.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
While "flash bank" syntax has been changed long ago,
several tcl script are still not fully update.
Fix following cases related with "cfi" driver:
- syntax error: the mandatory <name> parameter is missing
- warning: the <target> parameter is a number, instead of
the target name
- the comment line above the command does not report
actual syntax
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Globally rename "jtag_nsrst_assert_width" as "adapter_nsrst_assert_width",
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_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>
The default config script will now dynamically setup the BMX registers
in the reset init script.
This will also work if the user overrides the default working area.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Add flash algorithm support for the PIC32MX.
Still a few things todo but this dramatically decreases
the programing time, eg. approx programming for 2.5k test file.
- without fastload: 60secs
- with fastload: 45secs
- with fastload and algorithm: 2secs.
Add new devices to supported list.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Fix some issues with the generic LPC1768 config file:
- Handle the post-reset clock config: 4 MHz internal RC, no PLL.
This affects flash and JTAG clocking.
- Remove JTAG adapter config; they don't all support trst_and_srst
- Remove the rest of the bogus "reset-init" event handler.
- Allow explicit CCLK configuration, instead of assuming 12 MHz;
some boards will use 100 Mhz (or the post-reset 4 MHz).
- Simplify: rely on defaults for endianness and IR-Capture value
- Update some comments too
Build on those fixes to make a trivial config for the IAR LPC1768
kickstart board (by Olimex) start working.
Also, add doxygen to the lpc2000 flash driver, primarily to note a
configuration problem with driver: it wrongly assumes the core clock
rate never changes. Configs that are safe for updating flash after
"reset halt" will thus often be unsafe later ... e.g. for LPC1768,
after switching to use PLL0 at 100 MHz.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The MC13224V is a FreeScale ARM7TDMI based IEEE802.15.4 platform for
Zigbee and similar low-power wireless applications. Using PIP
(Platform In Package) technology, it integrates: an RF balun and
matching network; a buck converter (only an external inductor is
necessary); 96KB of SRAM; and 128KB of non-volatile memory.
It has an integrated bootloader and can boot from a variety of sources:
external SPI or I2C non-volatile memory, an image loaded over UART1,
or the internal non-volatile memory. The image loaded from one of these
sources is executed directly from SRAM starting at location 0x00400000.
Open source development code at http://mc1322x.devl.org
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cortex-M targets don't support ARM instructions.
Leave the NVIC.VTOR setup alone, but comment how the whole
routine looks like one big bug...
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Moved board specific settings from target/at91r40008.cfg to a new
file board/ethernut3.cfg.
Set correct CPUTAPID. Reset delay increased, see MIC2775 data sheet.
Increased work area size from 16k to 128k.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
For STR7x flash, the device cannot be queried for the protect status.
The solution is to remove the protection on reset init. The driver
also initialises the sector protect field to unprotected.
[dbrownell@users.sourceforge.net: line length shrinkage]
Signed-off-by: Edgar Grimberg <edgar.grimberg@zylin.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The default state of the STR7 flash after a reset init is unlocked.
The information in the flash driver now reflects this.
The information about the lock status cannot be read from the
flash chip, so the user is informed that flash info might not
contain accurate information.
[dbrownell@users.sourceforge.net: line length shrinkage]
Signed-off-by: Edgar Grimberg <edgar.grimberg@zylin.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
openocd does not start with the target configfile due to the case in the
dependent config file.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
add reset-init script to allow ram execution from reset, this is required for ejtag fastdata access.
Signed-off-by: Spencer Oliver <ntfreak@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>
That syntax has been obsolete forever and is now gone; remove a few
remaining references. Shows how seldom this stuff gets used.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Common target.cfg file for LM3S CPU family
[dbrownell@users.sourceforge.net: rename, generalize more]
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Behave like OMAP3530: force global software reset. Given the
patch to teach ARM11 how to use these events, and use VCR to
catch the reset vector, this works better than either the
current reset logic or than using SRST.
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>
Kick in ETM (and ETB) support for ARM11. Tested on OMAP 2420,
so update that configuration. (That's an ARM1136ejs, ETB,
OpenGL ES1.1, C55x DSP, etc.)
Also update the other ARM11 ETM + ETB targets in the tree
to set up these modules. (Not tested.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Various cores with an ETB have its TAP misnamed ... either as a
boundary scan TAP or as the iMX "Secure JTAG Controller" (which
is, among other things, a JRC that could be used to shorten
scan chains).
Use the correct name for these TAPs, which we can recognize since
their IDs were assigned by ARM and these chips all document the
presence of an ETB. The 0x2b900f0f is ETB11; the 0x1b900f0f
is an older module, just called "ETB".
Also shrink the ETB's IR configuration; the default IR-Capture
value is fine, and the mask can specify that all four bits are
safe to check (per ARM documentation).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
General rule, this is all board-specific and doesn't belong
in target config files. Some of these were just cosmetic.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
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>
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>
Gets rid of the runtime warning "stm32.bs: nonstandard IR mask"
[dbrownell@users.sourceforge.net: line lengths, note issue, section ref]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This gets rid of runtime warnings from the use of numbers.
STM32 and LPC2103 were tested. Other LPC updates are the
same, and so are safe. The CFI updates match other tested
changes now in the tree.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Now I can issue "reset halt" and have everything act smoothly;
the vector_catch hardware is obviously not kicking in, but the
rest of the reset sequence acts sanely.
- TAP "setup" event enables the DAP, not omap3_dbginit
(resolving a chicken/egg bug I noted a while back)
- Remove stuff from omap3_dbginit which should never be
used in event handlers
- Cope better with slow clocking during reset
Also, stop hard-wiring the target name: use the input params in
the standard way, and set up $_TARGETNAME as an output param.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Startup now mostly works, except that the initial target state
is "unknown" ... previously, it refused to even start.
Getting that far required fixing the ircapture value (which
can never have been correct!) and the default JTAG clock rate,
then providing custom reset script.
The "reset" command is still iffy. DCSR updates, and loading
the debug handler, report numerous DR/IR capture failures.
But once that's done, "poll" reports that the CPU is halted
(which it shouldn't be, this was "reset run"!), due to the
rather curious reason "target-not-halted".
Summary: you still can't debug these parts, but it's closer.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Without some extra delay after releasing SRST, we seemed to
be trying to talk to the TAP before it was ready to respond.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The model is that this fires after scanchain verification, when it's
safe to call "jtag tapenable $TAPNAME". So it will fire as part of
non-error paths of "init" and "reset" command processing. However it
will *NOT* trigger during "jtag_reset" processing, which skips all
scan chain verification, or after verification errors.
ALSO:
- switch DaVinci chips to use this new mechanism
- log TAP activation/deactivation, since their IDCODEs aren't verified
- unify "enum jtag_event" scripted event notifications
- remove duplicative JTAG_TAP_EVENT_POST_RESET
git-svn-id: svn://svn.berlios.de/openocd/trunk@2800 b42882b7-edfa-0310-969c-e2dbd0fdcd60
It can be sped up later, once it's known the PLLs are active.
Note that modern tools from TI all use adaptive clocking; and
that if that's done with OpenOCD, "too fast" is also a non-issue.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2740 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Update the board config for the DaVinci DM355 EVM so the reset-init
event handler does the rest of the work it should do:
- minor PLL setup bugfixes
- initialize the DDR2 controller
- probe both NAND banks
- initialize UART0
- enable the icache
git-svn-id: svn://svn.berlios.de/openocd/trunk@2699 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- remove endianness options; these chips hard-wire "little"
- $_TARGETNAME updates:
* don't pass $_TARGETNAME where a TAP label is required
* flash config uses $_TARGETNAME (it might not be target #0)
* simplify one $_TARGETNAME construction
- update work area setup:
* remove VM spec; these chips have no VM!
* fix some wrong sizes (0x4000 == 16K, not 4K)
* simplify: take defaults
- comment fixups
git-svn-id: svn://svn.berlios.de/openocd/trunk@2589 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add flash programming support for NXP LPC1700 cortex_m3 based family
git-svn-id: svn://svn.berlios.de/openocd/trunk@2579 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Freddie Chopin
Øyvind Harboe
Marc Pignat
Spencer Oliver
michal smulski
Antonio Borneo
David Brownell
Mariano Alvira
Viktar Palstsiuk
Ethan Eade
Harald Kipp
Edgar Grimberg
Michael Grzeschik
mkdorg@users.sourceforge.net
Yegor Yefremov
Marek Vasut
Zachary T Welch
Thomas Kindler
Wookey
John Rigby
dbrownell
mlu
oharboe
ntfreak