Re: [Openocd-development] arm11 srst behavior
On Tuesday 13 October 2009, michal smulski wrote: arm11 has a bug in that you cannot at the same time assert srst to the arm11 core and access its JTAG logic. Asserting srst will disable TAP logic. Maybe *some* processors do, but I just fired up an OMAP2420 and found that it's not true: jtag_reset 1 1 jtag_reset 0 1 jtag arp_init ... all the scan chain checks work, three active TAPs That's an arm1136 based core. The active taps were an ICEpick-B, the ARM1136, an ETB ... so at the JTAG level there seem to be no issues like that. On Tuesday 13 October 2009, Øyvind Harboe wrote: Can someone help me explain what the effects of asserting srst on an arm11 is? On that chip, it just keeps parts of the system in reset, while leaving the TAP alone. This isn't a new part at all; I think this particular board is almost three years old. Does anyone know how to safely reset an arm11 into the halted state? Well it *said* that it halted fine after reset halt. And it acted OK then too; flash probe worked etc. So I'd think the current code is behaving, modulo issues you might have with iMX31 ... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm11 srst behavior
So I'd think the current code is behaving, modulo issues you might have with iMX31 ... The currrent code target/arm11* code doesn't assert srst, it just issues a halt during assert. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problems with xscale/debug_handler.bin
Worked. Committed. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] simplify XScale debug handler installation
+++ Michael Schwingen [2009-10-13 19:41 +0200]: David Brownell wrote: Looks quite stable to me. I use it regularly at home on IXP42x (I have a BDI2000 at work), mostly in the mode of reset halt / erase program flash / reset run, plus from time to time some gdb-based debugging. I had some problems with breakpoints, but forcing hard breakpoints seems to fix that. Debugging inside the Linux kernel seems a bit tricky for now. I haven't tested new code yet (will do next week), but certainly with existing code we find that on pxa270, the kernel does not boot if openocd has left the CPU running in debug mode. i.e. to reboot and run the kernel we have to do 'jtag_reset 0 1' (to just waggle the reset lines), not 'reset halt/run' (which puts the CPU in debug mode). Presumably it should be possible to boot the kernel with the debug enabled? (It would be very useful). Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fw: [PATCH] OpenRD board configuration
Committed. Thanks! -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's git's equivalent to svn version #?
Hi! On Wed, Oct 14, 2009 at 6:11 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: What's the most reasonable way to refer to a git version for human beings? In svn it's a small integer(only in the thousands). I was thinking about something like 0.2 + N versions. Most git-using people are happy with commit hashes... S. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's git's equivalent to svn version #?
Øyvind Harboe wrote: What's the most reasonable way to refer to a git version for human beings? In svn it's a small integer(only in the thousands). I was thinking about something like 0.2 + N versions. Actually you can checkout things like $ git checkout master~2 Makefile See the branch section and the examples in http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's git's equivalent to svn version #?
On Wed, Oct 14, 2009 at 04:11:33PM +0200, Øyvind Harboe wrote: What's the most reasonable way to refer to a git version for human beings? In svn it's a small integer(only in the thousands). I was thinking about something like 0.2 + N versions. How about 'git describe'? Johannes ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's git's equivalent to svn version #?
On Wednesday 14 October 2009, Johannes Stezenbach wrote: I was thinking about something like 0.2 + N versions. How about 'git describe'? On one recent tree it says: 0.2.0-367-g4bc3132 where the 367 ~= N ... good answer! That also pretty much matches what openocd --version says: Open On-Chip Debugger 0.3.0-dev-00367-g4bc3132-dirty (2009-10-13-15:42) where dirty of course exposes the patches (via quilt) which are on top of this. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's git's equivalent to svn version #?
Well, that won't really work since history is nonlinear. You can git log --oneline -- path/to/file to list out the last commit to modify that file. Then git describe abbreviated_hash_from_first_line_of_log and it'll give you something like: tagname-commit-count-since-gAbbreviated SHA1 which is a valid way to specify a revision. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Wednesday, October 14, 2009 9:12 AM To: openocd-development@lists.berlios.de Subject: [Openocd-development] What's git's equivalent to svn version #? What's the most reasonable way to refer to a git version for human beings? In svn it's a small integer(only in the thousands). I was thinking about something like 0.2 + N versions. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] simplify XScale debug handler installation
On Wednesday 14 October 2009, Michael Schwingen wrote: Have you setup correct Mini-IC entries using the xscale vector_table command? Without that, the kernel crashes on the first exception, since the mini-IC does not match ram contents. We should start collecting hints for Linux debugging. :) Michael, I noticed that the Hot-Debug white paper (now referenced at the top of target/xscale.c) said that it's important to invalidate the Branch Target Buffer (BTB) when updating those vector tables. Quickly glancing at the source code suggested to me that's not done. Did I miss something, or is that a lurking bug? - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] doc updates to match help better
This makes the documentation a closer match to help output:
- pathmove somehow was not documented in the User's Guide
- jtag_nsrst_assert_width and jtag_ntrst_assert_width
are new; both needed descriptions.
- Removed two undocumented and fairly useless script mechanisms:
* production/production_info/production_test ... using it,
requires replacing everything; so having it adds no value.
* cpu ... way out of date; hopeless to keep that current
Note that anyone using that production stuff already defines
their own procedures, and can keep using them with no change.
---
committed ...
doc/openocd.texi | 42 --
src/helper/startup.tcl | 57 ---
2 files changed, 40 insertions(+), 59 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2229,6 +2229,12 @@ needing to cope with both architecture a
@section Commands for Handling Resets
+...@deffn {Command} jtag_nsrst_assert_width milliseconds
+Minimum amount of time (in milliseconds) OpenOCD should wait
+after asserting nSRST (active-low system reset) before
+allowing it to be deasserted.
+...@end deffn
+
@deffn {Command} jtag_nsrst_delay milliseconds
How long (in milliseconds) OpenOCD should wait after deasserting
nSRST (active-low system reset) before starting new JTAG operations.
@@ -2236,6 +2242,12 @@ When a board has a reset button connecte
probably have hardware debouncing, implying you should use this.
@end deffn
+...@deffn {Command} jtag_ntrst_assert_width milliseconds
+Minimum amount of time (in milliseconds) OpenOCD should wait
+after asserting nTRST (active-low JTAG TAP reset) before
+allowing it to be deasserted.
+...@end deffn
+
@deffn {Command} jtag_ntrst_delay milliseconds
How long (in milliseconds) OpenOCD should wait after deasserting
nTRST (active-low JTAG TAP reset) before starting new JTAG operations.
@@ -6083,6 +6095,15 @@ TAP @code{post-reset} events are deliver
with handlers for that event.
@end deffn
+...@deffn Command {pathmove} start_state [next_state ...]
+Start by moving to @var{start_state}, which
+must be one of the @emph{stable} states.
+Then, in a series of single state transitions
+(conforming to the JTAG state machine) shift to
+each @var{next_state} in sequence, one per TCK cycle.
+The final state must also be stable.
+...@end deffn
+
@deffn Command {runtest} @var{num_cycles}
Move to the @sc{run/idle} state, and execute at least
@var{num_cycles} of the JTAG clock (TCK).
@@ -6110,23 +6131,30 @@ Default is enabled.
@cindex TAP state names
The @var{tap_state} names used by OpenOCD in the @command{drscan},
-and @command{irscan} commands are:
+...@command{irscan}, and @command{pathmove} commands are the same
+as those used in SVF boundary scan documents, except that some
+versions of SVF use @sc{idle} instead of @sc{run/idle}.
@itemize @bullet
-...@item @b{RESET} ... acts as if TRST were pulsed
-...@item @b{RUN/IDLE} ... don't assume this always means IDLE
+...@item @b{RESET} ... @emph{stable} (with TMS high);
+acts as if TRST were pulsed
+...@item @b{RUN/IDLE} ... @emph{stable}; don't assume this always means IDLE
@item @b{DRSELECT}
@item @b{DRCAPTURE}
-...@item @b{DRSHIFT} ... TDI/TDO shifting through the data register
+...@item @b{DRSHIFT} ... @emph{stable}; TDI/TDO shifting
+through the data register
@item @b{DREXIT1}
-...@item @b{DRPAUSE} ... data register ready for update or more shifting
+...@item @b{DRPAUSE} ... @emph{stable}; data register ready
+for update or more shifting
@item @b{DREXIT2}
@item @b{DRUPDATE}
@item @b{IRSELECT}
@item @b{IRCAPTURE}
-...@item @b{IRSHIFT} ... TDI/TDO shifting through the instruction register
+...@item @b{IRSHIFT} ... @emph{stable}; TDI/TDO shifting
+through the instruction register
@item @b{IREXIT1}
-...@item @b{IRPAUSE} ... instruction register ready for update or more shifting
+...@item @b{IRPAUSE} ... @emph{stable}; instruction register ready
+for update or more shifting
@item @b{IREXIT2}
@item @b{IRUPDATE}
@end itemize
--- a/src/helper/startup.tcl
+++ b/src/helper/startup.tcl
@@ -291,59 +291,10 @@ proc ocd_process_reset_inner { MODE } {
}
}
-# stubs for targets scripts that do not have production procedure
-proc production_info {} {
- return Imagine an explanation here...
-}
-add_help_text production_info Displays information on production procedure
for target script. Implement this procedure in target script.
-
-proc production {firmwarefile serialnumber} {
- puts Imagine production procedure running successfully. Programmed
$firmwarefile with serial number $serialnumber
-}
-
-add_help_text production serialnumber - Runs production procedure. Throws
exception if procedure failed. Prints progress messages. Implement this
procedure in the target script.
-
-proc production_test {} {
- puts Imagine nifty test procedure having run to completion here.
-}
-add_help_text production_test Runs test procedure.
Re: [Openocd-development] PATCH: 64 bit fixes for Windows x64 compilation using libftdi/libusb
On Tuesday 13 October 2009, Redirect Slash NIL wrote:
Sorry about the inline patch. Please find the original diff file as a text
attachment.
See appended comments. As is usual with this type of port, some
of the type warnings are real issues that need fixing. But a lot
of them seem to be compiler glitches:
- %lld being correct when the parameter is a long long,
as it *IS* here, but for some reason this patch changed
those to require uint64_t and PRIi64.
- %zu being correct for a size_t, but this changes them
to uint64_t and PRIu64
- %jd being correct for an intmax_t, but again this
changing them to use 64-bit types.
Of the ones that are real issues, fixes for most of them are
in the tree now. (Can you verify they're fixed in your build
environment too?) But others seem to need different fixes.
Fixes that won't break _other_ systems, that is!
The jim-eventloop thing deserves a different approach...
The only warning fix is in /src/helper/replacements.c and has to do with
MinGW not linking a long being cast to HANDLE (= 64 bit void*), so I'm
not sure it's worth splitting it (it's still 64 bit related).
If you insist, I'll do it.
The only way I found to address this was to explicitly detect the MinGW 64
bit compilation flags ( #if (defined(_M_X64) || (defined(_M_AMD64))) ),
which I'm not entirely satisfied with since it's far from universal. There's
probably a better way to address this.
I think that deserves to merge standalone -- it's not a general
portability fix like the rest, it's Win64-specific. I'd be
inclined to merge it as-is, and let better fixes be submitted
later. The whole thing is inside an #ifdef _WIN32 anyway...
Can you address the comments below, against current git (which
should have fixes already, as noted)?
- Dave
--- a/src/flash/flash.c
+++ b/src/flash/flash.c
@@ -939,7 +939,7 @@ static int handle_flash_write_bank_command(struct
command_context_s *cmd_ctx, ch
if (retval == ERROR_OK)
{
command_print(cmd_ctx,
- wrote %lld byte from file %s to flash bank
%li at offset 0x%8.8 PRIx32 in %s (%f kb/s),
+ wrote % PRIi64 byte from file %s to
flash bank %li at offset 0x%8.8 PRIx32 in %s (%f kb/s),
fileio.size,
This is wrong; fileio.size is a long long so %lld is correct;
while PRIi64 isn't.
This looks like a compiler bug. The toolchain you referenced seems
to be in active development ... so I'm quite reluctant to accept
such changes!
Possibly related: I notice that http://mingw-w64.sourceforge.net
has a release dated *TODAY*. Maybe your toolchain has an update
that addresses these issues?
args[1],
strtoul(args[0], NULL, 0),
--- a/src/flash/mflash.c
+++ b/src/flash/mflash.c
@@ -474,8 +474,8 @@ static int mg_mflash_read_sects(void *buff, uint32_t
sect_num, uint32_t sect_cnt
residue = sect_cnt % 256;
for (i = 0; i quotient; i++) {
- LOG_DEBUG(mflash: sect num : % PRIu32 buff : 0x%0lx,
sect_num,
- (unsigned long)buff_ptr);
+ LOG_DEBUG(mflash: sect num : % PRIu32 buff : 0x%0PRIx64,
sect_num,
+ (unsigned long long)buff_ptr);
This is wrong; buff_ptr is a pointer. A better fix for this
would be to use %p instead ...
(FIX merged)
ret = mg_mflash_do_read_sects(buff_ptr, sect_num, 256);
if (ret != ERROR_OK)
return ret;
@@ -485,8 +485,8 @@ static int mg_mflash_read_sects(void *buff, uint32_t
sect_num, uint32_t sect_cnt
}
if (residue) {
- LOG_DEBUG(mflash: sect num : % PRIx32 buff : %0lx,
sect_num,
- (unsigned long)buff_ptr);
+ LOG_DEBUG(mflash: sect num : % PRIx32 buff : %0PRIx64,
sect_num,
+ (unsigned long long)buff_ptr);
Same: buff_ptr is a pointer, so %p is better.
(FIX merged)
return mg_mflash_do_read_sects(buff_ptr, sect_num, residue);
}
@@ -751,7 +751,7 @@ static int mg_write_cmd(struct command_context_s
*cmd_ctx, char *cmd, char **arg
duration_stop_measure(duration, duration_text);
- command_print(cmd_ctx, wrote %lli byte from file %s in %s (%f kB/s),
+ command_print(cmd_ctx, wrote % PRIi64 byte from file %s in %s (%f
kB/s),
fileio.size, args[1], duration_text,
Same issue as before, with fileio.size ... it's long long, so
what's coded there is already correct. Alternatively, maybe make
fileio.size become a size_t and use %zd. (Except ... you had
issues with that, elsewhere.)
(float)fileio.size / 1024.0 / ((float)duration.duration.tv_sec
+ ((float)duration.duration.tv_usec / 100.0)));
--- a/src/flash/nand.c
+++ b/src/flash/nand.c
@@ -1609,7 +1609,7 @@ static int handle_nand_dump_command(struct
Re: [Openocd-development] SWJ interface support -- expand vsllink_execute_queue command type
On Tuesday 13 October 2009, simon qian wrote: Any comments or suggestions? I don't follow. Maybe if you showed the proposed change to src/jtag/interface.h and sketched how it would be used in higher level code, that would help... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NS9360 Unknown EmbeddedICE version and halt problem
On Monday 12 October 2009, Henry Margies wrote: By the way, I just found the BSDL file for the NS9360 CPU. Not sure if that is helping, but it says (things like): -- Specifies the number of bits in the instruction register. attribute INSTRUCTION_LENGTH of cooper: entity is 3; So that's not the CPU itself being described ... it's the boundary scan TAP. I've seen this done in two ways: - Like Atmel does, with a signal controlling which TAP is exposed through the JTAG signals. Developers use the not boundary scan option. Production test uses the other one. - Like various other vendors. The scan chain has two TAPs ... one for boundary scan, the other for ARM. Doesn't the current code tell you how many TAPs it finds? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Bug report with FT2232H
On Monday 12 October 2009, Jiří Kubias wrote: Im using Amontec JTAGkey2 with FT2232H with LPC2364. The Openocd often reports me this error: Error: couldn't read the requested number of bytes from FT2232 device (76 81) Error: couldn't read from FT2232 Im using libftdi. Usually I get this error consecutively for random times. But after couple restarts it start working. Someone with FT2232H experience may have ideas. Do you know whether it's trying to use the higher speed clock rate? Or adaptive clocking? I also get this error Error: EmbeddedICE v7 handling might be broken That suggests problems to me. The LPC2364 uses ARM7TDMI-S rev4, yes? Docs on that are a bit confused. infocenter.arm.com says that the EmbeddedICE version there should be 1, not 7. Yet it also says that the CTRL and STAT registers have sizes that don't match other v1 parts. I suspect some docs are wrong... If you can, try to sort out the issues with the r4 ARM7TDMI-S core with some JTAG adapter that's not so shiny new ... maybe an older FT2232 adapter (not FT2232H). If there are no such issues, that suggests strongly that you have just one problem, $SUBJECT related. Otherwise you might well have two problems ... or just one, that's not related to $SUBJECT. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ESC Boston report
On Monday 28 September 2009, Brian Hutchinson wrote: I have a BeagleBoard now :) It was a good but busy week! Thanks for the report. ESC can be fun. TI didn't happen to have XDS100 v2 prototypes did they? http://wiki.davincidsp.com/index.php/XDS100 It's an oversight that OpenOCD doesn't support this yet; it's basically Yet Another FT2232-based adapter, geared towards TI boards (like Beagle). The v2 uses the highspeed parts and supports adaptive clocking. It's not shiping yet though. I'd think that when XDS100 v2 ships, it ought to be fairly popular for use with Beagle and such. ;) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
