- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm attempting to find information on how to program my DE0-Nano through a ARM Linux machine. I have a small computer connected to the device and would like to reconfigure it without plugging it back into my main machine; either by storing multiple programming files or through scp. Sadly, I'm having a tough time finding any information to get me started.
Has anyone programmed through ARM and can point me in the right direction to find/build/configure the necessary drivers / tools to do so? Edit: I guess I should mention I was trying to find the byteblaster.tar.gz file mentioned in the ByteBlaster II Download Cable User Guide in order to attempt to build the driver on my system, but cannot seem to locate the package.- Tags:
- arm
- linux
- usb blaster
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is wrong with just programming the DE0-nano configuration device, and then just turning on the power?
Given that Quartus does not work under ARM Linux, you would need to create the configuration images on a different machine anyway, so why not just use that same machine to program the device? Lets assume that you do not want to unplug your ARM Linux machine and your DE0-nano ... 1. Use a Virtual Machine Run VirtualBox on the ARM Linux machine and run a Windows virtual machine, with Quartus or the programmer tool installed. You can attach the DE0-nano USB-Blaster to the virtual machine, and program it from there (I do this all the time when testing different versions of Quartus or OSes). 2. Use USB-over-IP http://usbip.sourceforge.net/ Run USB-over-IP on your ARM machine (server) and your Quartus machine (client), and the client will see the DE0-nano as a USB device which you can program (meaning that you can also use JTAG indirect programming to configure the EPCS device). I have successfully tested this with a PowerPC as the server, with a BeMicro-SDK board (which has a built-in USB-Blaster like the DE0-nano). Cheers, Dave- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the response, I'll look into a virtual machine and some script automation. The reason I do not want to use the main machine is because I want to store many different sof files on the host computer and have it decide which one to load for certain scenarios during run time without outside interaction. Much appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I'll look into a virtual machine and some script automation. The reason I do not want to use the main machine is because I want to store many different sof files on the host computer and have it decide which one to load for certain scenarios during run time without outside interaction. Much appreciated. --- Quote End --- Using a virtual machine would probably be the easiest path, in that you should be able to run a TCP/IP server inside the VM that your ARM Linux machine can communicate with, and have the VM download the various .SOF images. There are command-line tools that can load .SOF images, so a server based on Python or Tcl should be fairly simple to create. You could also directly control the USB-Blaster from your ARM Linux machine using libusb and libftdi. Unfortunately Altera do not publish the information on what is required to download an .sof image via JTAG, so that would require significantly more effort (in reverse engineering) than just running a VM. Note that one "wrinkle" with the VM under ARM Linux is that you'll need to find one that emulates an x86 so that Quartus thinks it is running natively. I'm not sure if VirtualBox does that, you might have to find a VM that emulates x86 well enough to boot x86 Linux, and then install Quartus in that. If that ends up being too painful, run USB-over-IP on the ARM Linux machine, and the .SOF server on some other x86 machine that also runs the USB-over-IP client. That x86 machine does not need to be your development machine. Cheers, Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Hello, I noticed a thread you created a while ago: http://www.alteraforum.com/forum/showthread.php?t=31509 matches one I created earlier this week: http://www.alteraforum.com/forum/showthread.php?t=42325 . I'm attempting to program through USB-Blaster II to a DE0-Nano device on an ARM Linux computer; did you find a good solutions? Thanks. --- Quote End --- Hi ASIC, Dave already describe your options very well! As he describe it for me in the past! When I still need to program with the USB-Blaster I use x86 machine with quartus. Otherwise I use JTAG with my specific setup. So for my setup it's working fine. Here what my setup is: Embedded ARM board with 4 GPIO connected to the Cyclone 4 JTAG lines (TCK,TMS,TDI,TDO). Using the Jamplayer 2.5: https://www.altera.com/download/legacy/jam/dnl-player.jsp Implement my own jam_jtag_io() function to do one clock for the JTAG something like: 1- Set clock to low (TCK) 2- Set TMS value 3- Set TDI value 4- // Should wait half period but I don't since my current implementation is really slow go max to 20Mhz 5- Read TDO 6- Set clock high (TCK) 7- // Should wait half period, I don't 8- Set clock to high (TCK) // This is to be sure to always finish at low Now to work with the jam player you need a .jam file: 1- Open Quartus and generate a .jic file in my case. 2- Convert .jic to .jam with "quartus_cpf -c file.jic file.jam" Then you need to copy the jamplayer and the .jam file on your ARM board and program the FPGA: 1- jamplayer -aconfigure file.jam // Wait for 25-30 minutes and success message. This depends of the size of your .jam file 2- jamplayer -aprogram file.jam // Wait for double the time of the configure and success message I always reset the FPGA with another gpio (NRESET) and 2 more to look at the FPGA status CONF_DONE and STATUS. Recommendation keep the length between the gpio and FPGA JTAG as short as possible. Hope it can help, -KA

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page