Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so >=0.8.0)

2016-08-11 Thread Benjamin Rodgers 
Patched and re-ran.  I can see the difference in the debug output, but the
behavior does not appear to be affected.  I've attached both a debug and
dmesg log.  This time, I've included the dmesg messages printed as a result
of running OpenOCD.


Cheers!

Benjamin Rodgers



On Wed, Aug 10, 2016 at 5:17 PM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:

> Looking into it. The failure is on a really low level because the scan
> chain discovery just finds garbage. I suspect a problem with the reset
> signals because the I/O initialization seems to otherwise match the legacy
> driver. Looking at the old driver it seems the adapter has fully
> tristate-buffered reset signals even though they are not used as such. Not
> sure why that should be a problem but can you anyway try the following
> config file patch?
>
> diff --git a/tcl/interface/ftdi/sheevaplug.cfg b/tcl/interface/ftdi/
> sheevaplug.cfg
> index f299f27..5e3f369 100644
> --- a/tcl/interface/ftdi/sheevaplug.cfg
> +++ b/tcl/interface/ftdi/sheevaplug.cfg
> @@ -10,5 +10,5 @@ ftdi_vid_pid 0x9e88 0x9e8f
>  ftdi_channel 1
>
>  ftdi_layout_init 0x0608 0x0f1b
> -ftdi_layout_signal nTRST -data 0x0200
> -ftdi_layout_signal nSRST -noe 0x0400
> +ftdi_layout_signal nTRST -data 0x0200 -noe 0x0100
> +ftdi_layout_signal nSRST -data 0x0800 -noe 0x0400
>




>
> Nothing in dmesg when openocd starts and ttyUSB0 goes missing? I just want
> to confirm that openocd actually opens the correct interface, otherwise
> that could be the problem (talking JTAG with the serial port circuitry).
> The "ftdi_channel 1" option is not used a lot and I've never tested it
> myself. A disappearing serial port might indicate that the interface is
> actually wrong, but it could also be some quirk of
> libusb/ftdi_sio/virtualbox.
>
> Regards,
> Andreas Fritiofson
>
vagrant@jessie:~$ git -C openocd-code rev-parse HEAD
cd9b9a636411671808e8669ad8d6ee8f8815ad1b
vagrant@jessie:~$ git -C openocd-code diff
diff --git a/tcl/interface/ftdi/sheevaplug.cfg 
b/tcl/interface/ftdi/sheevaplug.cfg
index f299f27..5e3f369 100644
--- a/tcl/interface/ftdi/sheevaplug.cfg
+++ b/tcl/interface/ftdi/sheevaplug.cfg
@@ -10,5 +10,5 @@ ftdi_vid_pid 0x9e88 0x9e8f
 ftdi_channel 1
 
 ftdi_layout_init 0x0608 0x0f1b
-ftdi_layout_signal nTRST -data 0x0200
-ftdi_layout_signal nSRST -noe 0x0400
+ftdi_layout_signal nTRST -data 0x0200 -noe 0x0100
+ftdi_layout_signal nSRST -data 0x0800 -noe 0x0400
vagrant@jessie:~$ sudo openocd -d 3 -f 
/usr/local/share/openocd/scripts/board/sheevaplug.cfg
Open On-Chip Debugger 0.10.0-dev-00335-gcd9b9a6 (2016-08-10-20:54)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
User : 13 2 command.c:544 command_print(): debug_level: 3
Debug: 14 2 options.c:96 add_default_dirs(): bindir=/usr/local/bin
Debug: 15 3 options.c:97 add_default_dirs(): pkgdatadir=/usr/local/share/openocd
Debug: 16 3 options.c:98 add_default_dirs(): run_prefix=
Debug: 17 3 configuration.c:42 add_script_search_dir(): adding /root/.openocd
Debug: 18 4 configuration.c:42 add_script_search_dir(): adding 
/usr/local/share/openocd/site
Debug: 19 4 configuration.c:42 add_script_search_dir(): adding 
/usr/local/share/openocd/scripts
Debug: 20 4 configuration.c:82 find_file(): found 
/usr/local/share/openocd/scripts/board/sheevaplug.cfg
Debug: 21 4 configuration.c:82 find_file(): found 
/usr/local/share/openocd/scripts/interface/ftdi/sheevaplug.cfg
Debug: 22 5 command.c:143 script_debug(): command - ocd_command ocd_command 
type ocd_interface ftdi
Debug: 23 5 command.c:143 script_debug(): command - interface ocd_interface ftdi
Debug: 25 5 command.c:364 register_command_handler(): registering 
'ocd_ftdi_device_desc'...
Debug: 26 5 command.c:364 register_command_handler(): registering 
'ocd_ftdi_serial'...
Debug: 27 5 command.c:364 register_command_handler(): registering 
'ocd_ftdi_location'...
Debug: 28 5 command.c:364 register_command_handler(): registering 
'ocd_ftdi_channel'...
Debug: 29 5 command.c:364 register_command_handler(): registering 
'ocd_ftdi_layout_init'...
Debug: 30 5 command.c:364 register_command_handler(): registering 
'ocd_ftdi_layout_signal'...
Debug: 31 6 command.c:364 register_command_handler(): registering 
'ocd_ftdi_set_signal'...
Debug: 32 6 command.c:364 register_command_handler(): registering 
'ocd_ftdi_vid_pid'...
Debug: 33 6 command.c:364 register_command_handler(): registering 
'ocd_ftdi_tdo_sample_edge'...
Debug: 34 6 command.c:143 script_debug(): command - ocd_command ocd_command 
type ocd_ftdi_device_desc SheevaPlug JTAGKey FT2232D B
Debug: 35 6 command.c:143 script_debug(): command - ftdi_device_desc 
ocd_ftdi_device_desc SheevaPlug JTAGKey FT2232D B
Debug: 37 6 command.c:143 script_debug(): command - ocd_command ocd_command 
type ocd_ftdi_vid_pid 0x9e88 0x9e8f
Debug: 38 6 command.c:143 script_debug(): command - ftdi_vid_pid 
ocd_ftdi_vid_pid 0x9e88 0x9e8f
Debug: 40 6 command.c:143 script_debug(): command - ocd_command ocd_command 
type

Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so >=0.8.0)

2016-08-10 Thread Andreas Fritiofson 
Looking into it. The failure is on a really low level because the scan
chain discovery just finds garbage. I suspect a problem with the reset
signals because the I/O initialization seems to otherwise match the legacy
driver. Looking at the old driver it seems the adapter has fully
tristate-buffered reset signals even though they are not used as such. Not
sure why that should be a problem but can you anyway try the following
config file patch?

diff --git a/tcl/interface/ftdi/sheevaplug.cfg
b/tcl/interface/ftdi/sheevaplug.cfg
index f299f27..5e3f369 100644
--- a/tcl/interface/ftdi/sheevaplug.cfg
+++ b/tcl/interface/ftdi/sheevaplug.cfg
@@ -10,5 +10,5 @@ ftdi_vid_pid 0x9e88 0x9e8f
 ftdi_channel 1

 ftdi_layout_init 0x0608 0x0f1b
-ftdi_layout_signal nTRST -data 0x0200
-ftdi_layout_signal nSRST -noe 0x0400
+ftdi_layout_signal nTRST -data 0x0200 -noe 0x0100
+ftdi_layout_signal nSRST -data 0x0800 -noe 0x0400

On Wed, Aug 10, 2016 at 11:23 PM, Benjamin Rodgers <
benjamin.rodg...@verizondigitalmedia.com> wrote:
>
> On Wed, Aug 10, 2016 at 3:24 AM, Andreas Fritiofson  fritiof...@gmail.com> wrote:
>>
>> On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers > zondigitalmedia.com> wrote:
>>>
>>> On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
>>> andr...@fritiofson.net> wrote:
>>>
 On Wed, 22 Jul 2015 14:17:31 +0100 Philip Hands  wrote:

> I notice that running openocd causes the /dev/ttyUSB0 device to
> disapear,
> so it's certainly doing something, even if it's not very useful.


 OpenOCD detaches the kernel driver on the selected interface (FTDI
 channel)
 which might serve a serial port if so configured. Do you really have a
 tty
 on the same interface/channel as the JTAG circuitry? Channel A *should*
 be
 unaffected by OpenOCD if "ftdi_channel 1" is selected.
>>>
>>>
>>> With the legacy driver "/dev/ttyUSB0" is no longer disappearing upon
>>> running OpenOCD.  It was disappearing with the FTDI driver.
>>>
>>
>> Can you send the output of "lsusb -v -d 0x9e88:0x9e8f" and whatever adds
>> to "dmesg" after plugging in the adapter and starting openocd (beginning
>> with the line "new full-speed USB device number...")?
>>
>
> I've attached the output of both (lsusb.txt, dmesg.txt).
>
>
Nothing in dmesg when openocd starts and ttyUSB0 goes missing? I just want
to confirm that openocd actually opens the correct interface, otherwise
that could be the problem (talking JTAG with the serial port circuitry).
The "ftdi_channel 1" option is not used a lot and I've never tested it
myself. A disappearing serial port might indicate that the interface is
actually wrong, but it could also be some quirk of
libusb/ftdi_sio/virtualbox.

Regards,
Andreas Fritiofson

Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so >=0.8.0)

2016-08-10 Thread Benjamin Rodgers 
On Wed, Aug 10, 2016 at 3:24 AM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:
>
> On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers  verizondigitalmedia.com> wrote:
>
>> I compiled OpenOCD 0.9.0 from source first without
>> "--enable-legacy-ft2232_libftdi" to confirm no change in behavior, and
>> then with "--enable-legacy-ft2232_libftdi".  With a couple caveats, it's
>> actually working now.
>>
>
>>
>
>>
>> Caveat 2:  When I don't have a serial connection open (screen
>> /dev/ttyUSB0 115200), everything works great.  When I do, OpenOCD
>> periodically chokes.  This may be related to my hardware configuration
>> (Debian Jessie as set up by Vagrant debian/jessie64 running on VirtualBox
>> on a Mac), but I'm mentioning it just in case others experience similar
>> behavior.
>>
>> Error: ftdi_write_data: usb bulk write failed
>>> Error: couldn't write MPSSE commands to FT2232
>>> Polling target feroceon.cpu failed, trying to reexamine
>>> Info : Embedded ICE version 0
>>> Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
>>> For reference, the telltale
>>
>>
> This symptom was common with the ft2232 adapter driver (for several
> reasons) and was part of the motivation for the full rewrite. We will not
> fix issues with the deprecated ft2232 driver upstream, in fact we have a
> patch pending to purge it completely. Now that we know that the same setup
> works with ft2232 but not with ftdi, let's focus on getting the latter
> working.
>

Makes sense to me.  Glad I mentioned it.



On Wed, Aug 10, 2016 at 3:24 AM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:
>
> On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers  verizondigitalmedia.com> wrote:
>>
>> On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
>> andr...@fritiofson.net> wrote:
>>
>>> On Wed, 22 Jul 2015 14:17:31 +0100 Philip Hands  wrote:
>>>
 I notice that running openocd causes the /dev/ttyUSB0 device to
 disapear,
 so it's certainly doing something, even if it's not very useful.
>>>
>>>
>>> OpenOCD detaches the kernel driver on the selected interface (FTDI
>>> channel)
>>> which might serve a serial port if so configured. Do you really have a
>>> tty
>>> on the same interface/channel as the JTAG circuitry? Channel A *should*
>>> be
>>> unaffected by OpenOCD if "ftdi_channel 1" is selected.
>>
>>
>> With the legacy driver "/dev/ttyUSB0" is no longer disappearing upon
>> running OpenOCD.  It was disappearing with the FTDI driver.
>>
>
> Can you send the output of "lsusb -v -d 0x9e88:0x9e8f" and whatever adds
> to "dmesg" after plugging in the adapter and starting openocd (beginning
> with the line "new full-speed USB device number...")?
>

I've attached the output of both (lsusb.txt, dmesg.txt).



On Wed, Aug 10, 2016 at 3:24 AM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:
>
> On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers  verizondigitalmedia.com> wrote:
>
For reference, here is the output of OpenOCD with the FTDI driver.
>>
>
>> vagrant@jessie:~/a/openocd-0.9.0$ src/openocd -f
>>> tcl/board/sheevaplug.cfg -s tcl
>>
>>
> Please add "-d" to get a verbose log. Also, if you compile from source
> anyway, use the git master if possible (for easier matching the log to the
> code).
>

Rebuilt from git master and ran with "-d".  I've attached the Vagrantfile
for reference and logged output (debug.txt).


Cheers!

Benjamin Rodgers
...
[6.811545] PM: Hibernation image not present or could not be loaded.
[6.844175] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: 
(null)
[6.863399] usb 1-1: new full-speed USB device number 2 using ohci-pci
[6.943184] tsc: Refined TSC clocksource calibration: 2495.109 MHz
[6.950286] systemd[1]: Cannot add dependency job for unit 
display-manager.service, ignoring: Unit display-manager.service failed to load: 
No such file or directory.
...
[7.146478] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[7.147695] alg: No test for crc32 (crc32-pclmul)
[7.148380] usb 1-1: New USB device found, idVendor=9e88, idProduct=9e8f
[7.148382] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[7.148383] usb 1-1: Product: SheevaPlug JTAGKey FT2232D B
[7.148384] usb 1-1: Manufacturer: FTDI
[7.148385] usb 1-1: SerialNumber: FTJRNOPX
[7.160143] Adding 473084k swap on /dev/sda5.  Priority:-1 extents:1 
across:473084k FS
[7.194573] usbcore: registered new interface driver usbserial
[7.194665] usbcore: registered new interface driver usbserial_generic
[7.194731] usbserial: USB Serial support registered for generic
[7.195806] usbcore: registered new interface driver ftdi_sio
[7.195815] usbserial: USB Serial support registered for FTDI USB Serial 
Device
[7.195837] usb 1-1: Ignoring serial port reserved for JTAG
[7.195853] ftdi_sio 1-1:1.1: FTDI USB Serial Device converter detected
[

Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so >=0.8.0)

2016-08-10 Thread Andreas Fritiofson 
On Wed, Aug 10, 2016 at 4:55 AM, Benjamin Rodgers <
benjamin.rodg...@verizondigitalmedia.com> wrote:

> This issue appears to be affecting me as well while trying to connect to a
> DreamPlug.
>
>
Interesting. Different hardware but both use the feroceon target (rare) and
both use "ftdi_channel 1" (rare). I wonder which is the key to the problem.


>
> I compiled OpenOCD 0.9.0 from source first without 
> "--enable-legacy-ft2232_libftdi"
> to confirm no change in behavior, and then with 
> "--enable-legacy-ft2232_libftdi".
> With a couple caveats, it's actually working now.
>
>

>
> Caveat 2:  When I don't have a serial connection open (screen /dev/ttyUSB0
> 115200), everything works great.  When I do, OpenOCD periodically chokes.
> This may be related to my hardware configuration (Debian Jessie as set up
> by Vagrant debian/jessie64 running on VirtualBox on a Mac), but I'm
> mentioning it just in case others experience similar behavior.
>
> > Error: ftdi_write_data: usb bulk write failed
> > Error: couldn't write MPSSE commands to FT2232
> > Polling target feroceon.cpu failed, trying to reexamine
> > Info : Embedded ICE version 0
> > Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
> > For reference, the telltale
>
>
This symptom was common with the ft2232 adapter driver (for several
reasons) and was part of the motivation for the full rewrite. We will not
fix issues with the deprecated ft2232 driver upstream, in fact we have a
patch pending to purge it completely. Now that we know that the same setup
works with ft2232 but not with ftdi, let's focus on getting the latter
working.


>
> On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
> andr...@fritiofson.net> wrote:
> > On Wed, 22 Jul 2015 14:17:31 +0100 Philip Hands  wrote:
> > > I notice that running openocd causes the /dev/ttyUSB0 device to
> disapear,
> > > so it's certainly doing something, even if it's not very useful.
> >
> > OpenOCD detaches the kernel driver on the selected interface (FTDI
> channel)
> > which might serve a serial port if so configured. Do you really have a
> tty
> > on the same interface/channel as the JTAG circuitry? Channel A *should*
> be
> > unaffected by OpenOCD if "ftdi_channel 1" is selected.
>
> With the legacy driver "/dev/ttyUSB0" is no longer disappearing upon
> running OpenOCD.  It was disappearing with the FTDI driver.
>
>
Can you send the output of "lsusb -v -d 0x9e88:0x9e8f" and whatever adds to
"dmesg" after plugging in the adapter and starting openocd (beginning with
the line "new full-speed USB device number...")?


> For reference, here is the output of OpenOCD with the FTDI driver.
>

> > vagrant@jessie:~/a/openocd-0.9.0$ src/openocd -f
> tcl/board/sheevaplug.cfg -s tcl
>

Please add "-d" to get a verbose log. Also, if you compile from source
anyway, use the git master if possible (for easier matching the log to the
code).

Regards,
Andreas Fritiofson

Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so >=0.8.0)

2016-08-09 Thread Benjamin Rodgers 
This issue appears to be affecting me as well while trying to connect to a
DreamPlug.

Most of my troubleshooting has been performed using with Vagrant
debian/jessie64.  I've tried the backports package for 'openocd' as well,
and dist-upgrading to Stretch.  The only difference I've noticed is that
the OpenOCD shipped with Jessie (0.8.0-4) refuses to match the adapter with
this line in place in
"/usr/share/openocd/scripts/interface/ftdi/sheevaplug.cfg".

> ftdi_device_desc "SheevaPlug JTAGKey FT2232D B"


On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
andr...@fritiofson.net> wrote:
> A lot has happened since 0.5.0 apart from the adapter driver change so the
> problem might lie somewhere else than ftdi vs ft2232. Can you try the
> latest release that included the ft2232 driver (0.8?), or even better,
> build from source and explicitly pass --enable-legacy-ft2232_libftdi to
> configure (make sure you have libusb-1.0 and libftdi dev packages
> installed). The feroceon target has AFAIK not been tested in a long time
so
> there might be issues with that. Does the hardware allow you to connect
> other targets to the same debug adapter or vice versa (i.e. an external
> debug connector or such)? Just trying to reduce the number of unknowns.


I compiled OpenOCD 0.9.0 from source first without
"--enable-legacy-ft2232_libftdi" to confirm no change in behavior, and then
with "--enable-legacy-ft2232_libftdi".  With a couple caveats, it's
actually working now.


Caveat 1:  Switching back to the non-FTDI interface is necessary (obvious
reasons).

> vagrant@jessie:~$ diff -u {a,b}/openocd-0.9.0/tcl/board/sheevaplug.cfg
> --- a/openocd-0.9.0/tcl/board/sheevaplug.cfg 2015-05-17
21:14:10.0 +
> +++ b/openocd-0.9.0/tcl/board/sheevaplug.cfg 2016-08-10
02:07:55.674787653 +
> @@ -1,6 +1,6 @@
>  # Marvell SheevaPlug
>
> -source [find interface/ftdi/sheevaplug.cfg]
> +source [find interface/sheevaplug.cfg]
>  source [find target/feroceon.cfg]
>
>  adapter_khz 2000


Caveat 2:  When I don't have a serial connection open (screen /dev/ttyUSB0
115200), everything works great.  When I do, OpenOCD periodically chokes.
This may be related to my hardware configuration (Debian Jessie as set up
by Vagrant debian/jessie64 running on VirtualBox on a Mac), but I'm
mentioning it just in case others experience similar behavior.

> Error: ftdi_write_data: usb bulk write failed
> Error: couldn't write MPSSE commands to FT2232
> Polling target feroceon.cpu failed, trying to reexamine
> Info : Embedded ICE version 0
> Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
> For reference, the telltale


On Thu, 23 Jul 2015 00:57:21 +0200 Andreas Fritiofson <
andr...@fritiofson.net> wrote:
> On Wed, 22 Jul 2015 14:17:31 +0100 Philip Hands  wrote:
> > I notice that running openocd causes the /dev/ttyUSB0 device to
disapear,
> > so it's certainly doing something, even if it's not very useful.
>
> OpenOCD detaches the kernel driver on the selected interface (FTDI
channel)
> which might serve a serial port if so configured. Do you really have a tty
> on the same interface/channel as the JTAG circuitry? Channel A *should* be
> unaffected by OpenOCD if "ftdi_channel 1" is selected.

With the legacy driver "/dev/ttyUSB0" is no longer disappearing upon
running OpenOCD.  It was disappearing with the FTDI driver.


For reference, here is the output of OpenOCD with the FTDI driver.

> vagrant@jessie:~/a/openocd-0.9.0$ src/openocd -f tcl/board/sheevaplug.cfg
-s tcl
> Open On-Chip Debugger 0.9.0 (2016-08-10-02:21)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> Info : auto-selecting first available session transport "jtag". To
override use 'transport select '.
> 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
> Info : TAP feroceon.cpu does not have IDCODE
> Info : TAP auto0.tap does not have IDCODE
> Info : TAP auto1.tap does not have IDCODE
> Info : TAP auto2.tap does not have IDCODE
> Info : TAP auto3.tap does not have IDCODE


Cheers!

Benjamin Rodgers

Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so =0.8.0)

2015-07-22 Thread Philip Hands 
Package: openocd
Version: 0.9.0-1+b1
Severity: normal

Dear Maintainer,

This is effectively a continuation of bug #751372

I've added the  B to the end of the ftdi_device_desc line in
interface/ftdi/openrd.cfg, thus:

  ftdi_device_desc OpenRD JTAGKey FT2232D B

judging by the output from the working 0.5.0 package, the right number
is probably:

  adapter_khz 3000

(I've also tried various other frequencies without success)

I notice that running openocd causes the /dev/ttyUSB0 device to disapear,
so it's certainly doing something, even if it's not very useful.  If I
then un/re-plug the USB cable, the device comes back, and sometimes works
(sometimes it looks like it's got the wrong baud rate somewhere).

Attached is the output from running this with -d3 -- feel free to ask
me to run other tests, or try other options.

Cheers, Phil.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openocd depends on:
ii  libc6  2.19-18
ii  libhidapi-hidraw0  0.8.0~rc1+git20140201.3a66d4e+dfsg-3
ii  libjim0.76 0.76-1
ii  libusb-0.1-4   2:0.1.12-25
ii  libusb-1.0-0   2:1.0.19-1

openocd recommends no packages.

openocd suggests no packages.

-- no debconf information
# openocd -d3 -f board/openrd.cfg

Open On-Chip Debugger 0.9.0 (2015-05-28-17:08)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
User : 13 3 command.c:546 command_print(): debug_level: 3
Debug: 14 3 options.c:98 add_default_dirs(): bindir=/usr/bin
Debug: 15 3 options.c:99 add_default_dirs(): pkgdatadir=/usr/share/openocd
Debug: 16 3 options.c:100 add_default_dirs(): run_prefix=
Debug: 17 3 configuration.c:44 add_script_search_dir(): adding 
/home/phil/.openocd
Debug: 18 3 configuration.c:44 add_script_search_dir(): adding 
/usr/share/openocd/site
Debug: 19 3 configuration.c:44 add_script_search_dir(): adding 
/usr/share/openocd/scripts
Debug: 20 3 configuration.c:84 find_file(): found 
/usr/share/openocd/scripts/board/openrd.cfg
Debug: 21 3 configuration.c:84 find_file(): found 
/usr/share/openocd/scripts/interface/ftdi/openrd.cfg
Debug: 22 3 command.c:145 script_debug(): command - ocd_command ocd_command 
type ocd_echo WARNING!
Debug: 23 3 command.c:145 script_debug(): command - echo ocd_echo WARNING!
User : 25 3 command.c:764 jim_echo(): WARNING!
Debug: 26 3 command.c:145 script_debug(): command - ocd_command ocd_command 
type ocd_echo This file was not tested with real interface, it is based on code 
in ft2232.c.
Debug: 27 3 command.c:145 script_debug(): command - echo ocd_echo This file was 
not tested with real interface, it is based on code in ft2232.c.
User : 29 3 command.c:764 jim_echo(): This file was not tested with real 
interface, it is based on code in ft2232.c.
Debug: 30 4 command.c:145 script_debug(): command - ocd_command ocd_command 
type ocd_echo Please report your experience with this file to openocd-devel 
mailing list,
Debug: 31 4 command.c:145 script_debug(): command - echo ocd_echo Please report 
your experience with this file to openocd-devel mailing list,
User : 33 4 command.c:764 jim_echo(): Please report your experience with this 
file to openocd-devel mailing list,
Debug: 34 4 command.c:145 script_debug(): command - ocd_command ocd_command 
type ocd_echo so it could be marked as working or fixed.
Debug: 35 4 command.c:145 script_debug(): command - echo ocd_echo so it could 
be marked as working or fixed.
User : 37 4 command.c:764 jim_echo(): so it could be marked as working or fixed.
Debug: 38 4 command.c:145 script_debug(): command - ocd_command ocd_command 
type ocd_interface ftdi
Debug: 39 4 command.c:145 script_debug(): command - interface ocd_interface ftdi
Debug: 41 4 command.c:366 register_command_handler(): registering 
'ocd_ftdi_device_desc'...
Debug: 42 4 command.c:366 register_command_handler(): registering 
'ocd_ftdi_serial'...
Debug: 43 4 command.c:366 register_command_handler(): registering 
'ocd_ftdi_channel'...
Debug: 44 4 command.c:366 register_command_handler(): registering 
'ocd_ftdi_layout_init'...
Debug: 45 4 command.c:366 register_command_handler(): registering 
'ocd_ftdi_layout_signal'...
Debug: 46 4 command.c:366 register_command_handler(): registering 
'ocd_ftdi_set_signal'...
Debug: 47 4 command.c:366 register_command_handler(): registering 
'ocd_ftdi_vid_pid'...
Debug: 48 4 command.c:145 script_debug(): command - ocd_command ocd_command 
type ocd_ftdi_device_desc OpenRD JTAGKey FT2232D B
Debug: 49 4 command.c:145 script_debug(): command - ftdi_device_desc 
ocd_ftdi_device_desc OpenRD JTAGKey FT2232D B
Debug: 51 4 command.c:145 script_debug(): command - ocd_command ocd_command 
type

Bug#793214: openocd: OpenRD Ultimate unsupported since removal of ft2232 (so =0.8.0)

2015-07-22 Thread Andreas Fritiofson 
On Wed, 22 Jul 2015 14:17:31 +0100 Philip Hands p...@hands.com wrote:
 Package: openocd
 Version: 0.9.0-1+b1

 I've added the  B to the end of the ftdi_device_desc line in
 interface/ftdi/openrd.cfg, thus:

   ftdi_device_desc OpenRD JTAGKey FT2232D B

The device really has a B in its product string? I.e. lsusb -v -d0403:9e90
| grep idProduct shows the B? Is the device original?


 judging by the output from the working 0.5.0 package

A lot has happened since 0.5.0 apart from the adapter driver change so the
problem might lie somewhere else than ftdi vs ft2232. Can you try the
latest release that included the ft2232 driver (0.8?), or even better,
build from source and explicitly pass --enable-legacy-ft2232_libftdi to
configure (make sure you have libusb-1.0 and libftdi dev packages
installed). The feroceon target has AFAIK not been tested in a long time so
there might be issues with that. Does the hardware allow you to connect
other targets to the same debug adapter or vice versa (i.e. an external
debug connector or such)? Just trying to reduce the number of unknowns.

 the right number
 is probably:

   adapter_khz 3000

 (I've also tried various other frequencies without success)

The result shouldn't be especially dependent on a specific frequency.
Usually there's a max and lower than that shouldn't make a difference. If
your log is complete there is no frequency issue.


 I notice that running openocd causes the /dev/ttyUSB0 device to disapear,
 so it's certainly doing something, even if it's not very useful.

OpenOCD detaches the kernel driver on the selected interface (FTDI channel)
which might serve a serial port if so configured. Do you really have a tty
on the same interface/channel as the JTAG circuitry? Channel A *should* be
unaffected by OpenOCD if ftdi_channel 1 is selected.

 Attached is the output from running this with -d3 -- feel free to ask
 me to run other tests, or try other options.

Did you truncate the log or did it just freeze right there?

Regards,
Andreas