Yesterday I installed ISE 14.1 from the DVD and after no success with getting the ZedBoard to work I downloaded ISE 14.2 and installed that. I had to fight a little to get everything running. To help others getting their installation working and to supply Xilinx with some bug reports, I'll post my experience here.
I'm working on Debian (sid, fully updated) on a 64 bit Intel Core-i7. So these problems mostly apply for this combination.
1) Mentor CodeSourcery
During the ISE installation, it also (silently) installs Mentor CodeSourcery to /opt/Xilinx/14.2/ISE_DS/EDK/gnu/arm/lin64, which contains GCC and GDB for the ARM architecture. Unfortunately, no errors are given to the user if problems occured during installation.
Their installer does not like "dash" as the default shell /bin/sh, but does not complain! When executing its installer by hand, they suggest to reconfigure the dash package to not be the default shell.
# dpkg-reconfigure -plow dash
and say [No] when asked to use dash for /bin/sh.
2) User Permissions
When starting PlanAhead for the first time after installation as a normal user (not root), a little window complains that it cannot write to /opt/Xilinx/14.2/ISE_DS/.xinstall/ Why should it write there?
PlanAhead don't like German locale due to a bug using ',' instead of '.' as decimal point when displaying schematics.
$ unset LANG
4) PlanAhead 100% CPU Usage
While XPS is running and PlanAhead waits for it to quit, PlanAhead requires 100% CPU. Interestingly enough, this only happens after the 2nd time XPS is executed (or so).
1) Why does PlanAhead need to be "locked" while XPS runs?
2) Why use 100% CPU?
5) PlanAhead VHDL Editor
When copy-pasting code, sometimes its common indentation is changed, but this doesn't fit to the surrounding blocks.
When saving a VHDL file, the whole window is disabled (grayed out) for 1-2 seconds (on a quite fast PC!). This seems to be the auto-update of hierarchy and stuff. Why does this lock the whole window? And why does this consume so much CPU?
6) Browser doesn't work when started from SDK
When clicking on links (e.g. in the system.mss file), the console where "xsdk" was started says:
epiphany-browser: /opt/Xilinx/14.2/ISE_DS/common/lib/lin64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/lib/libwebkitgtk-3.0.so.0)
epiphany-browser: /opt/Xilinx/14.2/ISE_DS/common/lib/lin64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/libwebkitgtk-3.0.so.0)
strace reveals, that clicking a link searches MIME->App. mappings (e.g. /home/hansi/.local/share/applications/mimeapps.list), which further finds /usr/share/applications/epiphany.desktop and (after some playing around with DBus) executes epiphany-browser, which is searched in $PATH.
Solution: Add a script /opt/Xilinx/14.2/ISE_DS/ISE/bin/lin64/epiphany-browser which unsets LD_LIBRARY_PATH before launching the browser.
# Execute Epiphany Browser with unset LD_LIBRARY_PATH
exec /usr/bin/epiphany-browser "$@"
The SDK build process requires "gmake":
$ ln -s /usr/bin/make /home/hansi/bin/gmake
8) JTAG via USB
The JTAG USB device doesn't allow a normal user (other than root) to access it. The FTDI FT232H enumerates as
0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
for which automatically the module "ftdi_sio" installs as ttyUSB0 serial driver.
The /etc/udev/rules.d/52-digilent-usb.rules matches to all devices with idVendor=1443 and 0403 and launches /usr/local/sbin/dftdrvdtch to detach the fdti_sio driver. Actually, it should also set the mode to "666", but /dev/bus/usb/001/034 is still only rw-rw-r-T.
The problem is that /lib/udev/rules.d/91-permissions.rules overrides the mode with "664".
Solution: Rename 52-digilent-usb.rules to 92-digilent-usb.rules.
9) The Digilent JTAG cable makes problems with XMD
The Xilinx Microprocessor Debugger (XMD) Engine makes a SIGSEGV. GDB showed that this happens in /usr/local/lib64/digilent/adept/libdpcomm.so.2 which is the Digilent Adept driver. The very same problem happens with iMPACT, for which I found the following forum discussion.
The suggested solution with LD_PRELOAD=libdpcomm.so.2 worked for me. Unfortunately, the SDK cannot be modified to do this, therefore we have to replace the original "xmd" executable by a script.
mv xmd xmd-xilinx
mv unwrapped/xmd unwrapped/xmd-xilinx
Create new file "xmd" with the content:
# Execute XMD with LD_PRELOAD
LD_PRELOAD=libdpcomm.so.2 /opt/Xilinx/14.2/ISE_DS/EDK/bin/lin64/xmd-xilinx "$@"
Then make it executable
chmod a+x xmd
I also installed the newest Adept 2.10.2 runtime from Digilent
which alone didn't solve the problem.
10) SDK Debugging hangs
Still, debugging with SDK didn't work. The startup window ("Launching Delegate" or similar) still kept hanging.
Some debugging revealed that XDM is executed as
xmd -nx -json -ipcport 2350
(i.e., no xmd.init, use JSON as protocol, and communicate via TCP port 2350). Using "tcpdump" I found the following conversation taking place:
xload hw /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/proc_module_hw_platform/system.xml
xconnect arm hw -debugdevice cpunr 1 devicenr 1
xdebugconfig 64 -reset_on_run processor enable
xdownload 64 /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/hello_world_0/Debug/hello_world_0.elf
xelf_verify 64 -random /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/hello_world_0/Debug/hello_world_0.elf
xsafemode 64 -elf /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/hello_world_0/Debug/hello_world_0.elf
xsafemode 64 on
where the last command issues a sigsegv. GDB says where this happens:
Program received signal SIGSEGV, Segmentation fault.
0x00000000004d44fb in CortexA9DebugManager::printExceptions(int) ()
#0 0x00000000004d44fb in CortexA9DebugManager::printExceptions(int) ()
#1 0x00000000004bd79f in tclSafeMode ()
When these commands are executed by hand, the following messages are displayed before the sigsegv:
WARNING: It is recommended that you load the Hardware Specification file at the begining of XMD session: e.g., xload hw system.xml.
WARNING: All enabled exceptions will be trapped. If you need more control over which exception to trap, set all exception handler at writable addresses with command 'safemode -config <ID> <Address>'
While this is clearly a bug in XMD, the solution was quite simple: I deactivated the Safe Mode which I've previously enabled in the Debug Configurations -> Debugger Options tab.
As shown above, XMD provides lots of "x*" commands which are not documented in "help". The special (secret?) command "xhelp" reveals a list of commands.
Secondly, the "xdownload" command used by SDK requires much more time than the (equivalent?) "dow" command to download the ELF file. GDB shows thousands of newly created threads which are destroyed immediately during the long delay of "xdownload".