Configuring network booting for a development setup

Most professional i.MX6 boards will have an internal flash memory, and that would be the recommended way to boot firmware. The Wandboard is not really a product meant for professional use, so it does not have one, booting from a microSD card instead. But neither the internal flash nor the microSD card are ideal for development work, as any system change would involve a reprogramming of the firmware image.

Getting ready

The ideal setup for development work is to use both Trivial File Transfer Protocol (TFTP) and Network File System (NFS) servers in your host system and to only store the U-Boot bootloader in either the internal flash or a microSD card. With this setup, the bootloader will fetch the Linux kernel from the TFTP server and the kernel will mount the root filesystem from the NFS server. Changes to either the kernel or the root filesystem are available without the need to reprogram. Only bootloader development work would need you to reprogram the physical media.

Installing a TFTP server

If you are not already running a TFTP server, follow the next steps to install and configure a TFTP server on your Ubuntu 16.04 host:

$ sudo apt-get install tftpd-hpa  

The tftpd-hpa configuration file is installed in /etc/default/tftpd-hpa. By default, it uses /var/lib/tftpboot as the root TFTP folder. Change the folder permissions to make it accessible to all users using the following command:

$ sudo chmod 1777 /var/lib/tftpboot

Now copy the Linux kernel and device tree for the Wandboard Quad Plus from your build directory as follows:

$ cd /opt/yocto/fsl-community-bsp/wandboard/tmp/deploy/images/wandboard/
$ cp zImage-wandboard.bin zImage-imx6qp-wandboard-revd1.dtb /var/lib/tftpboot
  

If you have a different hardware variant or revision of the Wandboard, you will need to use a different device tree, as shown next. The corresponding device trees for the Wandboard Quad are:

• revision b1: zImage-imx6q-wandboard-revb1.dtb
• revision c1: zImage-imx6q-wandboard.dtb
• revision d1: zImage-imx6q-wandboard-revd1.dtb

The corresponding device trees for the Wandboard solo/dual lite are:

• revision b1: zImage-imx6dl-wandboard-revb1.dtb
• revision c1: zImage-imx6dl-wandboard.dtb
• revision d1: zImage-imx6dl-wandboard-revd1.dtb

And the device tree for the Wandboard Quad Plus is:

• revision d1: zImage-imx6qp-wandboard-revd1.dtb

Installing an NFS server

If you are not already running an NFS server, follow the next steps to install and configure one on your Ubuntu 16.04 host:

$ sudo apt-get install nfs-kernel-server

We will use the /nfsroot directory as the root for the NFS server, so we will untar the target's root filesystem from our Yocto build directory in there.

By default, the Wandboard only builds WIC images. We will need to modify our build project to build a compressed copy of the target's root filesystem. For that, follow the next steps:

$ cd /opt/yocto/fsl-community-bsp/wandboard 

Edit conf/local.conf and add the following:

IMAGE_FSTYPES = "wic.gz tar.bz2"  

This will build a core-image-minimal-wandboard.tar.bz2 file that we can then uncompress under /nfsroot, as follows:

$ sudo mkdir /nfsroot
$ cd /nfsroot
$ sudo tar --numeric-owner -x -v -f /opt/yocto/fsl-community-bsp/wandboard/tmp/deploy/images/wandboard/core-image-minimal-wandboard.tar.bz2 

The extraction of the root filesystem can also be done without superuser permissions by using the runqemu-extract-sdk script, which uses pseudo to correctly extract and set the permissions of the root filesystem, as follows:

$ cd /opt/yocto/fsl-community-bsp/wandboard
$ bitbake meta-ide-support
$ runqemu-extract-sdk tmp/deploy/images/wandboard/core-image-minimal-wandboard.tar.bz2 /nfsroot/rootfs/

For this to work, the destination nfsroot directory needs to be writable by the current user.

Next, we will configure the NFS server to export the /nfsroot folder.

Add the following line to /etc/exports:

/nfsroot/ *(rw,no_root_squash,async,no_subtree_check)  

We will then restart the NFS server for the configuration changes to take effect:

$ sudo service nfs-kernel-server restart  

How to do it...

We now have the boot binaries and root filesystem ready for network booting, and we need to configure U-Boot to perform the network boot.

Boot the Wandboard and stop at the U-Boot prompt by pressing any key on the serial console. Make sure it has an Ethernet cable plugged in and connected to your local network. You should see the U-Boot banner and prompt as follows:

U-Boot banner

The Yocto 2.4 version of U-Boot for the Wandboard has introduced changes in the default environment so that there is less platform-specific customization made in the source. As such, previous versions used to have a default environment ready to perform a network boot just by setting a few environmental variables and running the netboot script.

The current U-Boot has instead replaced it with a network boot mechanism that looks for a U-Boot script called extlinux.conf on the configured TFTP server and executes it. In that way, platform-specific booting options are isolated into the boot script which is compiled with the U-Boot source.

The Yocto Project prepares an extlinux.conf boot script and copies it to the deploy directory along with the images. We can add kernel command line arguments to pass to the Linux kernel in this boot script by using the UBOOT_EXTLINUX_KERNEL_ARGS configuration variable. More details about customizing the extlinux.conf script is provided in Chapter 2, The BSP Layer.

However, for development purposes, it is more flexible to restore the previous network boot environment variables:

> env set netload 'tftpboot ${loadaddr} ${image};tftpboot ${fdt_addr} ${fdt_file}'
> env set netargs 'setenv bootargs console=${console} ${optargs} root=/dev/nfs ip=${ipaddr} nfsroot=${serverip}:${nfsroot},v3,tcp'
> env set netboot 'echo Booting from net ...;run netargs;run netload;bootz ${loadaddr} - ${fdt_addr}'  

The netload script loads the Linux kernel binary and the device tree blob into memory. The netargs script prepares the bootargs environmental variable to pass the correct kernel command line parameters for a network boot, and the netboot command executes the network boot by running netargs and using the bootz command.

Now we will prepare the rest of the environmental variables it needs:

1. Configure a static IP address with:

> env set ipaddr <static_ip>

2. Configure the IP address of your host system, where the TFTP and NFS servers have been set up:

> env set serverip <host_ip>

3. Configure the root filesystem mount:

> env set nfsroot /nfsroot

4. Configure the Linux kernel and device tree filenames:

> env set image zImage-wandboard.bin
> env set fdt_file zImage-imx6qp-wandboard-revd1.dtb

5. Save the U-Boot environment to the microSD card:

> env save

6. Perform a network boot:

> run netboot

The Linux kernel and device tree will be fetched from the TFTP server, and the root filesystem will be mounted by the kernel from the NFS share.

You should be able to log in with the root user without a password prompt.

Once booted, we can find out the kernel command line arguments used to boot by doing:

$ cat /proc/cmdline
console=ttymxc0,115200 root=/dev/nfs ip=192.168.1.15 nfsroot=192.168.1.115:/nfsroot,v3,tcp