Linux on the Arty, Part 0: Establishing a build environment

I have long wanted to explore the endless possibilities of soft core CPUs like the Xilinx Microblaze. A few months back, I stumbled across the announcement of the Arty by Digilent/Avnet/Xilinx – an affordable evaluation/development board clearly built for makers and perfect for getting my feet wet with a few Microblaze-based projects.


I initially wanted to get GNU/Linux up and running on a Microblaze CPU on the Arty to establish a familiar software environment for further tinkering. This proved to be quite a task in itself – a task which required reading through lots of product guides, manuals, blog posts and howtos online. Lots of documentation has been written on the Microblaze subject, but none of it was quite to the point or simple for me to follow.

In the following series of blog posts I will describe my way of accomplishing this goal; Linux on the Arty, with all on-board peripherals up and running and exposed to userland.

In the first posts, post 0, we will establish a build environment for both the hardware and the software. Later posts will span from establishing a bare-minimal, Linux-ready hardware design to getting each on-board peripheral of the Arty included in the hardware design, supported by the Linux kernel and exposed to the GNU/Linux userland.

My main development environment is a Macbook running OS X. I constantly use VMware Fusion for running various other (typically either FreeBSD or GNU/Linux) virtual machines to fulfill my needs for other development platforms. For developing the hardware and building the software for the Arty, I have installed CentOS 7 in a VM. I then use ssh to establish a local connection from OS X to the CentOS VM and forward the X display to OS X, thus allowing my to see e.g. the Xilinx Vivado windows on my OS X desktop through XQuartz.

You could of course use any PC capable of running Xilinx Vivado for the hardware part, but note that you will need a GNU/Linux host for building the Linux kernel and GNU/Linux userland. We will be focusing on Vivado 2015.4 and buildroot 2016.02 for this blog series.

If you plan on using a virtual CentOS 7 for the build environment, as I do, I recommend going with at least 50 GB HDD. The Xilinx Vivado installation itself will take up at least 20 GB and the hardware/software projects will take up another 5 GB. You will need a few packages and customizations on top of the Minimal 64 Bit installation image. Also, make sure you create an administrator user account during the installation.


First off, almost all CentOS command-line tools will complain about missing locale settings. Fix this by logging in and setting the locale to e.g. U.S. English with UTF-8 encoding by issuing the following command:
sudo localectl set-locale LANG=en_US.utf-8
Remember to log out and back in for the locale settings to take effect.

Next up, install and start the Open VM Tools (skip this if not running under VMware):
sudo yum -y install open-vm-tools
sudo systemctl enable vmtoolsd
sudo systemctl start vmtoolsd

Before we install the Xilinx Vivado suite, we will need to install a few dependencies and tools:
sudo yum -y update
sudo yum -y groupinstall 'Development Tools'
sudo yum -y groupinstall 'X Window System'
sudo yum -y groupinstall Fonts
sudo yum -y install glibc.i686 libstdc++.i686 fontconfig.i686 libXext.i686 libXrender.i686 glib2.i686 libpng12.i686 libSM.i686
sudo yum -y install evince wget ncurses-devel bc screen
sudo reboot

The *.i686 packages are needed by the Xilinx Vivado Documentation Navigator, which for some reason is still shipped as a 32 bit binary. Evince is a PDF viewer, which we will be using from within the Documentation Navigator.

Download the Vivado HLx Web Install Client for Linux and install it using the following commands:
sudo mkdir /opt/Xilinx
sudo chown $USER:$USER /opt/Xilinx
chmod +x Xilinx_Vivado_SDK_2015.4_1118_2_Lin64.bin

If you get an error about no X11 DISPLAY variable being set, make sure you’re logged on to the CentOS host using ssh -Y .... The -Y option will enable trusted X11 display forwarding.

Make sure to enable installation of the Software Development Kit, as this will be needed later on. You propably already aquired a license for Xilinx Vivado using the voucher included with the Arty, so you can skip acquiring a licence during the installation.


The Xilinx Platform Cable USB Driver/Digilent JTAG Driver are a separate install requiring root access. Install them using the following command:
cd /opt/Xilinx/Vivado/2015.4/data/xicom/cable_drivers/lin64/install_script/install_drivers
sudo ./install_drivers

We also need to make sure that our user account has access to the USB JTAG and serial port devices exposed by the Arty. These will be owned by the dialout group, so add our user to that group:
sudo usermod -G wheel,dialout $USER

To be able to launch the various Xilinx Vivado tools, we also need to set up our shell accordingly.
echo 'source /opt/Xilinx/Vivado/2015.4/' >> ~/.bashrc
source /opt/Xilinx/Vivado/2015.4/

Finally, install the license for Xilinx Vivado obtained by using the voucher included with the Arty:
mkdir -p ~/.Xilinx
mv Xilinx.lic ~/.Xilinx/Xilinx.lic

Finally, launch docnav, open the Settings Dialog and change the PDF Viewer Path to evince.


This concludes the first part of this blog series. The next part will describe how to do the basic, Linux-ready hardware design.

Cheap RepRap Cable Guide

I’ve come up with a cheap and easy cable guide hack for use with RepRap 3D printers. The trick is to wrap the electrical wires in sleeving along with a piece of piano wire. I’ve used 0.8 mm piano wire, but anything between 0.5 mm and 1 mm will likely work fine.

The photo below shows a close-up of the wrapped electrical wires and piano wire powering the heated bed of my RepRap Prusa Mendel i2.

As you can see in the following photo, the piano wire keeps the cable arranged in a nice arc at all times, thus making sure it will never touch the heated bed or get in the way of its movement.

The top end of the cable harness is secured to the threaded rod using cable ties. The end near the heated bed is secured using a self adhesive cable tie mount as shown below.

RepRap Thermal Imaging

Ever since I wired up the heated build plate and extruder hot end to my RepRap, I’ve wanted to verify the thermal temperatures and heat distribution. For starters, I have used a cheap infrared thermometer, which is fine for verifying the temperatures, but not very well suited for verifying heat distribution.

Last week, I got my hands on a Fluke Ti25 Thermal Imager – perfect for getting a good look at the heat distribution!

My heat bed is a sandwich with Josef Prusa’s PCB heat bed on the bottom and a 4 mm glass plate covered in kapton on the top. My thermistor for sensing the temperature of the heat bed is taped to the bottom side of the PCB. As shown by the image below, the glass plate does a good job of evening out the heat from the PCB.

Prusa PCB Heat Bed

However, I was surprised to see how much the temperature of the kapton-covered glass surface lacks behind the temperature on the bottom side of the PCB (which, incidentally, is where my thermistor is placed). On the image above, the top is 85.8 C while the heat reflection by the bottom alu plate reads 92.8 C – nearly the same temperature sensed by my thermistor at that time. The top glass surface catches up to the bottom temperure eventually, but it takes as long as 5 minutes for it to become stable. This explains why some of my prints have had a hard time sticking to the heated build plate – it simply wasn’t warm enough, when I started the print.

J-Head MkII Nozzle

The image above is of my extruders hot end, a 0.5 mm J-head MkII (or should that be 0.4572 mm?). Again, I was quite surprised by the thermal imaging – the heater resistor goes as high as 302.3 C when heating the nozzle to 200 C! That’s quite a lot more than I would have expected – good thing I’ve used cement that can withstand 1100 C for gluing in the thermistor and resistor.


Finally, the image above is of my RAMPS 1.4, which has small EnzoTech MOS-C1 heatsinks mounted on all the Allegro A4988 stepper drivers. Notice how cool the heatsinks are – and notice how hot the PCB gets. Good thing those heatsinks were cheap…

My RepRap Prusa – Iteration 2

In August last year, I was swept away by the idea of the Open Source/Open Hardware Replicating Rapid Prototyper, or RepRap for short. The RepRap project is a community effort to create a 3D printer capable of self-replication.

I first encountered the idea behind the RepRap at our friends at Labitat and shortly thereafter began self-sourcing the materials needed to build a Prusa Mendel v1, which – at that time – was state of the art within the RepRap community.

During the Fall and Winter, I managed to complete my Prusa Mendel build, and shortly before Christmas I had my first working 3D print!

For more photos of some of the items, I have printed on this machine, visit my Thingiverse page…

I have since then begun updating my RepRap to the Prusa Mendel Iteration 2 design, based on linear LM8UU bearings. The conversion is 66% done (X- and Y-axis are done, Z-axis still using printed PLA-bushings).

Stay tuned for posts with the small hints and tips, I have picked up while building this amazing machine!

Downloading Sony GPS Assist Data Manually

After having bought a new Sony DSC-HX5V digital camera, which is equipped with an integrated GPS, I discovered that it comes with windows-only software for downloading and updating the GPS almanac on the camera (the supplied PMB Portable software runs on Apple OS X, but it does not support downloading the GPS almanac).

After tinkering a bit with tcpdump(1) and friends I found out how to perform the download and update manually:

  1. Download assistme.dat
  2. Download assistme.md5
  3. Verify that the MD5 sum of the assistme.dat file matches the one in the assistme.md5 file
  4. Create a top-level folder hierarchy on the memory card for the camera (not the internal memory of the camera) called PRIVATE/SONY/GPS/
  5. Place the downloaded assistme.dat file in the PRIVATE/SONY/GPS/ folder
  6. Place the memory card in the camera and verify that the GPS Assist Data is valid

I have written a small perl script for automating the above tasks. The script takes the mount point of the memory card as argument.

Monitoring Soekris Temperature through SNMP

Here’s a quick tip for monitoring the temperature of your Soekris net4801 through SNMP on FreeBSD:

Install the net-mgmt/bsnmp-ucd and sysutils/env4801 ports and add the following to /etc/snmpd.conf:

begemotSnmpdModulePath."ucd" = "/usr/local/lib/"
extNames.0 = "temperature"
extCommand.0 = "/usr/local/sbin/env4801 | /usr/bin/grep ^Temp | /usr/bin/cut -d ' ' -f 6"

Enable and start bsnmpd(1). The temperature of your Soekris net4801 can now be queried through UCD-SNMP-MIB::extOutput.0 OID (

Plotting Load Average as Floating Point using MRTG

The web is flooded with examples of how to use the popular MRTG software for plotting more exotic SNMP OIDs than just network traffic.

One of the more popular variables to graph seems to be the load average of a given system, but all of the examples I have stumpled upon online compromise when it comes to plotting the load average as a floating point value.

It is, however, possible to post-process the gathered statistics before plotting the graph and the legend using the YTicsFactor and Factor keywords as shown in the example below:

Options[load]: gauge, nopercent, noo
MaxBytes[load]: 100
Title[load]: 5 Minute Load Average
PageTop[load]: <h1>5 Minute Load Average</h1>
YLegend[load]: Load Average
ShortLegend[load]: &nbsp;
Legend1[load]: 5 Minute Load Average
Legend3[load]: Maximum Observed Load Average
LegendI[load]: &nbsp;Load Average:
YTicsFactor[load]: 0.01
Factor[load]: 0.01

The above example will gather the 5 minute load average as an integer value (average load x 100) of localhost and use a scaling factor of 0.01 before actually plotting the graph.

Judging from the examples I have found online, the noo option and the PseudoZero pseudo OID used in the example are other, often overlooked features of MRTG. The noo option specifies that no “Output” graph shall be plotted while the PseudoZero pseudo OID always returns 0 (whereas noi disables the “Input” graph and PseudoOne always returns 1). vs. iTerm, Round II

A lot of water has passed beneath the bridge since I wrote my last entry about Apples vs. iTerm. Apple has released Snow Leopard with, among other things, a much improved version of, which has gotten me to ditch iTerm again.

So, I bring to you a version of the script for opening a new terminal window on the currently active desktop space – the way:

tell application "System Events"
	set TerminalCount to (count (every process whose name is "Terminal"))
end tell

if (TerminalCount is not 0) then
	tell application "Terminal"
		do script
	end tell
	tell application "Terminal"
	end tell
end if

As usual: Save the script to a .scpt file, open it with Script Editor, save as an Application and place a shortcut in your Dock. vs. iTerm

Having used Apple’s own for all my terminal emulator needs since I switched to OS X on my primary workstation, I decided to take iTerm for a spin this weekend – it was a pleasant surprise.

Compared to, iTerm seems to suck up a few more system resources, but this is – imho – easily made up for with the added features. Especially tab support is much better in iTerm than in Being able to set the title of tabs from the running shell (using the XTerm “icon name” escape sequence) along with the tab activity indicators rocks. Copy-on-selection and Cmd-click to launch URLs are also nice additions, that – once you get used to them – are very hard to work without.

There is, however, one missing feature of both and iTerm: The ability to click an icon in the Dock and have a new terminal emulator window open in the currently selected space. I’ve written a small AppleScript to do just that for iTerm:

tell application "System Events"
	set iTermCount to (count (every process whose name is "iTerm"))
end tell

if (iTermCount is not 0) then
	tell application "iTerm"
		set newterm to (make new terminal)
		tell newterm
			launch session "Default"
		end tell
	end tell
	tell application "iTerm"
	end tell
end if

Save the script to a .scpt file, open it with Script Editor, save as an Application and place a shortcut in your Dock.

Booting nanoBSD on the Alix2c2 SBC

A friend and I recently purchased a couple of Alix2c2 SBCs from PC Engines with the intention of running FreeBSDs nanoBSD on them.

However, getting nanoBSD to boot on the Alix board turned out to require a few customizations which I will post here in the hope of saving others the trouble.

The Alix2c2 reports the following at boot time for the noname 1GB CF card from PC Engines:

PC Engines ALIX.2 v0.99
640 KB Base Memory
261120 KB Extended Memory

01F0 Master 044A CF 1GB                                  
Phys C/H/S 1966/16/63 Log C/H/S 983/32/63

Running diskinfo(8) on the CF in an USB CF card reader on another FreeBSD machine revealed the capacity of the card:

$ diskinfo /dev/da0
/dev/da0        512     1014644736      1981728 967     64      32

Gettng nanoBSD to boot on the Alix2c from the 1GB CF card required the following customizations to the nanoBSD configuration file:

# Drive geometry
NANO_MEDIASIZE=`expr 1014644736 / 512` # size from diskinfo(8) on the UBS CF card reader
NANO_HEADS=32 # heads from the logic CHS information at boot time
NANO_SECTS=63 # sects from the logic CHS information at boot time

# Boot loader
NANO_BOOT0CFG="-o nopacket -s 1 -m 3" # nopacket seems to be required by tinyBIOS

Before booting nanoBSD, hit ‘s’ on the Alix2c2 serial console during RAM testing and switch the BIOS to LBA mode and 9600 baud serial console (default is 38400 baud, but this wont work with boot0sio). Re-attach to the serial console with 9600 baud and reboot to verify the setup.