[bootlin/training-materials updates] master: Block filesystem lab for QEMU (cb7ed394)

Michael Opdenacker michael.opdenacker at bootlin.com
Wed Jun 24 19:08:50 CEST 2020

Repository : https://github.com/bootlin/training-materials
On branch  : master
Link       : https://github.com/bootlin/training-materials/commit/cb7ed39412308b3c0d265d2a554ce19054843e85


commit cb7ed39412308b3c0d265d2a554ce19054843e85
Author: Michael Opdenacker <michael.opdenacker at bootlin.com>
Date:   Wed Jun 24 19:08:50 2020 +0200

    Block filesystem lab for QEMU
    Signed-off-by: Michael Opdenacker <michael.opdenacker at bootlin.com>


 .../sysdev-block-filesystems-qemu.tex              | 148 +++++++++++++++++++++
 .../sysdev-block-filesystems.tex                   |   2 +-
 labs/sysdev-u-boot-qemu/sysdev-u-boot-qemu.tex     |  21 ++-
 mk/embedded-linux-qemu.mk                          |   4 +-
 4 files changed, 164 insertions(+), 11 deletions(-)

diff --git a/labs/sysdev-block-filesystems-qemu/sysdev-block-filesystems-qemu.tex b/labs/sysdev-block-filesystems-qemu/sysdev-block-filesystems-qemu.tex
new file mode 100644
index 00000000..4d412a46
--- /dev/null
+++ b/labs/sysdev-block-filesystems-qemu/sysdev-block-filesystems-qemu.tex
@@ -0,0 +1,148 @@
+\subchapter{Filesystems - Block file systems}{Objective: configure and
+  boot an embedded Linux system relying on block storage}
+After this lab, you will be able to:
+\item Manage partitions on block storage.
+\item Produce file system images.
+\item Configure the kernel to use these file systems
+\item Use the tmpfs file system to store temporary files
+After doing the {\em A tiny embedded system} lab, we are going to copy
+the filesystem contents to the emulated SD card. The storage will be
+split into several partitions, and your QEMU emulated board will
+be booted from this SD card, without using NFS anymore.
+Throughout this lab, we will continue to use the root filesystem we
+have created in the \code{$HOME/__SESSION_NAME__-labs/tinysystem/nfsroot}
+directory, which we will progressively adapt to use block filesystems.
+\section{Filesystem support in the kernel}
+Recompile your kernel with support for SquashFS and ext4\footnote{Basic
+configuration options for these filesystems will be sufficient. No need
+for things like extended attributes.}.
+Update your kernel image on the tftp server. We will only later copy
+the kernel to our FAT partition.
+Boot your board with this new kernel and on the NFS filesystem you
+used in this previous lab.
+Now, check the contents of \code{/proc/filesystems}. You should see
+ that ext4 and SquashFS are now supported.
+\section{Format the third partition}
+We are going to format the third partition of the SD card image
+with the ext4 filesystem, so that it can contain uploaded images.
+Setup the loop device again:
+sudo losetup -f --show --partscan sd.img
+And then format the third partition:
+sudo mkfs.ext4 -L data /dev/loop<x>p3
+Now, mount this new partition on a directory on your host (you could
+create the \code{/mnt/data} directory, for example) and move the contents of the
+\code{/www/upload/files} directory (in your target root filesystem) into
+it. The goal is to use the third partition of the SD card as the storage
+for the uploaded images.
+You can now unmount the partition and free the loop device:
+sudo umount /mnt/data
+sudo losetup -d /dev/loop<x>
+Now, restart QEMU and from the Linux command line and
+mount this third partition on \code{/www/upload/files}.
+Once this works, modify the startup scripts in your root filesystem
+to do it automatically at boot time.
+Reboot your target system again and with the mount command, check that
+\code{/www/upload/files} is now a mount point for the third SD card
+partition. Also make sure that you can still upload new images, and
+that these images are listed in the web interface.
+\section{Adding a tmpfs partition for log files}
+For the moment, the upload script was storing its log file in
+\code{/www/upload/files/upload.log}. To avoid seeing this log file in
+the directory containing uploaded files, let's store it in
+\code{/var/log} instead.
+Add the \code{/var/log/} directory to your root filesystem and modify
+the startup scripts to mount a \code{tmpfs} filesystem on this
+directory. You can test your \code{tmpfs} mount command line on the
+system before adding it to the startup script, in order to be sure
+that it works properly.
+Modify the \code{www/cgi-bin/upload.cfg} configuration file to store
+the log file in \code{/var/log/upload.log}. You will lose your log
+file each time you reboot your system, but that's OK in our
+system. That's what \code{tmpfs} is for: temporary data that you don't need
+to keep across system reboots.
+Reboot your system and check that it works as expected.
+\section{Making a SquashFS image}
+We are going to store the root filesystem in a SquashFS filesystem in
+the second partition of the SD card.
+In order to create SquashFS images on your host, you need to install
+the \code{squashfs-tools} package. Now create a SquashFS image of your
+NFS root directory.
+Setup the loop device again, and using the \code{dd} command,
+copy the file system image to the second partition in the SD card
+image. Release the loop device.
+\section{Booting on the SquashFS partition}
+In the U-boot shell, configure the kernel command line to use the
+second partition of the SD card as the root file system. Also add the
+\code{rootwait} boot argument, to wait for the SD card to be properly
+initialized before trying to mount the root filesystem. Since the SD
+cards are detected asynchronously by the kernel, the kernel might try
+to mount the root filesystem too early without \code{rootwait}.
+Check that your system still works. Congratulations if it does!
+\section{Store the kernel image and DTB on the SD card}
+Setup the loop device again, and mount the FAT partition
+in the SD card image (for example on \code{/mnt/boot}).
+Then copy the kernel image and Device Tree to it.
+Unmount the FAT partition and release the loop device.
+You now need to adjust the \code{bootcmd} of U-Boot so
+that it loads the kernel and DTB from the SD card instead of loading
+them from the network.
+In U-boot, you can load a file from a FAT filesystem using a command
+fatload mmc 0:1 0x61000000 filename
+Which will load the file named \code{filename} from the first
+partition of the device handled by the first MMC controller to the
+system memory at the address \code{0x61000000}.
+Type \code{reset} in U-Boot to reboot the board and make
+sure that your system still boots fine.
diff --git a/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex b/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
index 2dab6be0..73e601c4 100644
--- a/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
+++ b/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
@@ -12,7 +12,7 @@ After this lab, you will be able to:
 After doing the {\em A tiny embedded system} lab, we are going to copy
-the filesystem contents to the SD card. The filesystem will be
+the filesystem contents to the SD card. The storage will be
 split into several partitions, and your sama5d3 X-plained board will
 be booted with this SD card, without using NFS anymore.
diff --git a/labs/sysdev-u-boot-qemu/sysdev-u-boot-qemu.tex b/labs/sysdev-u-boot-qemu/sysdev-u-boot-qemu.tex
index e7650410..a14e31f0 100644
--- a/labs/sysdev-u-boot-qemu/sysdev-u-boot-qemu.tex
+++ b/labs/sysdev-u-boot-qemu/sysdev-u-boot-qemu.tex
@@ -171,6 +171,11 @@ sudo mkfs.vfat -F 16 -n boot /dev/loop<x>p1
 The other partitions will be formated later.
+Now, you can release the loop device:
+sudo losetup -d /dev/loop<x>
 \section{Testing U-Boot's environment}
 Start QEMU again, but this time with the emulated SD card
@@ -206,7 +211,7 @@ script that will bring up a network interface between QEMU and the host. Here ar
-exec /sbin/ifconfig $1
+exec /sbin/ifconfig $1
 Of course, make this script executable:
@@ -214,8 +219,10 @@ Of course, make this script executable:
 sudo chmod +x /etc/qemu-myifup
-As you can see, the host side will have the \code{} IP
-address. We will use \code{} for the target side.
+As you can see, the host side will have the \code{} IP
+address. We will use \code{} for the target side.
+Of course, use a different IP address range if this conflicts with your
+local network.
 Then, you will need root privileges to run QEMU this time,
 because of the need to bring up the network interface:
@@ -241,19 +248,19 @@ On the U-Boot command line, you will have to configure the environment
 variables for networking:
-setenv ipaddr
-setenv serverip
+setenv ipaddr
+setenv serverip
 You can now test the connection to the host:
 It should finish by:
-host is alive
+host is alive
 \section{tftp setup}
diff --git a/mk/embedded-linux-qemu.mk b/mk/embedded-linux-qemu.mk
index c9444f6a..4730bc3a 100644
--- a/mk/embedded-linux-qemu.mk
+++ b/mk/embedded-linux-qemu.mk
@@ -53,10 +53,8 @@ EMBEDDED_LINUX_QEMU_LABS   = ubuntu-vm \
 		sysdev-kernel-fetch-and-patch \
 		sysdev-kernel-cross-compiling \
 		sysdev-tinysystem \
-		sysdev-block-filesystems \
-		sysdev-flash-filesystems \
+		sysdev-block-filesystems-qemu \
 		sysdev-thirdparty \
 		sysdev-buildroot \
 		sysdev-application-development \
 		sysdev-application-debugging \
-		sysdev-real-time

More information about the training-materials-updates mailing list