Quartus jtagd fails and unable to program MAX10 under Linux (18.1.0.625)

TBarn2 · ‎03-07-2019

I am having a problem programing MAX10 devices under Linux. It used to work fine but I think some software updates have changed things (kernels?). I am running Fedora29 (although I have the same issue on Redhat 7.5). I get the error:

"Error (209053): Unexpected error in JTAG server -- error code 35"

Strangely on a Thinkpad laptop, running the same Fedora29 it programs fine but on 5 different hardware systems it fails. (I have not managed to discern why this is the case) I have tried two different manufacturers programmers (Blaster compatible) both fail, different USB leads, different FPGA boards etc. If I use openocd to program it works fine but this is very slow. A quick look at the USB traffic suggests that jtagd is occassionaly sending garbage to the programmer.

It seems that there is an issue in jtagd, perhaps not matching the API's in later kernels. Is there a later version jtagd or is it available in source code form or any ideas ?

JohnT_Intel · ‎03-13-2019

Hi, May I know which blaster that you are using? May I know if your blaster driver is updated?

TBarn2 · ‎03-13-2019

We have used a Terasic USB Blaster and another vendors clone USB Blaster. These both work fine with the three different MAX10 boards we have via a particular Laptop running Linux and via openocd on all systems.

As we are using Linux there is no special USB Blaster driver, it will be using the generic Linux kernels USB driver provably via the libusb API library.

The jtagd program is statically linked so does not use system shared libraries for libusb (assuming it uses linusb). I suspect that is the issue in that the Linux kernels generic USB driver API has changed with updated kernels but the jtagd is using an older API that is not quite correct.

JohnT_Intel · ‎03-14-2019

From the information provided, it working with the blaster. I am not sure what is causing the issue with using generic USB driver. I would recommend you to use USB-Blaster driver

TBarn2 · ‎03-14-2019

There is no "USB-Blaster" driver for Linux AFAIK. The jtagd program uses the stadard Linux kernel driver:

https://www.intel.com/content/www/us/en/programmable/support/support-resources/download/drivers/dri-usb_b-lnx.html

Has anyone there tried the latest Quartus release on an up to date Redhat 7 Linux system ?

Is the source code for jtagd available so I can fix this issue ?

Abe · ‎03-15-2019

Have you tried unplugging the USB Blaster cable, killing the JTAG server task, then plugging in the cable and starting the JTAG server again with Admin privileges (sudo jtagd... ) ?

JohnT_Intel · ‎03-15-2019

Hi, The driver for linux is part of Quartus installation. We have tested out without any issue. No source code will be provided

TBarn2 · ‎03-15-2019

Yes, i have tried unplugging/plugging the USB Blater cable, putting it into different USB ports, different cables, different USB Blasters, different MAX10 boards, tried it from different user accounts (including root), on 4 different Linux systems (3 running Fedora27 and 1 running Redhat7), and tried running jtagd as root. This all fails apart from on one Lenovo thinkpad Laptop (running exactly the same Fedora27 and Quartus installation as far as I can tell) which works fine. The CPU types and speeds are different between these systems, the only thing I can think of which is different.

Note we were able to program fine until about November/December 2018 when it stopped working. As stated we can program fine with openocd (using the same USB Blaster) on all of the systems, but it is slow.

JohnT the "real" driver must be the standard Linux generic USB driver, jtagd will "probably" use a user level API layer like libusb to communicate with the Linux driver. There is no driver for Linux in the Quartuis distribution as far as i am aware, or is there one we can use ?

I have had some progress, but still don't know what is happening. On the laptop running Fedora27 where programing works I have three users setup: root ,terry, test. The programming only works for the user "terry". Now it gets really strange.

If I manually start the jtagd program as the user root with the command: "jtagd --user-start --config /homel/terry/.jtagd.conf" programming works.

If I manually start the jtagd program as the user root with the command: "jtagd --user-start --config /root/.jtagd.conf" programming fails. The ".jtagd.conf" file does not exists in all cases.

If I manually start the jtagd program as the user terry with the command: "jtagd --user-start --config /homel/terry/tmp/.jtagd.conf" programming works (the directory /homel/terry/tmp exists).

If I manually start the jtagd program as the user terry with the command: "jtagd --user-start --config /tmp/.jtagd.conf" programming fails.

Now even stranger as the test user with a home directory of /homel/test "jtagd --user-start --config /homel/test/.jtagd.conf" programming fails.

Using "jtagd --user-start --config /homel/test-55/.jtagd" (/homel/test-55 does not exists) programming is fine.

Using "jtagd --user-start --config /tmp/.jtagd.conf" programming fails.

If I create an empty .jtagd.conf file it does not affect things.

Something really strange is going on here with jtagd ... Any ideas ?

TBarn2 · ‎03-15-2019

Also running "jtagd --user-start --config hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh" works !

but "jtagd --user-start --config hhhhhhhhhh" fails.

It appears that the argument to --config has to exceed a certain number of characters.

It seems sure there is a bug, possibly a memory pointer bug in jtagd to me, or any ideas ?

TBarn2 · ‎03-15-2019

Note systems are Fedora29 not Fedora27 as i stated in the above two items.

JohnT_Intel · ‎03-18-2019

i am sorry to tell you that we do not support issue related Fedora OS. We only supported OS that has been validated. Please refer to https://www.intel.com/content/www/us/en/programmable/support/support-resources/download/os-support.html for supported OS

TBarn2 · ‎03-18-2019

Yes, I understand that, but as previously stated this also fails when running on an up to date Redhat 7.5 which is one of the listed systems you support.

JohnT_Intel · ‎03-18-2019

Have you tried to use the driver provided part of Quartus installation?

TBarn2 · ‎03-18-2019

JohnT as stated above: the "real" driver must be the standard Linux generic USB driver, jtagd will "probably" use a user level API layer like libusb to communicate with the Linux driver. There is no driver for Linux in the Quartuis distribution as far as i am aware, or is there one we can use ? I have configured udev to allow access to this driver for the vendor/product USB ID's as per the Intel installation instructions. Linux provides a generic USB driver used for applications like this, it is not Microsoft Windows.

Given my further debugging of the issue in the Intel jtagd program, as listed above, it appears it is more of a general internal memory pointer bug in jtagd not related to the USB driver but possibly due to underlying system updates. It would have taken me 10 minutes to find this bug in the jagd source code!

JohnT_Intel · ‎03-18-2019

Hi, You may refer to https://www.intel.com/content/www/us/en/programmable/support/support-resources/download/drivers/dri-usb_b-lnx.html.

TBarn2 · ‎03-18-2019

Yes, I have. That is the configuration for udev, that as stated above, allows access to the Linux kernels in-built generic USB driver for the vendor/product USB ID's of the USB Blaster device for any user on the system. There is NO Quartus driver for Linux.

JohnT_Intel · ‎03-18-2019

May I know if you have install Quartus or Quartus Programmer into your system? If yes, you should be able to find the driver under "<installation folder>/quartus/drivers/wdrvr/"

TBarn2 · ‎03-18-2019

Yes I have the Quartus software installed and yes that directory exists. that looks like the API library that communicates with the Linux generic USB device driver in the Linux kernel. I note that there appears to be sufficient source code in there to rebuild the API library or a particular Linux kernel version. I can try manually rebuilding that for our systems to see if that fixes the issue.

TBarn2 · ‎03-18-2019

Ok, some more information. Ok, there is a kernel driver and API library in that directory although this does not appear to be used. The driver would only build for up to 2.6.x kernels which are very very old (~2005 !). Our Fedora systems use the 4.20.14 and RedHat 7.5 3.10.0. That directory seems like a historical driver for very very old legacy systems. As stated earlier i strongly suspect that jtagd uses the libusb/generic Linux USB driver.

But again, as stated above, "Given my further debugging of the issue in the Intel jtagd program, as listed above, it appears it is more of a general internal memory pointer bug in jtagd not related to the USB driver but possibly due to underlying system updates. It would have taken me 10 minutes to find this bug in the jagd source code!"

JohnT_Intel · ‎03-19-2019

May I know which Quartus version are you using?

TBarn2 · ‎03-19-2019

18.1.0.625. I have quite a bit of work to get through ATM and I have a workaround ( running "jtagd --user-start --config hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh" works !) so I will have another look at this in a couple of weeks.