Arch Linux

TheColonel

Member

Registered: 2017-01-31

Posts: 10

[SOLVED] USB JTAG Programmer Device Failures

I'm having difficulties getting an Altera USB blaster to work with an Arch linux system.  I've spent the last few days trying to get to the bottom of it but I haven't found any solutions. 

A few key things:

• I have essentially 3 test systems: A physical box running Arch, and on that box: a VM running Arch and a VM running Fedora 28 with kernel 4.18.4 (also tested with Fedora 4.17.11 kernel).  VMs are hosted with VirtualBox. All systems are fully up to date as of this post.

• The device does not work when attempting to use it from Arch natively

• Using VirtualBox, the device and software works when forwarded to the Fedora VM

  • This is only true if the VM's USB controller is in 2.0 or 1.0 mode - if in 3.0 mode, it will fail in much the same way as it does in Arch.

  • I thought this might have been due to ohci_pci vs xhci_pci drivers, but using a 2.0 controller with the physical machine, arch will use ohci_pci drivers as seen in dmesg and still fail (whereas if plugged into a 3.0 port, xhci will handle it and also fail).

• Device does not work when forwarded to a VM running the same version of Arch as the hardware with VirtualBox USB mode set to 2.0

• Also does not work if running the Arch system with Fedora kernel on the Arch VM or Arch Physical Machine

• Arch-Zen and Arch LTS kernels have also been tried with no success.

• The device is detected and enumerated correctly in all test systems - eg it will show up correctly in the output of lsusb with id 09fb:6001

• udev rules have been set up identically on all test systems, and permissions are identical (0666) in the /dev fs for the device

• The programming software is the same between all systems - intel quartus 17.1 - and it does not report any helpful errors.  No errors show up in dmesg

• I have used wireshark to capture both a successful and a failed usage of the device.  I don't speak USB, but it looks like in the failed mode it will go into an infinite loop of USB_BULK_IN messages between the host and enpoint (both directions alternating) and eventually time out.

• I've tried both disabling and enabling EHCI forwarding in the machine's BIOS with no difference in behavior

I'm not sure where to go from here in terms of troubleshooting this, but any suggestions are appreciated.  I'm guessing it is something specific to Arch, given that with all other things equal, the Fedora VM does not fail where the Arch VM does.

Last edited by TheColonel (2018-08-27 19:03:18)

ewaller

Administrator

From: Pasadena, CA

Registered: 2009-07-13

Posts: 20,648

Re: [SOLVED] USB JTAG Programmer Device Failures

Can you post what gets added to the journal when you attach the programmer?   I do not think that device initially shows up as a mass storage device, but lets check....

---

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way

TheColonel

Member

Registered: 2017-01-31

Posts: 10

Re: [SOLVED] USB JTAG Programmer Device Failures

Sure thing.  This is all I get after plugging it in:

[16021.202171] usb 9-2: new full-speed USB device number 3 using ohci-pci
[16021.437436] usb 9-2: New USB device found, idVendor=09fb, idProduct=6001, bcdDevice= 4.00
[16021.437440] usb 9-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[16021.437443] usb 9-2: Product: USB-Blaster
[16021.437445] usb 9-2: Manufacturer: Altera
[16021.437448] usb 9-2: SerialNumber: 91d28408

ewaller

Administrator

From: Pasadena, CA

Registered: 2009-07-13

Posts: 20,648

Re: [SOLVED] USB JTAG Programmer Device Failures

Yeah, it is not showing up as a mass storage device.  That is good.  Some devices do that to provide a mechanism to ship Window drivers on the device and have them auto install.  There is a tool available to change the mode of devices that behave this way --but it is not relevant here.

Next, I would compare the outputs of lsmod for Arch (with the programmer attached) and for Fedora in the VM (with the programmer 'attached').  There are several Altera items in my arch kernel configuration that are flagged as modules; perhaps they need to be loaded.  You can see these with gzcat /proc/config.gz | grep ALTERA.  There may be other modules that are disabled that won't show up and could need to be built.  See what relevant kernel modules might exist in Fedora (where it works) vs Arch.

Edit:  For example, I am thinking the module altera_jtaguart  since, I believe, that part uses a FTDI like USB to asynchronous serial converter, and it uses JTAG to talk to the FPGA.
Edit 2:  Okay, it really looks like something that appears to be a USB to serial interface, but actually has parallel outputs that drive a second chip that drives the JTAG.  My suspicion remains, you are going to need to load a module -- and that module may, or may not already exist in the standard Arch kernel.

Last edited by ewaller (2018-08-22 21:19:24)

---

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way

TheColonel

Member

Registered: 2017-01-31

Posts: 10

Re: [SOLVED] USB JTAG Programmer Device Failures

Hmm, I don't see any relevant-looking modules loaded in the Fedora system.  None get loaded when the programmer is attached to the VM - and looking through the Fedora kernel config I see some of the config options that match altera are disabled.  Those that are enabled in Fedora are also enabled in Arch, and Arch even has some that Fedora doesn't.  Between the two VMs, it seems Arch's lsmod is a superset of Fedora's.  Fedora has a lot more built-in options than Arch does though, so the lsmod output may not tell all.

I also checked through the actual journalctl log (not dmesg) and found altera's jtagd left a few messages.  Nothing noteworthy, but I wasn't really aware of any of the command-line tools available in the quartus install directory - specifically jtagd and jtagconfigure.  I don't have physical access to the hardware (the target board needs a power switch flipped) until tomorrow.  I may try looking through strace output of jtagconfigure from both sides and seeing if anything pops out.

ewaller

Administrator

From: Pasadena, CA

Registered: 2009-07-13

Posts: 20,648

Re: [SOLVED] USB JTAG Programmer Device Failures

I'm running out of ideas here.  I have one at work, but it is on a Windows box; I could drag my Linux Laptop into the lab and see what it does.  First chance to try that is about 12 hours in the future..

Edit:  No I don't -- that system uses a Xilinx FPGA; I don't think we have an Altera development system in the lab.

Last edited by ewaller (2018-08-23 01:57:09)

---

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way

TheColonel

Member

Registered: 2017-01-31

Posts: 10

Re: [SOLVED] USB JTAG Programmer Device Failures

No worries - I appreciate the effort in any case.  I honestly didn't expect any outright answers.
I've made a bit of progress since yesterday.

If I start the jtagd server like so in either of the Arch systems before running Quartus, I can use the programmer software:

intelFPGA_lite/17.1/quartus/bin$ ./jtagd --user-start --foreground

Starting it without the foreground option will cause a failure.  Maybe there's some bug in jtagd or some subtle difference in USB handling between the Fedora and Arch kernels.

I'm leaning towards 'subtle USB handling difference' because I have a similar issue with another proprietary hardware programmer, also USB driven - it works in the Fedora VM but not Arch.  Both devices seem to work initially - the devices are present and will communicate basic descriptor info, but fail when USB bulk transfers are attempted.  In the case of the other device, it will actually partially program things and report a USB disconnect after a few seconds.

I'm tempted to leave it at this for now and just leave jtagd in a detached screen session for when I need it.  I'm also tempted to keep digging, but at some point I have to get actual work done

Edit: I was able to get things in Quartus land to function basically normally by editing the jtagd launch script at ~/intelFPGA_lite/17.1/quartus/bin/jtagd - basically just adding the --foreground option, and running it in the background.  This is the final line of the script:

#Old: eval exec "$CMD_NAME $cmd_line"
eval exec "$CMD_NAME $cmd_line --foreground &"

Edit2: Reread the wiki and installing libudev0-shim fixed the issue, so I can run with the unmodified script.  I didn't think it was relevant before because the wiki only mentions the lib32 version of the package.  This also seems to have fixed the issue with the other proprietary programmer I've been having difficulties with (for GoPro compatible firmware).

Last edited by TheColonel (2018-08-27 19:05:03)