Container segfault when attempting to program

[jackm]

After starting up the container, opening an existing Diamond project, and then going to Tools > Programmer, the main container process (i.e. the Diamond IDE) exits due to a segfault. For the physical programmer, I am using a Lattice HW-USBN-2B programmer cable. Note that I also manually named the docker container and prevented it from being deleted after exiting.

Checking the container logs I see this:

user@host:~/docker-fpga/lattice-diamond$ docker logs diamond-3.11-sp1
libusb couldn't open USB device /dev/bus/usb/002/006: Permission denied.
libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/002/006: Permission denied.
libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/002/006: Permission denied.
libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/002/006: Permission denied.
libusb requires write access to USB device nodes.
libusb couldn't open USB device /dev/bus/usb/002/006: Permission denied.
libusb requires write access to USB device nodes.
/opt/docker-fpga/run.sh: line 5:     9 Segmentation fault      (core dumped) diamond

Indeed, the USB device file is only writable by root:

user@host:~$ ls -l /dev/bus/usb/002/006
crw-rw-r-- 1 root root 189, 133 Dec 20 12:12 /dev/bus/usb/002/006

Is this expected? The user I am running the container under is a member of the "docker" group so it is able to run docker commands however it is not running as the root user of the host so the permission problems are to be expected if it is trying to write to /dev/bus/usb/002/006. I also tried using sudo docker start diamond-3.11-sp1 to re-start the existing container as root but I still got the same permission problems followed by a segfault.

What is the proper solution here? Perhaps a udev rule is needed for the programmer?

[Gekkio]

Personally I use a Bus Blaster v4, and I think I saw some Lattice software crashes before fixing udev permissions and mount /dev/bus/usb (now done automatically by run.sh script of this repository). Using sudo doesn't work, because you're just running docker as root but the container still runs with your own user credentials.

Try something like:

/etc/udev/rules.d/99_lattice.rules:

ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0664", GROUP="plugdev"

Adjust idVendor/idProduct based on what HW-USBN-2B uses, and make sure you are in the plugdev group (if necessary, run sudo adduser yourusername plugdev + log out + log back in).

[jackm]

Having udev add the device to a group that the host user is a member of (plugdev, in this example) did not work - Diamond IDE still segfaults and closes immediately when you open the programmer window and it attempts to write to the USB device.

I manually checked and the device was indeed part of the plugdev group with write permissions yet Diamond still didn't like it even though the docker container was running with the same permissions as the host user (-u argument). I had to give it world-writable permissions (i.e. MODE="0666") before diamond would stop complaining about USB device write permissions.

I also had to unbind the second serial interface from the FTDI SIO driver before Diamond could detect the programmer cable. I noticed that in dmesg that Diamond was trying to attach to the first and the second serial interface of the programmer cable, so I decided to unbind both from the FTDI SIO driver just for good measure.

Here is the udev rule that ended up working for me:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0666", SYMLINK+="ftdi-%n", RUN+="/bin/sh -c 'basename %p:1.0 > /sys/bus/usb/drivers/ftdi_sio/unbind; basename %p:1.1 > /sys/bus/usb/drivers/ftdi_sio/unbind'"

Note that the SYMLINK directive is not necessary and can be omitted.