Re: [Openocd-development] [COMMIT] jlink 8bit TLR patch
peter> In communication with Rolf Segger, who helpfully contacted me, Thank you Mr Segger - your participation and help is quite great, I have several oem versions of your JLINK, I have to say that your company makes good stuff. Keep up the good work. > I don't know how many versions in between are out "in the wild", and which > ones do or don't require the fix. The question is, should we leave it in, > or detect an older firmware and actively suggest an upgrade? The Linux > update utility doesn't work - you have to do it in Windows. > I suggest the following: This happens *ONLY* on power up. Leave it, extra clocks here don't hurt, its done once... Insert a comment that specifically refers to *THIS* thread on the mailing list. Issue a *DEBUG* warning. Let's not confuse a developer who is using OpenOCD if we can "just make it work". Bottom line: "OpenOCD - should just work - out of the (virtual) box". -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [COMMIT] jlink 8bit TLR patch
On Tue, 2 Jun 2009, Spencer Oliver wrote: > I have committed the attached patch to svn. > > - hack added to fix a issue with v5/6 jlink > v5/6 jlink seems to have an issue if the first tap move is not divisible by > 8, so we send a TLR on first power up > > Cheers > Spen Much better than my hack, however... In communication with Rolf Segger, who helpfully contacted me, I've established that newer firmware (dated May 27 2009 17:26:00) does not need the special case of multiples of 8 clocks as its first transaction. My old firmware (Mar 3 2008 18:04:42) requires the mulitple-of-8 clocks. I don't know how many versions in between are out "in the wild", and which ones do or don't require the fix. The question is, should we leave it in, or detect an older firmware and actively suggest an upgrade? The Linux update utility doesn't work - you have to do it in Windows. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] evb_lm3s811 docs
Clarify docs for the evb_lm3s811 layout: works in
two modes, not just one.
---
doc/openocd.texi |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Clarify docs for the evb_lm3s811 layout: works in
two modes, not just one.
---
doc/openocd.texi |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1414,8 +1414,9 @@ Currently valid layout @var{name} values
@item @b{axm0432_jtag} Axiom AXM-0432
@item @b{comstick} Hitex STR9 comstick
@item @b{cortino} Hitex Cortino JTAG interface
-...@item @b{evb_lm3s811} Luminary Micro EVB_LM3S811 as a JTAG interface
-(bypassing onboard processor), no TRST or SRST signals on external connector
+...@item @b{evb_lm3s811} Luminary Micro EVB_LM3S811 as a JTAG interface,
+either for the local Cortex-M3 (SRST only)
+or in a passthrough mode (neither SRST nor TRST)
@item @b{flyswatter} Tin Can Tools Flyswatter
@item @b{icebear} ICEbear JTAG adapter from Section 5
@item @b{jtagkey} Amontec JTAGkey and JTAGkey-Tiny (and compatibles)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] evb_lm3s811 ... don't all those EVBs use thesame JTAG glue?
On Thursday 04 June 2009, Spencer Oliver wrote: > > The name evb_lm3s811 is probably a little confusing. > Luminary seem to use the same interface for all their dev boards, the > name should probably be something more generic. As I suspected. But, for the moment, not on my list of things to change ... though IMO that *would* be a good thing to change for 0.2.0 given that checks out. > The luminary eval boards as you say support two modes, three modes on the > newer ones. > 1. connected to the onboard luminary target > 2. connected to a offboard target using the 20way jtag header. > 3. connect an external jtag tool to the onboard target, eg. jlink. > > All the openocd testing (cfg files) has been with the onboard luminary > target (1) and not passthrough. > So the docs are incorrect in my opinion. That's what I thought. I read the docs from Luminary as "switches automagically between (1) and (2)" so I'll update the docs accordingly. Mode (3) seems like a don't-care from the perspective of the ft2232 glule. > Personally i have not tested the passthrough interface, mainly because there > is no trst, srst - so it is > simpler to connect an amontec dongle for example. Right. I suppose it's good sometimes to verify that OpenOCD works properly without SRST and TRST though. (Mode 1 seems to have only SRST though, say schematics.) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] target/at91rm9200.cfg cleanup
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] target/at91rm9200.cfg cleanup
Use "echo" for script output not "puts" (which gets lost).
Minor cleanup and comment addittion.
Use "echo" for script output not "puts" (which gets lost).
Minor cleanup and comment addittion.
--- a/tcl/target/at91rm9200.cfg
+++ b/tcl/target/at91rm9200.cfg
@@ -1,3 +1,5 @@
+# Atmel AT91rm9200
+# http://atmel.com/products/at91/
reset_config trst_and_srst
@@ -21,31 +23,27 @@ if { [info exists CPUTAPID ] } {
# Never allow the following!
if { $_CPUTAPID == 0x15b0203f } {
- puts "---"
- puts "- ERROR: -"
- puts "- ERROR: TapID 0x15b0203f is wrong for at91rm9200 -"
- puts "- ERROR: The chip/board has a JTAG select pin/jumper -"
- puts "- ERROR: -"
- puts "- ERROR: In one position (0x05b0203f) it selects the -"
- puts "- ERROR: ARM CPU, in the other position (0x1b0203f) -"
- puts "- ERROR: it selects boundry-scan not the ARM -"
- puts "- ERROR: -"
- puts "---"
+ echo "---"
+ echo "- ERROR: -"
+ echo "- ERROR: TapID 0x15b0203f is wrong for at91rm9200 -"
+ echo "- ERROR: The chip/board has a JTAG select pin/jumper -"
+ echo "- ERROR: -"
+ echo "- ERROR: In one position (0x05b0203f) it selects the -"
+ echo "- ERROR: ARM CPU, in the other position (0x1b0203f) -"
+ echo "- ERROR: it selects boundry-scan not the ARM -"
+ echo "- ERROR: -"
+ echo "---"
}
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
-
# Create the GDB Target.
-set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
+set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm920t -endian $_ENDIAN -chain-position $_TARGETNAME
+
# AT91RM9200 has a 16K block of sram @ 0x0020.
-$_TARGETNAME configure -work-area-virt 0x0020 -work-area-phys 0x0020 -work-area-size 0x4000 -work-area-backup 1
+$_TARGETNAME configure -work-area-virt 0x0020 -work-area-phys 0x0020 \
+ -work-area-size 0x4000 -work-area-backup 1
# This chip has a DCC ... use it
arm7_9 dcc_downloads enable
-
-
-
-
-
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] openocd.texi - final commands (ch12/cpu config)
Rework chapter 12 (CPU configuration) to use @deffn, match
the code more closely, and present things more clearly.
Includes the *current* list of targets.
Whew ... this should be the last set of "reference matter"
changes, I think all the commands (except the JTAG adapter
ones mentioned earlier) have been reviewed, corrected, and
updated.
---
doc/openocd.texi | 672 +
1 file changed, 429 insertions(+), 243 deletions(-)
Rework chapter 12 (CPU configuration) to use @deffn, match
the code more closely, and present things more clearly.
Includes the *current* list of targets.
Whew ... this should be the last set of "reference matter"
changes, I think all the command (except the JTAG adapter
ones mentioned earlier) have been reviewed, corrected, and
updated.
---
doc/openocd.texi | 672 +
1 file changed, 429 insertions(+), 243 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1262,7 +1262,7 @@ the port @var{number} defaults to .
@cindex GDB configuration
You can reconfigure some GDB behaviors if needed.
The ones listed here are static and global.
-...@xref{target Create}, about declaring individual targets.
+...@xref{target Configuration}, about configuring individual targets.
@xref{Target Events}, about configuring target-specific event handling.
@anchor{gdb_breakpoint_override}
@@ -2096,11 +2096,173 @@ for querying the state of the JTAG taps.
@chapter CPU Configuration
@cindex GDB target
-This chapter discusses how to create a GDB debug target for a CPU.
+This chapter discusses how to set up GDB debug targets for CPUs.
You can also access these targets without GDB
-(@pxref{Architecture and Core Commands}) and, where relevant,
+(@pxref{Architecture and Core Commands},
+and @ref{Target State handling}) and
through various kinds of NAND and NOR flash commands.
-Also, if you have multiple CPUs you can have multiple such targets.
+If you have multiple CPUs you can have multiple such targets.
+
+We'll start by looking at how to examine the targets you have,
+then look at how to add one more target and how to configure it.
+
+...@section Target List
+
+All targets that have been set up are part of a list,
+where each member has a name.
+That name should normally be the same as the TAP name.
+You can display the list with the @command{targets}
+(plural!) command.
+This display often has only one CPU; here's what it might
+look like with more than one:
+...@verbatim
+CmdNameType Endian AbsChainPos Name State
+-- -- -- -- --- - --
+ 0: rm9200.cpu arm920tlittle 2 rm9200.cpu running
+ 1: MyTarget cortex_m3 little 0 mychip.cpu halted
+...@end verbatim
+
+One member of that list is the @dfn{current target}, which
+is implicitly referenced by many commands.
+In particular, memory addresses often refer to the address
+space seen by that current target.
+Commands like @command{mdw} (memory display words)
+and @command{flash erase_address} (erase NOR flash blocks)
+are examples; and there are many more.
+
+Several commands let you examine the list of targets:
+
+...@deffn Command {target count}
+Returns the number of targets, @math{N}.
+The highest numbered target is @math{N - 1}.
+...@example
+set c [target count]
+for @{ set x 0 @} @{ $x < $c @} @{ incr x @} @{
+# Assuming you have created this function
+print_target_details $x
+...@}
+...@end example
+...@end deffn
+
+...@deffn Command {target current}
+Returns the name of the current target.
+...@end deffn
+
+...@deffn Command {target names}
+Lists the names of all current targets in the list.
+...@example
+foreach t [target names] @{
+puts [format "Target: %s\n" $t]
+...@}
+...@end example
+...@end deffn
+
+...@deffn Command {target number} number
+The list of targets is numbered starting at zero.
+This command returns the name of the target at index @var{number}.
+...@example
+set thename [target number $x]
+puts [format "Target %d is: %s\n" $x $thename]
+...@end example
+...@end deffn
+
+...@c yep, "target list" would have been better.
+...@c plus maybe "target setdefault".
+
+...@deffn Command targets [name]
+...@emph{note: the name of this command is plural. Other target
+command names are singular.}
+
+With no parameter, this command displays a table of all known
+targets in a user friendly form.
+
+With a parameter, this command sets the current target to
+the given target with the given @var{name}; this is
+only relevant on boards which have more than one target.
+...@end deffn
+
+...@section Target CPU Types and Variants
+
+Each target has a @dfn{CPU type}, as shown in the output of
+the @command{targets} command. You need to specify that type
+when calling @command{target create}.
+The CPU type indicates more than just the instruction set.
+It also indicates how that instruction set is imple
