summaryrefslogtreecommitdiff
path: root/src/target
Commit message (Collapse)AuthorAgeFilesLines
...
* TARGET: fix handling return code of MMU translationAntonio Borneo2010-06-126-26/+0
| | | | | | | | | 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>
* TARGET/ARM920T: fix return valueAntonio Borneo2010-06-121-1/+1
| | | | | | | | | 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>
* TARGET/ARM920T: fix compile warningAntonio Borneo2010-06-121-1/+1
| | | | | | | | | Commit 0538081246fafbfb74d554bb1b758412534aa254 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>
* arm mmu: error propagation added for address translationØyvind Harboe2010-06-117-19/+47
| | | | | | | The return value for MMU translation was a mess, either error or value. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* verify: display up to 128 diff'sØyvind Harboe2010-06-081-11/+19
| | | | | | Showing up to 128 differences. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* etm: print something when trace buffer emptyJon Povey2010-05-311-0/+5
| | | | | | | | 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>
* arm_adi_v5: correct ahbap_debugport_init mem-ap id (bug #23)Spencer Oliver2010-05-211-0/+3
| | | | | | | | 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>
* target: slow targets could cause GDB to time outGary Carlson2010-05-191-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 kb/s to KiB/s in messages about kibibytesJon Povey2010-05-161-4/+4
| | | | | | | 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>
* fix instruction refilling bug when using software breakpoints on a ↵Jun Ma2010-05-121-0/+1
| | | | | | | big-endian arm926ej-s system Signed-off-by: Jun Ma <sync.jma@gmail.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* mips32: 20 second timeout/megabyte for CRC checkSpencer Oliver2010-05-101-1/+3
| | | | | | | There was a fixed 20 second timeout which is too little for large, slow timeout checks. Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
* armv7m: 20 second timeout/megabyte for CRC checkSpencer Oliver2010-05-101-1/+3
| | | | | | | There was a fixed 20 second timeout which is too little for large, slow timeout checks. Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
* flash: stop caching protection stateØyvind Harboe2010-05-051-13/+0
| | | | | | | | | | | | | | 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>
* command context: fix errors when running certain commands on startupØyvind Harboe2010-05-052-19/+18
| | | | | | | | | | | 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: clean up target memory allocation error messagesØyvind Harboe2010-05-042-3/+22
| | | | | | | | | | 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>
* xscale: add support for length arg to wp commandMike Dunn2010-04-241-8/+51
| | | | | | | | | | | | | | | | | | | | | | | 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.
* xscale: fix analyze_trace for trace data collected in wrap modeMike Dunn2010-04-152-216/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* cortex-a8: more MMU supportAnton Fedotov2010-04-142-98/+321
| | | | | | | | | | | | | | | | | | | + 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>
* TARGET/ARM7_9_COMMON: review scope of symbolsAntonio Borneo2010-04-112-17/+14
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* TARGET/MIPS32: review scope of functionsAntonio Borneo2010-04-112-11/+9
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* TARGET/MIPS32_PRACC: review scope of functionsAntonio Borneo2010-04-112-26/+26
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* TARGET/MIPS32_DMAACC: review scope of functionsAntonio Borneo2010-04-112-20/+19
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* TARGET/MIPS_EJTAG: review scope of functionsAntonio Borneo2010-04-102-4/+4
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* TARGET/DSP563XX_ONCE: review scope of functionsAntonio Borneo2010-04-102-8/+2
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* ADI_V5_JTAG: review scope of dataAntonio Borneo2010-04-101-1/+1
| | | | | | Add "static" qualifier to private data. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* ARM920T: review scope of functionsAntonio Borneo2010-04-101-1/+1
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* ARM_JTAG: review scope of functionsAntonio Borneo2010-04-101-1/+1
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* ARM_SIMULATOR: review scope of functionsAntonio Borneo2010-04-102-5/+1
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* ARMV4_5_MMU: review unused symbolsAntonio Borneo2010-04-101-7/+0
| | | | | | | | | Remove unused data: - armv4_5_mmu_page_type_names Remove prototype of not existing function: - armv4mmu_translate_va Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* ARMV4_5: review scope of dataAntonio Borneo2010-04-102-3/+1
| | | | | | Add "static" qualifier to private data. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* EMBEDDEDICE: review scope of functionsAntonio Borneo2010-04-102-2/+3
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* TARGET: review unused symbolsAntonio Borneo2010-04-102-17/+0
| | | | | | | Remove unused functions: - target_all_handle_event Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* TARGET: review scope of functionsAntonio Borneo2010-04-102-29/+15
| | | | | | | Add "static" qualifier to private functions. Remove unused "extern" in src/ecosboard.c Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* ARMv7M: review scope of functionsAntonio Borneo2010-04-101-1/+1
| | | | | | Add "static" qualifier to private functions. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
* Restore deleted '!' characterDavid Brownell2010-04-041-1/+1
| | | | | | | | 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>
* target: are we running algorithm code?David Brownell2010-04-042-1/+16
| | | | | | | | | | | | | | | | | | | | | | 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>
* simplify and unconfuse target_run_algorithm()David Brownell2010-04-042-19/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* xscale: fix trace buffer functionality when resuming from a breakpointMike Dunn2010-03-291-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* target: fix poll offØyvind Harboe2010-03-251-0/+6
| | | | | | | | | | | 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>
* change %x and %d to PRIx32 and PRId32 where needed for cygwinDaniel Bäder2010-03-252-2/+2
|
* fix software breakpoints on xscaleMike Dunn2010-03-221-2/+12
| | | | | | | | | | | | | | | | | | | | | | 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.
* arm breakpoints: amended fix commentØyvind Harboe2010-03-212-2/+11
| | | | | | | | 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>
* jtag: make out_value constØyvind Harboe2010-03-213-57/+54
| | | | | | Tightens up the jtag_add_xxx_scan() API Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* jtag: move towards making out_value constØyvind Harboe2010-03-203-5/+5
| | | | | | | These were relatively straightforward fixes which are backwards compatible. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* jtag: retire jtag_get/set_end_state()Øyvind Harboe2010-03-1915-58/+0
| | | | | | | Voila! This get rids of mysteries about what what state the TAP is in. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* jtag: remove jtag_get_end_state() usageØyvind Harboe2010-03-191-4/+4
| | | | | | | Code inspection indicated what constant end states to use. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* jtag: get rid of unecessary jtag_get_end_state()Øyvind Harboe2010-03-191-12/+21
| | | | | | By code inspection. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* jtag: remove unecessary usage of jtag_get_end_state().Øyvind Harboe2010-03-191-2/+2
| | | | | | By code inspection. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
* jtag: remove jtag_get_end_state()'s that should be unecessaryØyvind Harboe2010-03-194-5/+5
| | | | | | | | 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 underlying problem with xscale icache and dcache commandsMike Dunn2010-03-181-6/+11
| | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.46.0) at 2024-11-01 11:32:38 +0000