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>
first cut peek/poke over tcp/ip, used for debug/research
purposes only. Long term JTAG over TCP/IP might be an
offshoot. The performance is usable for development/testing
purposes.
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>
For testing and checking the build this can be useful,
it doesn't have any practical application outside development.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The init cleanup patch overlooked a message which was
wrongly specific to the "usbjtag" layout. Fix.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
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.
In the ft2232 driver, initialization for many layouts punts to a routine
called usbjtag_init(), instead of a routine specific to each layout.
That routine is a mess built around a "what type layout am I" core.
That's a bad design ... in this case, especially so, since it bypasses
the layout-specific dispatch which was just done, and obfuscates the
initialization which is at least somewhat generic, instead of being
specific to the "usbjtag" layout.
Split and document out the generic parts of usbjtag_init(), and make
the rest of those layouts have layout-specific init methods. Also,
rename usbjtag_reset() ... that also was not specific to the "usbjtag"
layout, and thus contributed to the previous code structure confusion.
(Eventually, all layout-specific code (and method tables) should probably
live in files specific to each layout. These changes will facilitate
those and other cleanups to this driver.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
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>
Note that the FT4232 chips have four channels not two, and
Elaborate on uses of the additional channels.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The implementation is now more straightforward as the
scan_fields have been greatly simplified over time.
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>
