Forum Discussion
New ContributorQuartus jtagd fails and unable to program MAX10 under Linux (18.1.0.625)
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 ?
21 Replies
JohnT_AlteraRegular Contributor
Hi, May I know which blaster that you are using? May I know if your blaster driver is updated?
TBarn2We 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_AlteraFrom 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
There is no "USB-Blaster" driver for Linux AFAIK. The jtagd program uses the stadard Linux kernel driver:
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
Frequent Contributor
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_AlteraHi, The driver for linux is part of Quartus installation. We have tested out without any issue. No source code will be provided
- TBarn2
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
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
Note systems are Fedora29 not Fedora27 as i stated in the above two items.
- JohnT_Alterai 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
