On Fri, Sep 16, 2016 at 11:13:53AM +0300, Paul Fertser wrote:
> On Fri, Sep 16, 2016 at 09:55:21AM +0200, David Madore wrote:
> > A SheevaPlug JTAGKey FT2232D (USB identifiers 9e88:9e8f) being
>
> Please also provide lsusb -vvv data for this device.
Bus 003 Device 002: ID 9e88:9e8f
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x9e88
idProduct 0x9e8f
bcdDevice 5.00
iManufacturer 1 FTDI
iProduct 2 SheevaPlug JTAGKey FT2232D B
iSerial 3 FTU85Z4Y
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 55
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 SheevaPlug JTAGKey FT2232D B
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 SheevaPlug JTAGKey FT2232D B
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
> > worked fine with it:
> ...
> > Error: JTAG scan chain interrogation failed: all zeroes
>
> No, this doesn't look fine to me.
Indeed, the JTAG connector was badly connected at the other end.
Here's what the output of openocd 0.5.0-1 looks like when it's
correctly connected (to a GuruPlug):
vega david ~ $ /tmp/openocd-0.5.0/src/openocd -s /tmp/openocd-0.5.0/tcl -f
/tmp/openocd-0.5.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.5.0 (2016-09-16-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
2000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part:
0x0a02, ver: 0x2)
Info : Embedded ICE version 0
Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
- and in case that's of any use, here's the additional stuff it says
when I run "reset ; init ; sheevaplug_load_uboot" from the telnet
interface:
Info : accepting 'telnet' connection from 4444
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part:
0x0a02, ver: 0x2)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
230196 bytes written at address 0x00600000
downloaded 230196 bytes in 1.618897s (138.860 KiB/s)
verified 230196 bytes in 0.839952s (267.635 KiB/s)
> > Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
> ...
> > Error: unable to open ftdi device with vid 9e88, pid 9e8f, description
> > 'SheevaPlug JTAGKey FT2232D' and serial '*'
>
> You might want to try to comment out ftdi_device_desc command from
> interface/ftdi/sheevaplug.cfg to workaround this issue.
Now openocd connects to the device, but it still doesn't work:
vega david ~ $ $ /tmp/openocd-0.8.0/src/openocd -s /tmp/openocd-0.8.0/tcl -f
/tmp/openocd-0.8.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, it is based on code in ft2232.c.
Please report your experience with this file to openocd-devel mailing list,
so it could be marked as working or fixed.
Info : only one transport option; autoselect 'jtag'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 2000 kHz
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 kHz
At this point, the port 4444 is open (accepting connections), but
telnet to it does not provide a prompt; there does not seem to be
anything I can do except type ^C. The behavior is similar with 0.9.0,
except that ^C doesn't work there and I have to kill -9 it.
> > The error message is almost identical with openocd 0.9.0:
> ...
> > Error: unable to open ftdi device with vid 9e88, pid 9e8f,
> > description 'SheevaPlug JTAGKey FT2232D' and serial '*'
>
> The error you report seems to be fixed post-0.8.0, but before 0.9.0,
> in v0.8.0-142-geab9af1 . So it looks as if you're trying to use 0.9.0
> with scripts from 0.8.0.
Ah, indeed, PEBCK for that part, I forgot to pass a -s option when
using openocd from a compilation tree. But still, as noted above,
neither 0.8.0 nor 0.9.0 seem to be able to use the device, they just
get stuck.
--
David A. Madore
( http://www.madore.org/~david/ )
