During cfi_write(), head and tail of destination area
could be not aligned to bus_width.
Since write operation must be at bus_width size, source
buffer size is extended and buffer padded with current
values read from flash.
Force using bus_width to read current value from flash.
Do not use cfi_add_byte() anymore, to allow removing this
function later on.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
NOR flash structure requires each access to be bus_width wide.
Fix read of flash ID accordingly to rule above.
Add case (chip_width == 4), allowed by CFI spec and coherent
with current value of CFI_MAX_CHIP_WIDTH but currently not
used by any target.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Since NOR flash devices does not handle "byte enable lanes",
each read/write access involves the whole "chip_width".
When multiple devices are in parallel, usually all chips are
enabled during each access.
All such cases are compatible with flash accesses at
"bus_width" size.
Access at "bus_width" size is mandatory for write access to
avoid transferring of garbage values to flash.
During read access the flash controller should take care,
and discard unneeded bytes. Anyway, it is good practice to
use "bus_width" size also for read.
Every memory access that does not respect "bus_width" size
is marked with a "FIXME" comment.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Review and simplify computation of bufferwsize.
Add comments about variables' meaning.
The same code is present 3 times in the file.
Current patch updates all the 3 instances.
Step 1)
Replace "switch(bank->chip_width) {...}".
Illegal values of bank->chip_width are already dropped.
For legal values, the code is equivalent to:
bufferwsize = buffersize / bank->chip_width;
Step 2)
The above code replacement plus the following line:
bufferwsize /= (bank->bus_width / bank->chip_width);
is merged in a single formula:
bufferwsize = (buffersize / bank->chip_width) /
(bank->bus_width / bank->chip_width);
and simplified as:
bufferwsize = buffersize / bank->bus_width;
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Arguments chip_width and bus_width of command "flash bank" are
not fully checked.
While bus_width is later on redundantly checked in several other
parts (e.g. in cfi_command_val()) and generates run-time error,
chip_width is never checked, nor related to actual bus_width
value.
Added check to avoid:
- (chip_width == 0), that would mean no memory chip at all,
avoiding also division by zero e.g. in cfi_get_u8();
- (bus_width == 0), that would mean no bus at all;
- unsupported cases of chip_width or bus_width value not power
of 2;
- unsupported case of chip width wider than bus.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
reproducable when "./configure --enable-maintainer-mode CFLAGS=-D_DEBUG_GDB_IO_"
Signed-off-by: Jun Ma <sync.jma@gmail.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Last block was being skipped, fix by changing the loop test from "<" to "<="
First block argument was ignored, always started from block 0 (and counted
the wrong blocks as bad if first was nonzero). Now we use it.
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The last_block argument to nand_erase() is checked against nand->num_blocks,
but the highest valid block number is (total - 1), the test for invalid should
be ">=" rather than ">".
Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
flash cmds can now be passed either the bank name or the bank number.
For example.
flash info stm32.flash
flash info 0
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
Hi,
This is my first post to the list. First, I would like to thank
everyone for their work on OpenOCD, it is a great tool to work with. I
have been using it to debug code on hardware for the Rockbox project
(www.rockbox.org).
The target that I primarily work with has a Spansion/Fujitsu NOR flash
(MBM29SL800TE). I attached a patch that adds support for this flash. I
hope it can be included in the main repository. If there is something
that needs to be changed with the patch before inclusion please let me
know.
-Karl Kurbjun
The ST/Numonix M29W128G has an issue when a 0xff cmd is sent,
it cause an internal undefined state. The workaround according
to the Numonyx is to send another 0xf0 reset cmd
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
c->sin.sin_port does not contain a valid port number so just use
service->port as this is always correct.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
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>
This stops GDB from launching with an empty memory map,
making gdb load w/flashing fail for no obvious reason.
The error message points in the direction of the gdb-attach
event that can be set up to issue a halt or "reset init"
which will put GDB in a well defined stated upon attach
and thus have a robust flash autoprobe.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
No segmentationfault when sending commands to tcl-server.
modified: src/server/server.c
modified: src/server/tcl_server.c
modified: src/server/tcl_server.h
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>
Remove/fix lots of bugs in handling of non-contigious sections
and out of order sections.
Fix a gaffe introduced in previous commit to src/flash/nor/core.c
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Remove bogus error messages when trying to allocate a
large chunk of target memory and then falling back to
a smaller one.
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>
make wait for srst deassert more long latency friendly
(JTAG over TCP/IP), print actual time if it was more than
1ms.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The current timeout for STM32 flash block erase and flash mass erase is
10 (ms), which is too tight, and fails around 50% of the time for me.
The data sheet for STM32F107VC specifies a maximum erase time of 40 ms
(for both operations).
I'd also consider it a bug that the code does not detect a timeout, but
just assumes that the operation has completed. The attached patch does
not address this bug.
The attached patch increases the timeouts from 10 to 100 ms. Please apply.
/Tobias
Fix a bug where write_image would fail if the sections
in the image were not in ascending order. This has previously
been fixed in gdb load.
Solved by sorting the image sections before running flash
write_image erase unlock foo.elf.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
this is done for unlocking and it is a simple omission that
it wasn't done for sectors.
The unnerving thing is that nobody has complained about this
until now....
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.
If the flash has not yet been probed and GDB connects while the target is
running, the flash probe triggered by GDB's memory map read will fail. In
that case the returned memory map will be empty, causing a subsequent load
from within GDB to fail. There's not much you can do from GDB to recover,
other than a restart; a 'mon reset init' and manual 'mon flash probe' won't
help since GDB has already made up its mind about the memory map.
It seems there's no reason to require the target to be halted when probing
the flash. Remove the check to let a valid memory map be provided to GDB
even when connecting to a running target.
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
The The patch labeled "CFI CORE: bug-fix protect single sector" was merged
rged without some requested bugfixes. Most significantly it broke invariants
in the code, invalidating descriptions and changing the calling convention
for underlying drivers. (It (Also wasn't CFI-specific...)
Fix that, and Include an update from Antonio Borneo for the degenerate
"nothing to do" case, (although that's still in the wrong location. which
is presumably why that is it was working in some cases but not all.)
src/flash/nor/core.c | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Arguments for "flash bank" command are already
parsed and put in "bank" struct.
Removed code to parse them again.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Syntax of "flash bank" command requires:
- chip_width as CMD_ARGV[3]
- bus_width as CMD_ARGV[4]
Actual code swaps the arguments.
Bug has no run time impact since wrong variables
are only used to check value and both are checked
against same constraint.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
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>
Without this, a system using gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
aborts builds after reporting:
tcl.c: In function ‘handle_irscan_command’:
tcl.c:1168: warning: passing argument 1 of ‘buf_set_u32’ discards qualifiers from pointer target type
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>
Clean up the jtag/tcl.c file, which was one of the biggest and
messiest ones in that directory. Do it by splitting out all the
generic adapter commands to a separate "adapter.c" file (leaving
the "tcl.c" file holding only JTAG utilities).
Also rename the little-used "jtag interface" to "adapter_name", which
should have been at least re-categorized earlier (it's not jtag-only).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The command "flash bank" has updated syntax.
Add the mandatory parameter <target> to the usage message
that prints in case of error.
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>
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>
jtag_get/set_end_state() is now deprecated.
There were lots of places in the code where the end state was
unintentionally modified.
The big Q is whether there were any places where the intention
was to modify the end state. 0.5 is a long way off, so we'll
get a fair amount of testing.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
A fn was copied instead of moved to a new file. The linker
can discard exact copies of fn's without warning.
This is a C++'ism.
However on my Ubuntu 9.10 machine, it fails.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The PIC32MX does not support the ejtag software reset - it is
optional in the ejtag spec.
We perform the equivalent using the microchip specific MTAP cmd's.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
The mips_m4k_assert_reset has now been restructured
so the variant ejtag_srst is not required anymore.
The ejtag software reset will be used if the target does not
have srst connected.
Remove ejtag_srst from docs.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
by ack'ing memory writes immediately and reporting either
at next memory write or stepi/continue time. GDB will then
send off a new packet that is ready by the time the previous
packet has been written to target memory.
On faster adapters this can be as much as 10% improvement.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Unused. If something should happen after context restore, then the
calling code can just do it afterwards.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Unclutter arm_adi_v5.c by moving most transport-specific code
to a transport-specific files adi_v5_{jtag,swd}.c ... it's not
a full cleanup, because of some issues which need to be addressed
as part of SWD support (along with implementing the DAP operations
on top of SWD transport):
- The mess where mem_ap_read_buf_u32() is currently coded to
know about JTAG scan chains, and thus needs rewriting before
it will work with SWD;
- Initialization is still JTAG-specific
Also move JTAG_{DP,ACK}_* constants from adi_v5.h to the JTAG
file; no other code should care about those values.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Until this time only basic SLC functionality exists when you want to use SLC to access external nand flash.
Basic functionality can be selected with command:
lpc3180 select 0 slc
It is anyway very slow to write/read to/from nand flash.
With the new command, SLC speed improved about 20 times, and hardware ECC info also read/written from/to nand flash OOB area:
lpc3180 select 0 slc bulk
Speed improvement achieved by using working are in SRAM of the LPC3250 chip and controlling DMA controller to interact between SRAM and SLC peripheral.
Here are the patches, and if they are ok than take them.
Tested with hitex LPC3250 usb stick.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Fixes bug that prevented users from specifying a base address of
0x80000000 or higher in image commands (flash write_image, etm image,
xscale trace_image).
image.base_address is an offset from the start address contained in
the image file (if there is one), or from 0 (for binary files). As a
signed 32-bit int, it couldn't be greater than 0x7fffffff, which is a
problem when trying to write a binary file to flash above that
address. Changing it to a 64-bit long long keeps it as a signed
offset, but allows it to cover the entire 32-bit address space.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The SRST configuration options are not specific to JTAG, so this
command may be needed with non-JTAG debug sessions. Just move
the command to a different group.
(The TRST options are, however, clearly JTAG-specific, but for
compatibility, they're now left alone. The flags they control
could later be disabled in non-JTAG sessions.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
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>
These routines apply to non-JTAG debug adapters too. To
reduce confusion, give them better (non-misleading) names.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Streamline use of the layout: have the "ft2232_layout" command
look it up and save the result, instead of having a few different
chunks of code looking it up later, and saving just its name (which
is already part of the layout). This
- is cleaner
- reports errors sooner
- facilitates earlier adapter-specific setup
- removes unused "default to "usbjtag" logic
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Simple patch that fixes the broken xscale icache and dcache commands.
This broke when the helper functions and macros were changed.
[ dbrownell@users.sourceforge.net: don't use strcasecmp ]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Remove undesirable
- backslashes at end-of-line;
- initializations of BSS data to zero/NULL;
- overlong lines (80+ characters)
- whitespace issues
- brackets around single-line statements
And other minor issues reported by the Linux "checkpatch" utility
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This patch greatly simplifies the Versaloon driver:
- reducing the code size from more than 50K to less than 28K
- adding support for IR/DR scan with unlimited size
- using tap_get_tms_path and tap_get_tms_path_len.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This includes a driver and matching config file. This support needs to be
enabled through the initial "configure" (use "--enable-buspirate").
Signed-off-by: Michal Demin <michaldemin@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
We'll need to be able to work with debug adapter interfaces (drivers)
even when they're not used for JTAG ... for example, while there are
multi-transport drivers which support JTAG *and* several other
transports (or just one more, like SWD) there are also adapters
with more limited goals (and no JTAG support at all).
Start decoupling the two concepts ("debug adapter driver", "jtag")
by having two command groups, which initialize separately.
This will help us support OpenOCD sessions using only non-JTAG
transports, in which JTAG commands should not be registered.
Update docs to mention that the JTAG, SVF, and XSVF commands
won't work without a JTAG transport.
Note that at least commands working with SRST are still inappropriately
coupled to JTAG ... inappropriate because (a) SRST is not part of the
JTAG standard, for all that many platforms (like ARM) expect it; and also
(b) because they're used with non-JTAG debug and programming interfaces,
too. They should perhaps become generic "interface" operations at some
point. (Similarly with the clock rate to be used by a given adapter.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Antonio Borneo
Jun Ma
Jon Povey
Spencer Oliver
Jun Ma
Karl Kurbjun
Øyvind Harboe
Matthias Bode
Tobias Ringström
Mike Dunn
michal smulski
Andreas Fritiofson
David Brownell
Anton Fedotov
Daniel Bäder
richard vegh
Bradey Honsinger
simon qian
Michal Demin