This patch adds function called "dap_detect_debug_base()", which should be
called to get location of the ROM Table. By walking ROM Table, it's possible to
discover the location of DAP.
Sadly, some CPUs misreport this value, therefore I had to introduce an fixup
table, which will be used in case such CPU is detected.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
So far most of the people have been using existing ARM966E in the
place of ARM946E, because they have practically the same scan chains.
However, ARM946E has caches, which further complicates JATG handling
via scan-chain. this was preventing single-stepping for ARM946E when
SW breakpoints are used.
This patch thus introduces :
1) Correct cache handling on memory write
2) Possibility to flush whole cache and turn it off during debug, or
just to flush affected lines (faster and better)
3) Correct SW breakpoint handling and correct single-stepping
4) Corrects the bug on CP15 read and write, so CP15 values
are now correctly R/W
Collect variable definitions.
Report syntax error to command dispatcher.
Propagate error when unable to open file.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
short story: if the JTAG clock is too high, then the
behavior will be flaky and kludging the code may
seem to make things beter, but really it's just a red
herring.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
A while back I sent in a patch that adds support for watchpoint lengths greater
than four on xscale. It's been working well, until the other day, when it
caused an unexpected debug exception. Looking into this I realized there is a
case where it breaks: when the length arg is greater than the base address.
This is a consequence of the way the hardware works. Don't see a work-around,
so I added code to xscale_add_watchpoint() to check for and disallow this
combination.
Some more detail... xscale watchpoint hardware does not support a length
directly. Instead, a mask value can be specified (not to be confused with the
optional mask arg to the wp command, which xscale does not support). Any bits
set in the mask are ignored when the watchpoint hardware compares the access
address to the watchpoint address. So as long as the length is a power of two,
setting the mask to length-1 effectively specifies the length. Or so I thought,
until I realized that if the length exceeds the base address, *all* bits of the
base address are ignored by the comaparator, and the watchpoint range
effectively becomes 0 .. length.
Questions, comments, criticisms gratefully received.
Thanks,
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Hi everyone,
Added more LOG_ERROR messsages to watchpoint and breakpoint code, given that the
infrastructure no longer interprets returned error codes. Also changed
existing LOG_INFO and LOG_WARNING to LOG_ERROR for cases where an error is
returned.
Note that the check of the target state is superflous, since the infrastruture
code currently checks this before calling target code. Is this being
reconsidered as well? Also, should we stop returning anything other than
ERROR_OK and ERROR_FAIL?
Comments gratefully received.
Thanks,
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
do not try to interpret "retval" into a string, just
amend a bit about the context of the already reported
error.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
Version 2 of this patch. Code added to breakpoints.c was removed from previous
patch, and item 3 added, per discussion with Øyvind regarding error reporting.
Item 4 added, which I just noticed.
I tried to use a software breakpoint in thumb code on the xscale for the first
time recently, and was surprised to find that it didn't work. The result was
this patch, which does four things:
1): fix trivial cut-n-paste error that caused thumb breakpoints to not work
2): call xscale_set_breakpoint() from xscale_add_breakpoint()
3): log error on data abort in xscale_write_memory()
4): fixed incorrect error code returned by xscale_set_breakpoint() when no
breakpoint register is available; added comment
Item 2 not only makes the xscale breakpoint code consistent with other targets,
but also alerts the user immediately if an error occurs when writing the
breakpoint instruction to target memory (previously, xscale_set_breakpoint() was
not called until execution resumed). Also, calling xscale_breakpoint_set() as
part of the call chain starting with handle_bp_command() and propagating the
return status back up the chain avoids the situation where OpenOCD "thinks" the
breakpoint is set when in reality an error ocurred.
Item 3 provides a helpful message for a common reason for failure to set sw
breakpoint.
This was thoroughly tested, mindful of the fact that breakpoint management is
somewhat dicey during single-stepping.
Comments and criticisms of course gratefully received.
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
I figured since I was poking around in the breakpoint code on other arches, I'd
add this change to those arches that don't do it already. This patch propagates
the return code of <arch>_set_breakpoint() up the call stack. This ensures that
the higher layer breakpoint infrastructure is aware that an error ocurred, in
which case the breakpoint is not recorded.
Normally I wouldn't touch code that I can't test, but the code is very
uniform across architectures, and the change is rather benign, so I figured
after careful inspection that it is safe. If the maintainers or others think
this is imprudent, the patch can be dropped.
Also changed the error code to something more appropriate in two cases where
hardware resources are unavailable.
Comments and criticisms of course gratefully received.
Mike
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Hi everyone,
This simple patch fixes a problem I noticed on the xscale where incorrect values
are sometimes reported by the reg command. The problem can occur when
requesting the value of registers in the xscale-specific register cache. With a
couple of exceptions, none of the registers in the xscale register cache are
automatically retrieved on debug entry. This is probably fine, as they are
unlikely to be needed on a regular basis during a typical debug session, and
they can be retrieved when explicitly requested by name using the reg command.
The problem is that once this is done, the register remains marked as valid for
the remainder of the OpenOCD session, and the reg command will henceforth always
report the same value because it is obtained from the cache and is never again
retrieved from the debug handler on the target.
The fix is to mark all registers in the xscale register cache as invalid on
debug entry (before the two exceptions are retrieved), thus forcing retrieval
(when requested) from the target across resumptions in execution, and avoiding
the reporting of stale values.
Small addition change by Øyvind: change 'i' to unsigned to fix compiler
warning for xscale_debug_entry() fn.
Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
This new cmd adds the ability to choose the Cortex-M3
reset method used.
It defaults to using SRST for reset if available otherwise
it falls back to using NVIC VECTRESET. This is known to work
on all cores.
Move any luminary specific reset handling to the stellaris cfg file.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
committed so as to ease cooperation and to let it be improved
over time.
So far it supports:
- halt/resume
- registers inspection
- memory inspection/modification
I'm still getting up to speed with OpenOCD internals and AVR32 so code is a little
bit messy and I'd appreciate any feedback.
ocd_ prefix is used internally in OpenOCD as a kludge more
or less to deal with the two kinds of commands that OpenOCD
has.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
if polling is off, then "reset run + halt" would fail
since halt incorrectly assumed the target was in the
reset state as it is the internal poll implementation
that moves the sw tracking of the target state out
of the reset state.
To reproduce:
> reset run; halt
JTAG tap: zy1000.cpu tap/device found: 0x1f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x1)
BUG: arm7/9 does not support halt during reset. This is handled in arm7_9_assert_reset()
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
back-off algorithm for polling. Double polling
interval up to 5000ms when it fails.
when polling succeeds, reset backoff.
This avoids flooding logs(as much) when working
with conditions where the target polling will fail.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
It is useful to know that the printed errors are *all* the
errors there were.
Added missing error handling(found by inspection).
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
As the mips32 uses instruction breakpoints for algorithms we do not really
need to check the pc on exit.
This now matches the behaviour of the arm codebase.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
As the armv7m uses instruction breakpoints for algorithms we do not really
need to check the pc on exit.
This now matches the behaviour of the arm4_5 codebase.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Update the arm_checksum_memory and arm_blank_check_memory
algorithms to use a breakpoint instruction on v5 arch.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Use addition for offsetting, not masking. Shorten some lines.
Make "component_start" print-only (unused otherwise; don't save).
Still doesn't resolve the issue where multiple components
are wrongly displaying as NVICs on some Cortex-M3 parts because
many PIDs appear to be zeroes ... maybe adapter related??
Signed-off-by: David Brownell <db@helium.(none)>
Mask the upper bits after 32-bit reads.
Alsoo revert the ugly changes to use PRIx32; just cast to unsized
integers when printing (two chars not eight).
Signed-off-by: David Brownell <db@helium.(none)>
This reverts the incorrect change made to the arm9 cmd group in commit
d1eca9a74c.
The code now matches the docs and the release notes.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
The code did not transfer the last word in no-ack transfers.
The strange thing is that this did not lead to any
observable errors.
This gaffe was introduced in commit 1f5883ea56
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Review allocation of error numbers in openocd
to avoid overlap.
Put brackets around negative numbers to avoid
issues during macro expansion.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Memory read/writes to virtual memory, requires that the CPU is
halted.
Use 'phys' option to write to memory while target is running.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
when locking the debug access fails on the first try, it's a
bit noisy, so print out message that it succeeded on second try.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Add "static" qualifier to private functions.
Move duplicated global declarations from "target/avrt.c"
and "nor/avrf.c" to "target/avrt.h".
Remove unused declarations form "nor/avrf.c".
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
normal code should not call jtag_get_error(), but rather check
the return code from jtag_execute_queue().
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
failure to write to memory was not propagated.
This is an interesting case of broken error handling:
with exceptions we wouldn't have had this at all,
and I also wonder if there is a GCC option to warn
about these kinds of potential bugs.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Parameter "type" of function armv4_5_mmu_translate_va()
is now not used.
Remove the parameter and the "enum" listing its values.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Function armv4_5_mmu_translate_va() now properly signals
errors in the return value.
Remove former error handling by setting variable "type" to
value "-1".
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Function arm920t_write_memory() default return value
should be ERROR_OK.
All cases of local errors are handled immediately and
not further propagated.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Commit 0538081246
introduces a compile time warning:
arm920t.c: In function ‘arm920t_write_memory’:
arm920t.c:567: warning: ‘retval’ may be used uninitialized in this function
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
ETM analyze produced no output when the trace buffer was empty.
This patch provides users with a clue.
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
We request a id register read at the end of ahbap_debugport_init
but we never actually run the queue. In some cases this causes a
segfault.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
This second half of the patch is proposed to clean up some GDB keep alive
issues on arm7_9 targets that start up with very slow clocks. If an attempt
is made to write to key registers on the processor with a slow jtag speed,
GDB timeout warnings appear on the console (at least mine) when "reset halt"
or "reset init" commands are issued from the gdb client:
*** BEFORE PATCH ***
(gdb) monitor reset init
fast memory access is disabled
2 kHz
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1026). Workaround: increase "set remotetimeout" in GDB
JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part:
0x7926, ver: 0x0)
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1027). Workaround: increase "set remotetimeout" in GDB
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1006). Workaround: increase "set remotetimeout" in GDB
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1006). Workaround: increase "set remotetimeout" in GDB
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1006). Workaround: increase "set remotetimeout" in GDB
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not
sent! (1004). Workaround: increase "set remotetimeout" in GDB
RCLK - adaptive
dcc downloads are enabled
fast memory access is enabled
NAND flash device 'NAND 256MiB 3,3V 8-bit' found
(gdb)
I added additional keep alive steps in areas that troubleshooting revealed
were causing problems. I only did this however for non-fast write memory
accesses. I don't think most people would be using fast memory accesses to
write to memory when the jtag and system clocks are slow anyway.
If you disagree with my feeling, think there is a more elegant way to handle
the problem, or think the patch will cause other unforeseen problems with
other targets, let me know. As you can see below, the patch does eliminate
the problem on my development station and I suspect that it will benefit
others.
*** AFTER PATCH ***
(gdb) monitor reset init
fast memory access is disabled
2 kHz
JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part:
0x7926, ver: 0x0)
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
RCLK - adaptive
dcc downloads are enabled
fast memory access is enabled
NAND flash device 'NAND 256MiB 3,3V 8-bit' found
(gdb)
Gary Carlson
Gary Carlson, MSEE
Principal Engineer
Carlson-Minot Inc.
Change download rate messages about kibibytes from "kb/s" to "KiB/s" units.
See: http://en.wikipedia.org/wiki/Data_rate_units
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
There are a million reasons why cached protection state might
be stale: power cycling of target, reset, code executing on
the target, etc.
The "flash protect_check" command is now gone. This is *always*
executed when running a "flash info".
As a bonus for more a more robust approach, lots of code could
be deleted.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Various commands, e.g. "arm mcr xxxx" would fail if invoked upon startup
since it there was no command context defined for the jim interpreter
in that case.
A Jim interpreter is now associated with a command context(telnet,
gdb server's) or the default global command context.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
target memory allocation can be implemented not to show
bogus error messages.
E.g. when trying a big allocation first and then a
smaller one if that fails.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
This patch adds support for the length argument to the xscale implementation of
the wp command. Per discussion with David, the length argument specifies the
range of addresses over which a memory access should generate a debug exception.
This patch utilizes the "mask" feature of the xscale debug hardware to implement
the correct functionality of the length argument. Some limitations imposed by
the hardware are:
- The length must be a power of two, with a minumum of 4.
- Two data breakpoint registers are available, allowing for two watchpoints.
However, if the length of a watchpoint is greater than four, both registers
are used (the second for a mask value), limiting the number of watchpoints
to one.
This patch also removes a useless call to xscale_get_reg(dbcon) in
xscale_set_watchpoint() (value had already been read from the register cache,
and the same previously read value is then modified and written back).
I have been using and testing this patch for a couple days.
Questions, corrections, criticisms of course gratefully received.
This patch fixes the xscale_analyze_trace() function. This function was
defective for a trace collected in 'fill' mode (hiccups with repeated
instructions) and completely broken when buffer overflowed in 'wrap' mode. The
reason for the latter case is that the checkpoint registers were interpreted
incorrectly when two checkpoints are present in the trace (which will be true in
'wrap' mode once the buffer fills). In this case, checkpoint1 register will
contain the older entry, and checkpoint0 the newer. The original code assumed
the opposite. I eventually gave up trying to understand all the logic of the
function, and rewrote it. I think it's much cleaner and understandable now. I
have been using and testing this for a few weeks now. I'm confident it hasn't
regressed in any way.
Also added capability to handle (as best as possible) the case where an
instruction can not be read from the loaded trace image; e.g., partial image.
This was a 'TODO' comment in the original xscale_analyze_trace().
Outside of xcsale_analyze_trace(), these (related) changes were made:
- Remove pc_ok and current_pc elements from struct xscale_trace. These elements
and associated logic are useless clutter because the very first entry placed
in the trace buffer is always an indirect jump to the address at which
execution resumed. This type of trace entry includes the literal address in
the trace buffer, so the initial address of the trace is immediately
determined from the trace buffer contents and does not need to be recorded
when trace is enabled.
- Added num_checkpoints to struct xscale_trace_data, which is necessary in order
to correctly interpret the checkpoint register contents.
- In xscale_read_trace()
- Fix potential array out-of-bounds condition.
- Eliminate partial address entries when parsing trace (can occur in wrap mode).
- Count and record number of checkpoints in trace.
- Added small, inlined utility function xscale_display_instruction() to help
make the code more concise and clear.
TODO:
- Save processor state (arm or thumb) in struct xscale_trace when trace is
enabled so that trace can be analyzed correctly (currently assumes arm mode).
- Add element to struct xscale_trace that records (when trace is enabled)
whether vector table is relocated high (to 0xffff0000) or not, so that a
branch to an exception vector is traced correctly (curently assumes vectors
at 0x0).
+ virt2phys() can now convert virtual address to real
+ read_memory() and write_memory() are renamed to read_phys_memory()
and write_phys_memory()
+ new read_memory() and write_memory() try to resolve real address if
mmu is enambled than perform real address reading/writing
+ if address is bellow 0xc000000 than TTB0 is used for page table
dereference, if above - than TTB1. Linux style of user/kernel address
separation
+ if above fails (i.e address is unspecified) than mode is checked
whether it is Supervisor (than TTB1) or User (than TTB0)
- Software breakpoints doesn't work. You should invoke
"gdb_breakpoint_override hard" before you start debugging
+ cortex_a8_mmu(), cortex_a8_enable_mmu_caches(),
cortex_a8_disable_mmu_caches() are implemented
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
I'm not sure what caused this significant character to get deleted.
it may be related to intermittent Editor or terminal flakes I've
been seeing lately (sigh). This fix is trivial.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Fixing one bug can easily uncover another .... in this case,
making sure that we properly invalidate some cached NOR state when
resuming arbitrary target code turned up an issue when the code
wasn't quite arbitrary (and we couldn't know that, but some parts
of OpenOCD assumed the cache would not be invalidated.
Specifically: some flash drivers (like CFI) update that state in loops
with downloaded algorithms, thus invalidating the state as it's probed.
+ Add a new target state flag, to record whether the target is
running downloaded algorithm code.
+ Use that flag to add a special case: "trust" downloaded algorithms
not to corrupt that cached state, bypassing cache invalidation.
Also update some of the documentation to stipulate that this flavor of
trustworthiness is now *required* ... not just a fortuitous acident.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
For some reason there are *two* schemes for interposing logic into
the run_algorithm() code path... One is a standard procedural wapper
around the target method invocation.
the other (superfluous) one hacked the method table by splicing
a second procedural wrapper into the method table. Remove it:
* Rename its slightly-more-featureful wrapper so it becomes
the standard procedural wrapper, leaving its added logic
(where it should have been in the first place.
Also add a paranoia check, to report targets that don't
support algorithms without traversing a NULL pointer, and
tweak its code structure a bit so it's easier to modify.
* Get rid of the superfluous/conusing method table hacks.
This is a net simplification, making it simpler to analyse what's
going on, and then interpose logic . ... by ensuring there's only one
natural place for it to live.
------------
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Problem: halt at a breakpoint, enable trace buffer ('xscale trace_buffer enable
fill'), then resume. Wait for debug exception when trace buffer fills (if not
sooner due to another breakpoint, vector catch, etc). Instead, never halts.
When halted explicitly from OpenOCD and trace buffer dumped, it contains only
one entry; a branch to the address of the original breakpoint. If the above
steps are repeated, except that the breakpoint is removed before resuming, the
trace buffer fills and the debug exception is generated, as expected.
Cause: related to how a breakpoint is stepped over on resume. The breakpoint is
temporarily removed, and a hardware breakpoint is set on the next instruction
that will execute. xscale_debug_entry() is called when that breakpoint hits.
This function checks if the trace buffer is enabled, and if so reads the trace
buffer from the target and then disables the trace (unless multiple trace
buffers are specified by the user when trace is enabled). Thus you only trace
one instruction before it is disabled.
Solution: kind of a hack on top of a hack, but it's simple. Anything better
would involve some refactoring. This has been tested and trace now works as
intended, except that the very first instruction is not part of the trace when
resuming from a breakpoint.
TODO: still many issues with trace: doesn't work during single-stepping (trace
buffer is flushed each step), 'xscale analyze_trace' works only marginally for
a trace captured in 'fill' mode, and not at all for a trace captured in 'wrap'
mode.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
I don't know when "poll off" broke, but "poll off" didn't
stop background polling of target. The polling status flag
simply wasn't checked in the handle_target timer callback.
All target polling(including power/reset state) is now stopped
upon "poll off".
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
This patch fixes xscale software breakpoints by cleaning the dcache and
invalidating the icache after the bkpt instruction is inserted or removed. The
icache operation is necessary in order to flush the fetch buffers, even if the
icache is disabled (see section 4.2.7 of the xscale core developer's manual).
The dcache is presumed to be enabled; no harm done if not. The dcache is also
invalidated after cleaning in order to safeguard against a future load of
invalid data, in the event that cache_clean_address points to memory that is
valid and in use.
Also corrected a confusing typo I noticed in a comment.
TODO (or not TODO...?): the xscale's 2K "mini dcache" is not cleaned. This
cache is not used unless the 'X' bit in the page table entry is set. This is a
proprietary xscale extension to the ARM architecture. If a target's OS or
executive makes use of this for memory regions holding code, the breakpoint
problem will persist. Flushing the mini dcache requires that 2K of valid
cacheable memory (mapped with 'X' bit set) be designated by the user for this
purpose. The debug handler that gets downloaded to the target will also need to
be extended.
the handling of caches, should be moved into the breakpoint
specific callbacks rather than being plonked into generic
memory write fn's.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
By a bit of code inspection it seems like all of these
instances of jtag_get_end_state() can be unambigously
replaced by constants.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Fix problem with the xscale icache and dcache commands. Both commands were
enabling or disabling the mmu, not the caches
I didn't look any further after my earlier patch fixed the trivial problem
with command argument parsing. Turns out the underlying code was broken.
The resolution is straightforward when you look at the arguments to
xscale_enable_mmu_caches() and xscale_disable_mmu_caches(). I finally
took a deeper look after dumping the cp15 control register (XSCALE_CTRL)
and seeing that the cache bits weren't changing, but the mmu bit was
(which caused all manner of grief, as you can imagine). This has been
tested and works OK now.
src/target/xscale.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
So don't use the name "swjdp" for all DAPs; rename to
plain old "dap", which *is* always correct.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Not sure how the original "move code to adi_v5_swd.c" patch left
some code in the "arm_adi_v5.c" file, but a recent patch was only
a partial fix -- it didn't remove all the duplication.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Marek Vasut
ddraskovic
Øyvind Harboe
Spencer Oliver
Peter Stuge
Antonio Borneo
Mike Dunn
Oleksandr Tymoshenko
David Brownell
Edgar Grimberg
Jon Povey
Gary Carlson
Jun Ma
Anton Fedotov
Daniel Bäder