Lattice Diamond v 3.11 on Linux: problem with ftdio_sio

[gregoireg]

On Linux, since v3.11, it seems that Lattice Diamond can only detect a FTDI cable if the kernel driver ftdio_sio has been removed.

On v3.10 and before, it was possible to just unbind the ftdi tty (ttyUSB*) with a udev rule (many blogs which explain how to install Diamond on Ubuntu mention such procedure - https://ycnrg.org/lattice-diamond-on-ubuntu-16-04/) and not to have to remove the ftdio_sio driver.

Does anyone know a way to still run the Lattice programmer without having to remove the ftdio_sio driver since v3.11?

[SiliconWizard]

I don't use Diamond on Linux, but I do use devices with FTDI chips and I know you need to unbind them from ftdi_sio to be able to access them with libusb, which the Linux FTDI drivers are based on.

The udev rule given in your link looks like the ones I use as well, so that should do?
Are you sure the problem is new with Diamond 3.11, and not that it comes from a recent change in the Linux kernel or something? If you are, maybe they changed something in the way they access FTDI parts in version 3.11, so that previous versions didn't actually show you that the udev rule you used was actually not working quite right.

I think I remember having to slightly modify those udev rules after some kernel update (can't remember which...). The following:

Code: [Select]

basename $(dirname $(realpath /sys%p/device)) may not be correct anymore, something to check.

To check (maybe you already did): plug your device in, then check that the corresponding ttyUSB* devices are not there. If they are, well, the udev rule doesn't work anymore, and it's not a problem with Diamond. AFAIK, in somes cases, the devices may be names like ttyACM* instead of ttyUSB*? So check that as well. Also check the output of 'dmesg'.

Try issuing the unbind (... >  /sys/bus/usb/drivers/ftdi_sio/unbind) manually with the correct device on the left.

[gregoireg]

Yes, I'm sure that v3.11 is the culprit. On the same system, I have both v3.10 and v3.11 installed. It works with v3.10. I do see that ttyUSB0 is removed, the udev rule works correctly. Yes, sometimes, udev rules are a pain but here it's working fine.

It seems that v3.11 wants "full access" to the FTDI chip and is not happy that another driver such as ftdi_sio is loaded. It would be great to have an official comment from Lattice about that.

[SiliconWizard]

This is odd. The unbinding should be enough to "release" the FTDI device and make it available to libusb.

Maybe Lattice added some stupid check about ftdi_sio being loaded even though the FTDI device is not held by it. This would be mind-bogglingly stupid, all the more that you may have other FTDI-based devices plugged at the same time, that you want to be used with ftdi_sio...

Maybe this is not Lattice's fault but FTDI's: maybe it comes from the Linux FTDI drivers that came updated in Diamond 3.11 (they are purely userland drivers since they use libusb, so they are probably part of Lattice Diamond's install...)

If you don't intend on using any other FTDI-based device than the programming cable at the same time, you could probably just add a 'rmmod ftdi_sio' after the unbind in the udev rule and call it a day...?
(Not ideal but it could work for you...)

[gregoireg]

That's exactly my problem. I'm using the ftdi driver for another application at the same time I'm flashing the Lattice chip. It's why I need a solution (doing rmmod / modprobe before/after flashing is painful and it seems to do bad things in my other application).

At least, if someone could confirm what I'm seeing that would be a first step. v3.11 has been released in June, so it's quite recent.

[SiliconWizard]

That's exactly my problem. I'm using the ftdi driver for another application at the same time I'm flashing the Lattice chip.

Yep, in that case...

Sorry I don't have time to fiddle with Diamond on Linux at the moment. I highly suspect it comes from FTDI's Linux "drivers" as said above though, that Diamond certainly uses on Linux. They may have updated them or something.

If it happens that FTDI drivers (or Diamond itself) just check that ftdi_sio is loaded regardless of which devices are bound to it, I think you're basically screwed if you need ftdi_sio for other devices at the same time. Don't really see any possible workaround outside of Diamond itself. Have you tried contacting Lattice's support? (I don't even know if you have access to that with free licenses, but I suspect not...)

Just a quick note for FTDI developers and ftdi_sio developers:
- FTDI: could  you please NOT check that ftdi_sio is loaded? Just try to get access to the device through libusb. If you can, no need to bother. If the device is held by ftdi_sio, I think you can't access it through libusb (at least that's my experience so far, may have changed recently?) Done.
- ftdi_sio: could please check that the detected FTDI devices are or ar not set with the D2XX drivers-only option (it's a configuration readable in their internal or external EEPROMs), such as what happens on Windows? In this case, any FTDI-based device that is set as loading D2XX drivers only would not be automatically bound to ftdi_sio, and there would be no need to unbind them with a udev rule. Using FT_PROG or similar, you could then set the appropriate option on your programming cable if it's not already done.

As it still is now, I find ftdi_sio extremely annoying when using FTDI devices on Linux.

[woofy]

modemmanager

On every new Linux install I do:
sudo apt-get purge modemmanager

It's a menace. If you don't need it, remove it.

[gregoireg]

@woofy, thanks but please don't pollute this thread. modemmanager can be a pain but this problem has absolutely nothing to do with modemmanager. It's a driver problem and how Lattice Diamond uses this. I even don't have modemmanager on my PC so it's not the problem.

[tolpe]

Hi,

this one worked for me:
https://section5.ch/index.php/2017/01/26/ecp5g-versa-board-under-linux/
You might not want to remove ftdi_sio when using a serial console to your board.

[gregoireg]

Thank you. It doesn't work for me on v3.11. Have you tried with Lattice Diamond v3.11? It can work on v3.10 and this is the standard way to unbind the ttyUSB0 but as I explained in my first post, this is not working any more since v3.11.

Is anyone seeing the same problem with Diamond v3.11 released in June 2019?

[gregoireg]

I have tried again and again just to make sure...

I see the following: if ftdi_sio is loaded in the kernel, when launching the programmer for the first time, no cable/port is detected. ftdi_sio needs to be unloaded.

After that, once you have reached the next screen to flash your board, you can re-inject the driver ftdi_sio, Diamond v3.11 doesn't seem to care.

Bottom line, I really believe that Lattice has added a check in v3.11 on ftdi_sio when the programmer is started...

[SiliconWizard]

Yup looks like it... as I checked again with Linux FTDI drivers alone, and the last version still works as before. So it's definitely strictly a new check in Diamond, probably in an attempt to work around the incompatibility with ftdi_sio (in a very dumb way).

I haven't fully migrated to Linux for all my dev needs, so I'm still using Diamond on Windows, but that's good to know. I have a JTAG probe based on FT2232H that has both a channel for JTAG and a channel for UART comm, so it would definitely not work with Diamond on Linux as is.

[gregoireg]

Thank you for checking!!! At least, I know that my nightmare is reality.

For me, the best trick is rmmod ftdio_sio before launching the programmer, modprobe ftdio_sio just after once it has launched and "found the cable" and do the usual 'unbind'.

[jaromir]

Sorry for resurrecting this older thread, but I noticed there is service pack for Diamond 3.11.
Release notes of this pack reads:

RedHat version 7.4 can’t open Programmer
This issue requires the user to update to a Linux driver from RedHat in order
to support version 7.4. This fix ensures that it is backward compatible with
previous versions of RedHat. Refer to the Lattice Diamond 3.11 Installation
Notice for Linux for RedHat instructions.
Versions affected: Diamond 3.11
Devices affected: All
CR129730

Since there is no other than RedHat Diamond version, perhaps it applies to Linux in general and not to this specific distribution. Issue description is somehow unclear, but I wonder if it has any relevance to this particular problem. Perhaps it's worth a try.

[ale500]

This diamond programmer is making me sad. I read the thread with a similar name
https://www.eevblog.com/forum/microcontrollers/lattice-diamond-is-making-me-sad/

To the SW:

CentOS 8 ( I should have installed 7.something!)
Diamond 3.11 with SP1.
libusb-0.15
I have a MachXO2 breakout board.

My 10-local.rules file:

Code: [Select]

SUBSYSTEM=="usb",ACTION=="add",ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6010",MODE=="0666",GROUP=="pacito:x:1000",SYMLINK+="ftdi-%n'
SUBSYSTEM=="usb", DRIVER=="usb", \
                  ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6010", \
                  MODE=="0666", RUN+="/bin/sh -c 'basename %p:1.0 > /sys/bus/usb/drivers/ftdi_sio/unbind'"


Permissions:

Code: [Select]

-rwxr-xr-x. 1 root root 1284 Dec 18 10:39 10-local.rules
-rw-r--r--. 1 root root  628 Jan  7  2019 70-persistent-ipoib.rules

It seems to work because I can see the ftdi_sio de-attaching from the first "port" (dmesg):

Code: [Select]

[ 6174.127678] usb 1-2: new high-speed USB device number 78 using xhci_hcd
[ 6174.337885] usb 1-2: New USB device found, idVendor=0403, idProduct=6010, bcdDevice= 7.00
[ 6174.337886] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6174.337888] usb 1-2: Product: Lattice FTUSB Interface Cable
[ 6174.337888] usb 1-2: Manufacturer: Lattice
[ 6174.358909] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[ 6174.358922] usb 1-2: Detected FT2232H
[ 6174.363935] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 6174.368901] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected
[ 6174.368911] usb 1-2: Detected FT2232H
[ 6174.373920] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1
[ 6174.380509] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 6174.380518] [color=red]ftdi_sio 1-2:1.0: device disconnected[/color]

lsusb shows:

Code: [Select]

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 051: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC
Bus 001 Device 002: ID 24ae:2010 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ony one FTDI chip plugged into the machine

The diamond programmer still says that it cannot find a ftdi cable

No messages on the console, no other info as to why.

Any ideas ? ... Ja, the boards I have work in windows, very well...

[ale500]

I installed Centos 7.7 and it behaves the same as Centos 8. (At least it has KDE instead of that dumbed down gnome. I'll try with Xfce when I get this working).
One issue I discovered is that the ftdi chip gets connected and disconnected every few seconds:

Code: [Select]

[ 8570.282602] usb 1-2: new high-speed USB device number 4 using xhci_hcd
[ 8570.489996] usb 1-2: New USB device found, idVendor=0403, idProduct=6010, bcdDevice= 7.00
[ 8570.490001] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 8570.490004] usb 1-2: Product: Lattice FTUSB Interface Cable
[ 8570.490007] usb 1-2: Manufacturer: Lattice
[ 8570.511040] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[ 8570.511079] usb 1-2: Detected FT2232H
[ 8570.516206] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 8570.521009] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected
[ 8570.521037] usb 1-2: Detected FT2232H
[ 8570.526051] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1
[ 8572.025119] usb 1-2: USB disconnect, device number 4
[ 8572.025509] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 8572.025522] ftdi_sio 1-2:1.0: device disconnected
[ 8572.025621] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[ 8572.025631] ftdi_sio 1-2:1.1: device disconnected
[ 8572.330722] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 8572.536540] usb 1-2: New USB device found, idVendor=0403, idProduct=6010, bcdDevice= 7.00
[ 8572.536545] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 8572.536548] usb 1-2: Product: Lattice FTUSB Interface Cable
[ 8572.536551] usb 1-2: Manufacturer: Lattice
[ 8572.557582] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[ 8572.557617] usb 1-2: Detected FT2232H
[ 8572.562618] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 8572.567549] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected
[ 8572.567577] usb 1-2: Detected FT2232H
[ 8572.572612] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB1
[ 8574.229698] usb 1-2: USB disconnect, device number 5
[ 8574.229928] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 8574.229941] ftdi_sio 1-2:1.0: device disconnected
[ 8574.230052] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[ 8574.230062] ftdi_sio 1-2:1.1: device disconnected



that is most probably the problem... but why ?

I decided to modify a bit the udev rule (the one in the previous post does the same) and now both serial interfaces are being unbounded, not that it brings anything

[ale500]

I found the problem !!

I had the breakout board connected to a USB 3.1 Gen 2 port. I tried a USB 2.0 port and the ftdi chip doesn't get re-enumerated every 10 seconds. unloading ftdi_sio and fixing the permissions manually made radiant's programmer find the device. I'll try in Centos 8 now.