[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>
>---------------------------------------------------------------
cb7ed39412308b3c0d265d2a554ce19054843e85
.../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:
+\begin{itemize}
+\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
+\end{itemize}
+
+\section{Goals}
+
+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.
+
+\section{Setup}
+
+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:
+\begin{verbatim}
+sudo losetup -f --show --partscan sd.img
+\end{verbatim}
+
+And then format the third partition:
+
+\begin{verbatim}
+sudo mkfs.ext4 -L data /dev/loop<x>p3
+\end{verbatim}
+
+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:
+\begin{verbatim}
+sudo umount /mnt/data
+sudo losetup -d /dev/loop<x>
+\end{verbatim}
+
+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
+like
+
+\begin{verbatim}
+fatload mmc 0:1 0x61000000 filename
+\end{verbatim}
+
+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:
\section{Goals}
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:
+\begin{verbatim}
+sudo losetup -d /dev/loop<x>
+\end{verbatim}
+
\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
\begin{verbatim}
#!/bin/bash
-exec /sbin/ifconfig $1 192.168.100.1
+exec /sbin/ifconfig $1 192.168.0.1
\end{verbatim}
Of course, make this script executable:
@@ -214,8 +219,10 @@ Of course, make this script executable:
sudo chmod +x /etc/qemu-myifup
\end{verbatim}
-As you can see, the host side will have the \code{192.168.100.1} IP
-address. We will use \code{192.168.100.2} for the target side.
+As you can see, the host side will have the \code{192.168.0.1} IP
+address. We will use \code{192.168.0.100} 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:
\begin{verbatim}
-setenv ipaddr 192.168.100.2
-setenv serverip 192.168.100.1
+setenv ipaddr 192.168.0.100
+setenv serverip 192.168.0.1
saveenv
\end{verbatim}
You can now test the connection to the host:
\begin{verbatim}
-ping 192.168.100.1
+ping 192.168.0.1
\end{verbatim}
It should finish by:
\begin{verbatim}
-host 192.168.100.1 is alive
+host 192.168.0.1 is alive
\end{verbatim}
\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