Network File System (NFS)

From InCircuit
Jump to: navigation, search

The network filesystem (NFS) can be used to host a device's filesystem on the PC and modify it without replacing any files on the target. This reasonably is especially useful during the development of applications. This has to be prepared on the host once. The target can be configured booting via NFS autonomous, too.


Preparation of the host

The following examples assume the host-PC to have the IP-Address The target is assumed to get the IP These values can be modified as needed, as long as both addresses exist within the same network. Another assumption is, that the host populates the directory /icnova with a filesystem and export it. The place of this directory can be changed, too. Buildroot will be assumed to be found at the users home-directory, ~/ICnova, and build for the device adb1000g45. Both is changeable, but must be replaced in the following examples.

Making the target known

To allow access to the client, the host must be able to find a hostname for the devices IP-Address. This either can be done via setting up a corresponding entry within the networks DNS-System, or by editing the file /etc/hosts on the PC. While the first option is out of the scope of this document, the scope will be set on the second one.

To register a hostname to a specific IP-address, just edit the file /etc/hosts and add a line like  icnova

Afterwards for this PC the IP is already known as the host icnova.

exporting a directory

All directories allowed to be exported on the host, are set in the file /etc/exports. The line

 /icnova *(rw,sync,no_subtree_check,no_root_squash)

is enough, to enable the target to access it's contents. The option no_root_squash must be set. Otherwise the target will not be able to work. After changing this file, the NFS-server has to be restarted. On a Debian or Ubuntu-System this can be done by executing

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

populating the export

Populating the exported directory with an buildroot generated filesystem can be done either from an ext2 or from an tar-image. Whichever is choosen, it must be selected within buildroots configuration.

Buildroot fsselection.png

Using a tar'ed filesystem

If a tar-image is generated this can be unpacked by

 $ cd /icnova
 $ sudo tar -xf ~/ICnova/binaries/adb1000g45/rootfs.arm.tar

While this method has the advantage of not deleting custom added files, it is quite slow, as the whole content of the image has to be copied, and it isn't cleaned up automaticly.

Using an ext2-image

If an ext2-image is generated, this can be used, if it was mounted using the loopback device. This can be done by the following commands

 $ sudo /etc/init.d/nfs-kernel-server stop
 $ sudo umount /icnova
 $ sudo mount -o loop ~/ICnova/binaries/adb1000g45/rootfs.arm.ext2 /icnova
 $ sudo /etc/init.d/nfs-kernel-server start

This method ensures that the content of the exported directory contain exactly the files, buildroot generated. No cruft was left. On the other hand, the size of the Image is hard and can be changed only by setting a new size within make menuconfig. Here not only the size of the Image (as multiple of 1024kB) is important but also the number of inodes or allowed number of files. On a usual system 1500 has be found to be a good value. Abite from restarting the NFS-server while remounting a new image, before generating a new image with buildroot, it always should be made sure, that the old images were deleted in advance, eg. by executing

 $ rm binaries/adb1000g45/rootfs.*; make

Otherwise the mounted system can be modified while the new system is generated, resulting in a unusable filesystem.

Mounting the targets root filesystem via NFS

During the normal boot, the ICnova configures it's networking during boot. While booting via network this step must be disabled, as any network-connection will be killed during this step. Please edit the file /icnova/etc/network/interfaces on the host before booting the target and delete the line “auto eth0”.

After making your image accessible over NFS, the bootloader can be accessed by pressing <SPACE> during the boot-up sequence.

on SAM9G45 and i.MX35 based modules

A list of all environment variables is displayed using the command "printenv". It is recommended to make notes of the default settings allowing a restore of the settings if needed.

To access a NFS-share, the bootloader needs to know its own address, as well as the address of the server. This can be done by setting the variables serverip and ipaddr.

 > setenv serverip
 > setenv ipaddr

To make the kernel know, where it can find the filesystem, the correct arguments have to be supplied. U-Boot will tell the Kernel all arguments that were saved in the variable bootargs.

 > setenv bootargs nfsroot=/icnova ip=${ipaddr}:${serverip}::::eth0:none

If the network is configured using DHCP and the target is getting the correct IP by the DHCP-server, the arguments can be shortened to

 > setenv bootargs nfsroot=/icnova ip=dhcp

To boot the via nfs, the kernel has to be loaded from the PC and booted afterwards. To do this execute

 > nfs 0x70400000 /icnova/boot/uImage; bootm

The address in memory depends on the module you are using. Please referr to the default memory locations for your module. If the board should always boot via nfs, it is possible to modify the environment variable bootcmd. This gets executed on system-start, if the bootloader isn't interrupted.

 > askenv bootcmd
 nfs 0x70400000 /icnova/boot/uImage; bootm
 > saveenv

The command askenv is different from saveenv, as it gives a new line to insert the value of a specific variable. It's contents can have characters with special meanings. Using setenv in this case would result in bootcmd having the content nfs 0x70400000 /icnova/boot/uImage and the command bootm being executed immediatly.

The command “boot“ boots the ICnova with the new settings.

on i.MX53 based modules

These modules use barebox as bootloader, making the configuration different.

After stopping the autoboot-mechanism by pressing space when requested, the user is dropped in a small shell with access to the bootloaders pseudo-filesystem. The booting scheme is defined in the file env/config. Using the command

 > edit env/config

this file can be edited. Navigation can be done by using the arrow keys. with <Ctrl>+<C> the editor closes, discarding the edits, pressing <Ctrl>+<D> the edits are saved before closing.

near the beginning of the file, a line


is commented out. By removing the hash '#' the line becomes active. Afterwards the values for eth0.serverip, eth0.ipaddr and nfsdir should be adjusted accordingly. Now the editor can be left pressing <Ctrl>+<D>.

If the module should boot via NFS always, use

 > saveenv

to make the changes permanent. Otherwise these will last until the next reboot, only. Entering the command

 > boot

the module will start to try booting via NFS.

Mounting a NFS directory on the target

To use NFS on the target, the program portmap has to be started in advance. Simply do

 # portmap

on the target.

To access the NFS-Server, its exported directory has to be mounted. This can be done by

 # mount -t nfs /mnt
Personal tools