Lattice Diamond is making me sad

[Tainer]

OK, so I had to install diamond on linux recently and had to spend a good evening to get it up and running. I've seen other posts of people struggling with it so I decided to write a small guide on this topic, since none of the instructions worked for me. In my case I'm using XO3 board, diamond 3.7 on debian.

• Step 1: getting diamond + license

You have to register on their website to obtain the license. That might require a dozen of fake email addresses, since their stupid authentication system is living it's own life. When you fill in your "company" don't write "Unaffiliated" as suggested on the website - that will most likely result in unactivated account and you will keep getting "page not found" errors. To obtain a license you need to fill in your MAC address - I usually generate a random address and spoof it when I need to. Also, you have to renew the license every 6 months. Honestly, that's just a pain in the ass which is why I've been looking towards other vendors for quite a while.

• Step 2: installing diamond

In case your distribution doesn't support rpm-packages you can still install it without any problems. However, don't use alien on debian and it's derivatives - you'll waste lots of time and it won't work properly. Simply unpack the rpm package (put it in ~/local/diamond for example) and then unpack .tar archives in each subfolder (./bin/bin.tar, ./cae_library/cae_library.tar, etc). Now you should be able to run ./bin/lin64/diamond. If it complains about missing libraries then install those separately.

• Step 3: installing the license

MAC address in the license file has to match the address of eth0 interface. To spoof MAC-address run:

Code: [Select]

# ip link set dev eth0 down
# ip link set dev eth0 address XX:XX:XX:XX:XX:XX
I do that on every machine where I use diamond. Great idea, Lattice. Thanks for making my life so much easier.

• Step 4: getting the programmer to work

At this point if you attach the programmer and run diamond, it will crash with a segfault and complain about usb write permissions. To get the programmer working we need to set the appropriate permissions and also unbind the ftdi_sio driver. However, in my case XO3 board has a FT2232H chip which provides a dual interface. If you look at dmesg output you should see something like

[71334.912360] usb 8-2: Product: Lattice XO3L Starter Kit
[71334.912363] usb 8-2: Manufacturer: Lattice
[71334.915149] ftdi_sio 8-2:1.0: FTDI USB Serial Device converter detected
...
[71334.918138] ftdi_sio 8-2:1.1: FTDI USB Serial Device converter detected

If you try to unbind ftdi_sio from device 8-2 it will not work - you have to specify device 8-2:1.0. In this case we only need to unbind the first interface, since it's used for programming.
Here is a complete udev rule:

Code: [Select]

# Lattice FTDI programmer
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'"
Place it under /etc/udev/rules.d/49-lattice.rules and run udevadm trigger afterwards.
If everything works properly, you should have similar dmesg output after attaching the board:

[71334.915526] usb 8-2: FTDI USB Serial Device converter now attached to ttyUSB0
[71334.918138] ftdi_sio 8-2:1.1: FTDI USB Serial Device converter detected
...
[71334.927683] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[71334.927699] ftdi_sio 8-2:1.0: device disconnected

[Brane212]

Couple more remarks about Diamond:

1. Check file owners. When you find and untar all those tarwhatevers, you'l find they have undefined owners and possibly permissions.
This can causevarious problems later, during usage, when programs call each other.

2. Same problem with libraries. Depending on your distro, it might happen that Diamond needs library that you don't have or that has wrong version and/or missing feature.
You can see that it has some libraries (libQtsomething ) but this just burries basic problem one level deeper- those libraries then just depend on some other libs on your system.
I usually copy libQtxxx from my system folder into Diamond/libs and if needed, I compile them specially for this purpose. There muste be other solutions, but I never bothered.

3. network card name. For some reason, Diamond checks JUST interfaces named ethX. If you have on your system NIC that either gets kernel's basic name like enp0sx or udev renames it to something like lan or wlan, you are f**ed. You have to correct change it to ethX.

4. As said before, at least for the time being, you have to remove or deactivate ftd_sio kernel module ( or compile kernel without it, if its built-in), if you plan to use FTDI-based programmers that are onboard.

[humbug11]

I managed to get Diamond working on Linux, thanks for the tips!

However, for some reason it is almost an order of magnitude slower than on Windows. I'm using the "pgrcmd" to program devices from the command line using an xcf file created with Diamond. On Windows, CRAM program & verify takes less than 10s whereas on Linux it is more than one minute! Does anyone know if there is a way to make this faster? I need to program the NVCRAM of a few hundred devices and waiting 1 minute isn't really practical. All our work is on Linux, so it would be annoying to need a Windows PC just for this step.

[Tainer]

Diamond is indeed slower under linux. Programming doesn't take that long for me, however the programmer takes about 10 seconds before it starts doing anything (I use the GUI thing from within diamond).
I think your best option is to follow Mike's advice and use ISPVM software.
Latest version for linux is 17.9, although 18.1 runs ok under wine.

Code: [Select]

http://files.latticesemi.com/ispVM/ispVMSystemV18.1.1.zip
http://files.latticesemi.com/ispVM/ispvm_v17_9_linux.tar.gz
Both versions did not support XO3, however you can add missing database files (Database/xpga/xo3) from diamond programmer.
This is as far as I got with ISPVM, since for some reason it refused to detect FTDI cable. I might give it another shot and revisit this post later.

[janoc]

Yep, I struggled with this for a long time.  There are several things you need to do:

1. Dig out the online help that talks about Linux installation. There's some useful stuff there.
2. Download the latest FTDI drivers, something like libftd2xx1.1.12.tar.gz, and install.
3. Make sure you rmmod ftdi_sio, so you don't pick up the standard driver.
4. Upgrade to Diamond 3.1 to avoid the problem where it fails to program after a few goes.

Once I sorted out the above, it all just worked.

Rolfe

HOORAY! Once I removed the ftdi_sio driver, it worked!    My friend, I owe you a beer.

Actually, you don't have to remove the driver - which will also prevent any other FTDI adapters from working.

Just detach it like this (modify for your device, of course):
https://lwn.net/Articles/143397/

That can be automated by a small script. There is even a ready made utility for this somewhere on Github.

[corecode]

I just installed Lattice Diamond 3.9 on Archlinux, and I kept getting crashes *after* doing the whole udev dance.

Turns out that their libftcjtag (which seems to be a libusb derivative) has a bug in their EventDestroy() function which leads to a segfault in libpthread's __lll_unlock_elision.  The bug is a double pthread_mutex_unlock(), which leads to a segfault on modern Intel processors which support the xstart/xend transactional memory instructions.

All Event*() functions leave the mutex unlocked upon exit, yet EventDestroy() calls pthread_mutex_unlock():


0000000000023c8b <EventDestroy@@Base>:
   23c8b:       55                      push   %rbp
   23c8c:       48 89 e5                mov    %rsp,%rbp
   23c8f:       48 83 ec 10             sub    $0x10,%rsp
   23c93:       48 89 7d f8             mov    %rdi,-0x8(%rbp)
   23c97:       48 8b 45 f8             mov    -0x8(%rbp),%rax
   23c9b:       48 89 c7                mov    %rax,%rdi
   23c9e:       e8 ad d7 fe ff          callq  11450 <pthread_mutex_unlock@plt>
   23ca3:       48 8b 45 f8             mov    -0x8(%rbp),%rax
   23ca7:       48 83 c0 28             add    $0x28,%rax
   23cab:       48 89 c7                mov    %rax,%rdi
   23cae:       e8 fd bc fe ff          callq  f9b0 <pthread_cond_destroy@plt>
   23cb3:       48 8b 45 f8             mov    -0x8(%rbp),%rax
   23cb7:       48 89 c7                mov    %rax,%rdi
   23cba:       e8 61 d6 fe ff          callq  11320 <pthread_mutex_destroy@plt>
   23cbf:       c9                      leaveq
   23cc0:       c3                      retq   


together with:

http://repo.or.cz/glibc.git/blob/HEAD:/sysdeps/unix/sysv/linux/x86/elision-unlock.c:

  23 int
  24 __lll_unlock_elision(int *lock, int private)
  25 {
  26   /* When the lock was free we're in a transaction.
  27      When you crash here you unlocked a free lock.  */
  28   if (*lock == 0)
  29     _xend();
  30   else
  31     lll_unlock ((*lock), private);
  32   return 0;
  33 }

does exactly what the comment says

zsh: segmentation fault (core dumped) /usr/local/diamond/3.9_x64/bin/lin64/diamond

#0  0x00007ffff620c6c0 in __lll_unlock_elision () from /usr/lib/libpthread.so.0
#1  0x00007fffd1cb5ca3 in EventDestroy () from /usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so.1
#2  0x00007fffd1cb00f2 in FT_Close () from /usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so.1

Fix:

Using the offset of the call to pthread_mutex_unlock() identified in the objdump of EventDestroy():

printf "\x90\x90\x90\x90\x90"| sudo dd of=/usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so bs=1 seek=$((0x23c9e)) conv=notrunc

Win!

Edit: turns out that you also need to either patch the same bug out of cableservermain, or you just nuke it alltogether:

ln -fs $(which false) /usr/local/diamond/3.9_x64/bin/lin64/cableserver

[janoc]

Using the offset of the call to pthread_mutex_unlock() identified in the objdump of EventDestroy():

printf "\x90\x90\x90\x90\x90"| sudo dd of=/usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so bs=1 seek=$((0x23c9e)) conv=notrunc

Win!

That's a pretty hardcore method of patching binaries 

I think I will stick with my hex editor.