Soft breakpoints are currently broken if the MMU is enabled due to incorrect
cache flushing. Until this is fixed, force the use of hardware breakpoints.
Signed-off-by: Aaron Carroll <aaronc@ok-labs.com>
all at91sam9 are nearly the same except sram and soc name
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Patrice Vilchez <patrice.vilchez@atmel.com>
PandaBoard REV EA1 (Panda Early Adopter Program) has a different ID.
This patch add alternate REV EA1 TAP id to configuration file
Signed-off-by: Luca Ellero <lroluk@gmail.com>
* Write to the PRM reset control register should have been 'phys';
* Setup empty reset-assert handlers for the M3's, since the board-level reset
takes care of them;
* Remove the dbginit cruft, because it gets called implicitly on reset.
Signed-off-by: Aaron Carroll <aaronc@cse.unsw.edu.au>
Define a proc which PCBs can easily override.
Also demonstrates how to add multiple TAP exepcted-id's
using arguments.
Added 0x3f0f0f0f as expected TAP-id. Old LPC2148 silicon
I happened to have on my desk?
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
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>
LPC2xxx do not require reset_config srst_pulls_trst. This can cause various "strange" problems when flashing the chip, because "reset halt" actually allows the chip to run for some short period of time and execute some code.
Signed-off-by: Freddie Chopin <freddie_chopin@op.pl>
Due to commit e40aee2954d2beabe1d8c530d9ff1e564fb01f48 we now honour the
targets 'reset_config' setting. Previously we ignored the srst setting
for luminary targets.
Luminary targets have never supported using srst to reset into debug mode
so remove the option from the target configs files.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
When this config was updated in commit e3773e3e3d
the old jtag declaration was not removed.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Rename Atmel target scripts which had wrong name ("at91" missing for ARM7 AT91SAM7..., "at" missing for AVR ATmega...)
Signed-off-by: Freddie Chopin <freddie_chopin@op.pl>
STMicroelectronics controller SMI is not SPEAr specific.
Rename it and change name to every symbol in the code.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Modified spearsmi driver to include support for STR75x
Added missing initialization in tcl file for STR750
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Initial support for ST SPEAr310 and for the evaluation
board EVALSPEAr310 Rev. 2.0.
Scripts are split in generic for SPEAr3xx family and
specific for SPEAr310. This should easily allow adding
new members of the family.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
This patch introduces support for Cortex A8 based Freescale i.MX51 CPU. This CPU
has the Debug Access Port located at a different address (0x60008000) than TI
OMAP3 series of CPUs.
i.MX51 configuration file based on OMAP3 configuration file and an email from
Alan Carvalho de Assis <acassis@gmail.com>.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
measure_clk indicates ca. 3-4MHz, so 1MHz should be safe.
Added self_test proc used to test that rclk worked.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Provide new helper proc that can set up either an SWD or JTAG DAP
based on the transport which is in use -- mostly for SWJ-DP.
Also update some SWJ-DP based chips/targets to use it. The goal
is making SWD-vs-JTAG transparent in most places. SWJ-DP based chips
really need this flexible configuration to cope with debug adapters
that support different transports, without needing new target configs
for each transport or adapter.
For JTAG-DP, callers will use "jtag newtap" directly, as today; only
one chip-level transport option exists.
For SW-DP (e.g. LPC1[13]xx or EFM32, they'll use "swd newdap" directly
(part of an upcoming SWD transport patch). Again, only one transport
option exists, so hard-wiring is appropriate there.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>