couple questions about trying flyswatter 2 on beagle xm from fedora 20

following up on my earlier post on JTAG debugging, i dug into my
supplies and found my flyswatter 2 and associated cables and started
following the instructions here:

  http://elinux.org/Flyswatter2_Beagleboard_XM_How_To

and ran into a couple issues.

  the first is that, if you look at the photos on that page, there's a
discrepancy between pics 4 and 5, as pic 4 shows the 10-pin ribbon
cable being connected, then suddenly that cable has vanished in pic 5,
and is replaced by the serial cable in pic 6, which is kind of
confusing.

  the bigger issue is an apparent bug in openocd. there is an openocd
package for fedora 20, which i installed with yum -- it's version
0.7.0, which appears to be the latest version. if i then connect the
USB cable and run the appropriate openocd command, i get:

# openocd -f interface/flyswatter2.cfg -f board/ti_beagleboard_xm.cfg -c init -c "reset init"
Open On-Chip Debugger 0.7.0 (2013-09-07-16:51)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10 kHz
Warn : dm37x.dsp: huge IR length 38
Runtime Error: embedded:startup.tcl:20: Unknown target type cortex_a,
try one of arm7tdmi, arm9tdmi, arm920t, arm720t, arm966e, arm946e,
arm926ejs, fa526, feroceon, dragonite, xscale, cortex_m, cortex_a8,
cortex_r4, arm11, mips_m4k, avr, dsp563xx, dsp5680xx, testee,
avr32_ap7k, or hla_target
in procedure 'script'
at file "embedded:startup.tcl", line 58
at file "/usr/share/openocd/scripts/board/ti_beagleboard_xm.cfg", line 5
in procedure 'target' called at file "/usr/share/openocd/scripts/target/amdm37x.cfg", line 144
in procedure 'ocd_bouncer'
at file "embedded:startup.tcl", line 20

... snip ...

  oh, wait, i found the additional elinux page:

http://elinux.org/OpenOCD_Config_Files

with apparently newer versions of some of the files, including the
very file that gave me trouble. i will continue reading ...

rday

  following up on my earlier post on JTAG debugging, i dug into my
supplies and found my flyswatter 2 and associated cables and started
following the instructions here:

  http://elinux.org/Flyswatter2_Beagleboard_XM_How_To

and ran into a couple issues.

  the first is that, if you look at the photos on that page, there's a
discrepancy between pics 4 and 5, as pic 4 shows the 10-pin ribbon
cable being connected, then suddenly that cable has vanished in pic 5,
and is replaced by the serial cable in pic 6, which is kind of
confusing.

Yes, PIC4 and 5 are slightly confusing and incorrect.

  the bigger issue is an apparent bug in openocd. there is an openocd
package for fedora 20, which i installed with yum -- it's version
0.7.0, which appears to be the latest version. if i then connect the
USB cable and run the appropriate openocd command, i get:

# openocd -f interface/flyswatter2.cfg -f board/ti_beagleboard_xm.cfg -c init -c "reset init"
Open On-Chip Debugger 0.7.0 (2013-09-07-16:51)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10 kHz
Warn : dm37x.dsp: huge IR length 38
Runtime Error: embedded:startup.tcl:20: Unknown target type cortex_a,
try one of arm7tdmi, arm9tdmi, arm920t, arm720t, arm966e, arm946e,
arm926ejs, fa526, feroceon, dragonite, xscale, cortex_m, cortex_a8,
cortex_r4, arm11, mips_m4k, avr, dsp563xx, dsp5680xx, testee,
avr32_ap7k, or hla_target
in procedure 'script'
at file "embedded:startup.tcl", line 58
at file "/usr/share/openocd/scripts/board/ti_beagleboard_xm.cfg", line 5
in procedure 'target' called at file "/usr/share/openocd/scripts/target/amdm37x.cfg", line 144
in procedure 'ocd_bouncer'
at file "embedded:startup.tcl", line 20
#

  "Unknown target type cortex_a"?

if i go to line 144 of the config file, sure enough, i find:

target create $_TARGETNAME cortex_a -chain-position $_CHIPNAME.dap
                           ^^^^^^^^

should that instead say "cortex_a8"? is this really a bug in openocd?
has anyone else tried this?

Yes, and it used to work. Did the cfg file get patched for cortex_a.

I'd also recommend NOT using the distros OpenOCD, but rather using the
latest version in OpenOCDs Git repo.

i just tried to build openocd from the git repo and, when all was
said and done, i was right back where i started -- with openocd
complaining about an unknown target type of "cortex_a".

  i'll try this again tomorrow after a good night's sleep, but i would
be interested in whether anyone else can get this to work on 64-bit
fedora 20 to talk to the beagleboard xm.

  more tomorrow ...

rday

>
> following up on my earlier post on JTAG debugging, i dug into my
> supplies and found my flyswatter 2 and associated cables and started
> following the instructions here:
>
> http://elinux.org/Flyswatter2_Beagleboard_XM_How_To
>
> and ran into a couple issues.
>
> the first is that, if you look at the photos on that page, there's a
> discrepancy between pics 4 and 5, as pic 4 shows the 10-pin ribbon
> cable being connected, then suddenly that cable has vanished in pic 5,
> and is replaced by the serial cable in pic 6, which is kind of
> confusing.

Yes, PIC4 and 5 are slightly confusing and incorrect.

>
> the bigger issue is an apparent bug in openocd. there is an openocd
> package for fedora 20, which i installed with yum -- it's version
> 0.7.0, which appears to be the latest version. if i then connect the
> USB cable and run the appropriate openocd command, i get:
>
> # openocd -f interface/flyswatter2.cfg -f board/ti_beagleboard_xm.cfg -c init -c "reset init"
> Open On-Chip Debugger 0.7.0 (2013-09-07-16:51)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.sourceforge.net/doc/doxygen/bugs.html
> Info : only one transport option; autoselect 'jtag'
> adapter speed: 10 kHz
> Warn : dm37x.dsp: huge IR length 38
> Runtime Error: embedded:startup.tcl:20: Unknown target type cortex_a,
> try one of arm7tdmi, arm9tdmi, arm920t, arm720t, arm966e, arm946e,
> arm926ejs, fa526, feroceon, dragonite, xscale, cortex_m, cortex_a8,
> cortex_r4, arm11, mips_m4k, avr, dsp563xx, dsp5680xx, testee,
> avr32_ap7k, or hla_target
> in procedure 'script'
> at file "embedded:startup.tcl", line 58
> at file "/usr/share/openocd/scripts/board/ti_beagleboard_xm.cfg", line 5
> in procedure 'target' called at file "/usr/share/openocd/scripts/target/amdm37x.cfg", line 144
> in procedure 'ocd_bouncer'
> at file "embedded:startup.tcl", line 20
> #
>
> "Unknown target type cortex_a"?
>
> if i go to line 144 of the config file, sure enough, i find:
>
> target create $_TARGETNAME cortex_a -chain-position $_CHIPNAME.dap
> ^^^^^^^^
>
> should that instead say "cortex_a8"? is this really a bug in openocd?
> has anyone else tried this?

Yes, and it used to work. Did the cfg file get patched for cortex_a.

I'd also recommend NOT using the distros OpenOCD, but rather using the
latest version in OpenOCDs Git repo.

  i just tried to build openocd from the git repo and, when all was
said and done, i was right back where i started -- with openocd
complaining about an unknown target type of "cortex_a".

  i'll try this again tomorrow after a good night's sleep, but i would
be interested in whether anyone else can get this to work on 64-bit
fedora 20 to talk to the beagleboard xm.

  more tomorrow ...

I'll give it a try as well tomorrow, or Monday.

i'm going to give this another shot but here's the fundamental
problem as i see it. over at elinux.org, there are a number of patches
to earlier openocd ostensibly to add support for the flyswatter2 and
the bb-xm, one of those patches being the file amdm37x.cfg as seen
here:

  http://elinux.org/images/9/95/Amdm37x.cfg

whose most important line seems to be 144:

  target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap

where you can see the reference to "cortex_a8", not just "cortex_a".

  however, i checked out the git repo for openocd from sourceforge and
you can see the latest commit to that very file here:

http://sourceforge.net/p/openocd/code/ci/d9ba56c295f057e716519a798bf9cdb4898c24f4/tree/tcl/target/amdm37x.cfg?diff=ca45e700b1c57caca2ef08e665e3c7e3e02ac8d3

which *renames* "cortex_a8" *back* to "cortex_a". so what's going on?

rday

at the risk of this being *slightly* off-topic, i want to spend
today mucking with my flyswatter2 and openocd and my bb-xm (and
documenting my adventures along the way), so given the page above,
other than the pics being slightly cognitively dissonant, is the
general recipe still valid?

  i followed along, connected my fs2 and bb-xm with both cables, then
connected the fs2 via USB cable to my fedora 20 system and, lo, what
appeared in /var/log/messages:

Jan 6 07:48:45 localhost kernel: [ 5920.204732] usb 2-1.4: new high-speed USB device number 5 using ehci-pci
Jan 6 07:48:46 localhost kernel: [ 5920.294188] usb 2-1.4: New USB device found, idVendor=0403, idProduct=6010
Jan 6 07:48:46 localhost kernel: [ 5920.294199] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 6 07:48:46 localhost kernel: [ 5920.294204] usb 2-1.4: Product: Flyswatter2
Jan 6 07:48:46 localhost kernel: [ 5920.294209] usb 2-1.4: Manufacturer: TinCanTools
Jan 6 07:48:46 localhost kernel: [ 5920.294213] usb 2-1.4: SerialNumber: FS20000
Jan 6 07:48:46 localhost kernel: [ 5920.296082] ftdi_sio 2-1.4:1.0: FTDI USB Serial Device converter detected
Jan 6 07:48:46 localhost kernel: [ 5920.296143] usb 2-1.4: Detected FT2232H
Jan 6 07:48:46 localhost kernel: [ 5920.296148] usb 2-1.4: Number of endpoints 2
Jan 6 07:48:46 localhost kernel: [ 5920.296153] usb 2-1.4: Endpoint 1 MaxPacketSize 512
Jan 6 07:48:46 localhost kernel: [ 5920.296157] usb 2-1.4: Endpoint 2 MaxPacketSize 512
Jan 6 07:48:46 localhost kernel: [ 5920.296161] usb 2-1.4: Setting MaxPacketSize 512
Jan 6 07:48:46 localhost kernel: [ 5920.296612] usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
Jan 6 07:48:46 localhost kernel: [ 5920.298110] ftdi_sio 2-1.4:1.1: FTDI USB Serial Device converter detected
Jan 6 07:48:46 localhost kernel: [ 5920.298167] usb 2-1.4: Detected FT2232H
Jan 6 07:48:46 localhost kernel: [ 5920.298172] usb 2-1.4: Number of endpoints 2
Jan 6 07:48:46 localhost kernel: [ 5920.298176] usb 2-1.4: Endpoint 1 MaxPacketSize 512
Jan 6 07:48:46 localhost kernel: [ 5920.298180] usb 2-1.4: Endpoint 2 MaxPacketSize 512
Jan 6 07:48:46 localhost kernel: [ 5920.298185] usb 2-1.4: Setting MaxPacketSize 512
Jan 6 07:48:46 localhost kernel: [ 5920.298590] usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB1

so i'm taking that as a good sign. more shortly and, yes, i'll write a
wiki page somewhere about this once it's all working.

rday

> Runtime Error: embedded:startup.tcl:20: Unknown target type cortex_a,
> try one of arm7tdmi, arm9tdmi, arm920t, arm720t, arm966e, arm946e,
> arm926ejs, fa526, feroceon, dragonite, xscale, cortex_m, cortex_a8,
> cortex_r4, arm11, mips_m4k, avr, dsp563xx, dsp5680xx, testee,
> avr32_ap7k, or hla_target
> in procedure 'script'
> at file "embedded:startup.tcl", line 58
> at file "/usr/share/openocd/scripts/board/ti_beagleboard_xm.cfg", line 5
> in procedure 'target' called at file "/usr/share/openocd/scripts/target/amdm37x.cfg", line 144
> in procedure 'ocd_bouncer'
> at file "embedded:startup.tcl", line 20
> #
>
> "Unknown target type cortex_a"?
>
> if i go to line 144 of the config file, sure enough, i find:
>
> target create $_TARGETNAME cortex_a -chain-position $_CHIPNAME.dap
>
> should that instead say "cortex_a8"? is this really a bug in openocd?
> has anyone else tried this?

Yes, and it used to work. Did the cfg file get patched for cortex_a.

  right now, the git repo for openocd shows line 144 from
tcl/target/amdm37x.cfg as:

target create $_TARGETNAME cortex_a -chain-position $_CHIPNAME.dap

and the git log for openocd seems fairly insistent that this is the
right target type, despite it being flagged as invalid. is it still
supposed to be patched? here's the openocd patch page from elinux:

  http://elinux.org/OpenOCD_Patches

which goes way back to openocd 0.5.0. should that still be applied?
seems like a long time for an essential patch to not be upstreamed.

I'd also recommend NOT using the distros OpenOCD, but rather using
the latest version in OpenOCDs Git repo.

  normally, i'd agree, but the yum installable openocd package for
fedora 20 is, in fact, version 0.7.0, which is the latest official
release. so i'll try both and see if it makes a difference. back
shortly ...

rday

so, following along here:

http://elinux.org/Flyswatter2_Beagleboard_XM_How_To

if i try the openocd 0.7.0 package that's yum installable on fedora
20, i (predictably) get:

  "Unknown target type cortex_a"

so i hack the file /usr/share/openocd/target/amdm37x.cfg and adjust
a single line thusly:

target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
                           ^^^^^^^^^

and try again and, lo ...

$ sudo openocd -f interface/flyswatter2.cfg -f board/ti_beagleboard_xm.cfg -c init -c "reset init"
Open On-Chip Debugger 0.7.0 (2013-09-07-16:51)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10 kHz
Warn : dm37x.dsp: huge IR length 38
trst_only separate trst_push_pull
Info : max TCK change to: 30000 kHz
Info : clock speed 10 kHz
Info : JTAG tap: dm37x.jrc tap/device found: 0x2b89102f (mfg: 0x017, part: 0xb891, ver: 0x2)
Info : JTAG tap: dm37x.dap enabled
Info : dm37x.cpu: hardware has 6 breakpoints, 2 watchpoints
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x54011140
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x54011150
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x54011150
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x540111c0
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x80000042, MEM_AP_TAR 0x540111c0
adapter speed: 10 kHz
Info : JTAG tap: dm37x.jrc tap/device found: 0x2b89102f (mfg: 0x017, part: 0xb891, ver: 0x2)
Info : JTAG tap: dm37x.dap enabled
adapter speed: 1000 kHz
Warn : dm37x.cpu: ran after reset and before halt ...
Info : number of cache level 2
Error: cache l2 present :not supported
Error: mpdir not in multiprocessor format
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x800001d3 pc: 0x40200f9c
MMU: disabled, D-Cache: disabled, I-Cache: enabled

  which makes me optimistic. i can now telnet in:

$ telnet localhost 4444
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger

  at which point i now have to figure out what i'm doing, but i at
least appear to have a working session.

rday

p.s. i'm looking at the elinux page of OpenOCD config files here:

  http://elinux.org/OpenOCD_Config_Files

and it would appear that, for me, the only file patch i would care
about is amdm37x.cfg. if i'm strictly using the FS2 on my bb-xm, none
of the other patch files are relevant for me, is that correct? and
openocd 0.7.0 already comes with a flyswatter2.cfg file.