Home > Community > Blogs > System Design and Verification > using a network file system with the xilinx zynq 7000 virtual platform
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Cadence blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Using a Network File System with the Xilinx Zynq-7000 Virtual Platform

Comments(0)Filed under: Embedded Linux, Zynq virtual platform, Ubuntu 12.04, Network File System

There are a number of ways to do embedded software development for Xilinx Zynq-7000 based designs. For embedded Linux projects, Zynq offers multiple storage options such as SD card and USB. It's also possible to use a ramdisk for the root file system during development. Today, I will cover how to use the Network File System (NFS), first to mount a file system on the host machine and then to mount the root file system over the network. As usual, we will do all this using the Zynq Virtual Platform from Cadence.

The Network File System has been around for a long time (approaching 30 years). I remember using diskless Sun workstations at my first job which mounted all directories from an NFS server. I also remember that when the server failed it was a complete work stoppage. Ironically, one of the applications in use was a Cadence schematic editor, but all I can remember is that it was something called ged.

Introduction to NFS

The Network File System allows one machine (the client) to mount a file system on another machine (the server). NFS is mostly commonly used on a network of UNIX or Linux workstations that share the same file systems for applications and user directories. The benefit for an embedded developer is that they can easily create software on a host machine (server) and immediately see the file changes from the target system (client). This eliminates the need to copy files using ssh or ftp and eliminates the risk of files becoming out of sync with the versions on the host machine. NFS is pretty slick, but there a few common pitfalls during setup.

This article covers the following topics:

  • Setting up an NFS server
  • Configuring the Zynq Linux kernel
  • Mounting a file system on an NFS server from the Zynq Virtual Platform
  • Using NFS for the root file system of the Zynq Virtual Platform

NFS Server Setup

The first step to working with NFS is to install and run an NFS server. I will show how to do this on a Ubuntu 12.04 machine. The first step is easy -- install the NFS packages using:

$ sudo apt-get install nfs-kernel-server nfs-common

The next step is to specify which parts of the file system to share with NFS clients. Since I eventually want to get to a root file system over NFS, I will start with a simple root file system that is used by the Zynq Virtual Platform as a ramdisk. If you have the Zynq Virtual Platform you can use the file `ncroot`/tools/esl/platforms/zynq/hw_unit/bp_demo/tb/rootfs.cpio.gz

First, I create a directory to share via NFS in my home directory:

$ cd ; mkdir zynqfs

Then, extract the file system in this new directory

$ cd zynqfs ; gzip -d < `ncroot`/tools/esl/platforms/zynq/hw_unit/bp_demo/tb/rootfs.cpio.gz | cpio --extract

Now we have a directory ~/zynqfs ready to share with the Zynq Virtual Platform.

NFS exports are defined in the file /etc/exports

Edit this file (using sudo) to add an entry for the file system to be exported. I added the following:

/home/jasona/zynqfs    *(rw,sync,no_root_squash,no_subtree_check,insecure)

The key options are rw for read and write and insecure to allow ports larger than 1024. I also allow access from any client machine using a * wildcard. Basically, I have no security in place, but I'm not concerned anybody at Cadence wants to mount and see this file system data.

After editing /etc/exports use the exportfs command to start the sharing.

$ sudo exportfs -a

Running the command with no arguments will show the exported file systems.

$ sudo /etc/init.d/nfs-kernel-server stop

$ sudo /etc/init.d/nfs-kernel-server start

When it's all done the exportfs command shows the file system exported for anybody:

If anything goes wrong look in the file /var/log/syslog to see what happened. I used this to debug what happened when things didn't work on the first try.

Configuring the Zynq Linux Kernel

The Zynq Linux kernel must be configured to support NFS. The good news is I found the default kernel configurations for Zynq have the needed options already enabled so no changes are needed. If you are interested in what is required there are two options under File systems -> Network File Systems. These are "NFS client support" and "Root file system on NFS". The menuconfig is shown below:

Mounting an NFS File System from the Zynq Virtual Platform

The first way to use NFS with the Zynq Virtual Platform is to mount the exported directory from the simulated Zynq Virtual Platform. Since the Gigabit Ethernet Controller is modeled it is easy to mount the file system over the network and access the files on the host machine. For this test, I booted Linux with a ramdisk as the root file system and then used a mount command as shown below. Since I shared the same root file system over NFS you can compare the contents. The screen shot is shown below.

The only interesting option is -o nolock; I found that without this I got an error and could not mount the file system. I don't know the details, but disabling file locking makes it work.

This mount could be automated by putting an entry in /etc/fstab to mount automatically

Using NFS for the Zynq Virtual Platform Root File System

The last scenario is to use NFS for the root file system. This would be useful if a development task involves iterating through changes to the root file system that would take more time to create an SD card or USB image for every change. Using NFS, updates can be tried immediately without any scp or ftp, and if the changes require rebooting, it will be more efficient than updating an SD card or USB image.

Using an NFS root file system with the Zynq Virtual Platform requires a change to the Linux kernel command line. I did this by modifying the Linux device tree source file (.dts file) and re-building the device tree binary (.dtb file).

The key option is to specify the root file system as nfs and to specify the same file system mounted before:

root=/dev/nfs nfsroot=

After these changes are made, rebuild the .dtb file using the device tree compiler:

$ dtc -I dts -O dtb -o zynq-ep107.dtb zynq-ep107.dts

Now when the simulation runs the root file system will be mounted over NFS. Look for the "Mounted root (nfs filesystem)" in the screenshot:

To confirm it really works, create a new file on the host machine anywhere in the exported file system area and see it show up in the root file system of the Zynq simulation. Files can be edited from either side and the updates are immediately available, very cool!


Using NFS for embedded software development is a useful option for many projects. There are definitely trade-offs related to performance and flexibility. Virtual Platforms are more flexible to start with since they are just simulations on the host machine anyway. Maybe next time I will show another way to get the same benefits as NFS in terms of protecting from files being out of sync by using USB or SD card models.

Thanks for reading.

Jason Andrews 


Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.