[FE training-materials-updates] Embedded Linux: misc improvements
Michael Opdenacker
michael.opdenacker at free-electrons.com
Thu May 26 06:35:59 CEST 2016
Repository : git://git.free-electrons.com/training-materials.git
On branch : master
Link : http://git.free-electrons.com/training-materials/commit/?id=bfe9a2a4d127fef4ff1c16bf37d74b86869edf38
>---------------------------------------------------------------
commit bfe9a2a4d127fef4ff1c16bf37d74b86869edf38
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date: Thu May 26 06:35:59 2016 +0200
Embedded Linux: misc improvements
Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>
>---------------------------------------------------------------
bfe9a2a4d127fef4ff1c16bf37d74b86869edf38
.../sysdev-block-filesystems.tex | 7 ++-
.../sysdev-kernel-cross-compiling.tex | 23 +++++++--
labs/sysdev-tinysystem/sysdev-tinysystem.tex | 2 +-
labs/sysdev-u-boot/sysdev-u-boot.tex | 3 +-
.../sysdev-block-filesystems.tex | 6 +--
.../sysdev-bootloaders-u-boot.tex | 48 +++++++++----------
.../sysdev-flash-filesystems.tex | 56 ++++++++--------------
.../sysdev-toolchains-definition.tex | 4 +-
8 files changed, 76 insertions(+), 73 deletions(-)
diff --git a/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex b/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
index db623f8..09e9389 100644
--- a/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
+++ b/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
@@ -89,6 +89,11 @@ we are going to use:
$ sudo cfdisk /dev/mmcblk0
\end{verbatim}
+If \code{cfdisk} asks you to \code{Select a label type}, choose
+\code{dos}. This corresponds to traditional partitions tables that DOS/Windows
+would understand. \code{gpt} partition tables are needed for disks bigger
+than 2 TB.
+
In the \code{cfdisk} interface, delete existing partitions, then
create three primary partitions, starting from the beginning, with the
following properties:
@@ -199,7 +204,7 @@ Check that your system still works. Congratulations if it does!
You'll first need to format the first partition, using:
\begin{verbatim}
-sudo mkfs.vfat -F 16 -n boot /dev/sdb1
+sudo mkfs.vfat -F 16 -n boot /dev/mmcblk0p1
\end{verbatim}
It will create a new FAT16 partition, called \code{boot}. Remove and
diff --git a/labs/sysdev-kernel-cross-compiling/sysdev-kernel-cross-compiling.tex b/labs/sysdev-kernel-cross-compiling/sysdev-kernel-cross-compiling.tex
index 186b290..e0261c6 100644
--- a/labs/sysdev-kernel-cross-compiling/sysdev-kernel-cross-compiling.tex
+++ b/labs/sysdev-kernel-cross-compiling/sysdev-kernel-cross-compiling.tex
@@ -165,10 +165,25 @@ bootz 0x21000000 - 0x22000000
\end{verbatim}
Write a U-Boot script that automates the DTB + kernel download
-and flashing procedure. Finally, using \code{editenv bootcmd},
-adjust \code{bootcmd} so that the Xplained board boots
+and flashing procedure.
+
+You are now ready to modify \code{bootcmd} to boot the board
+from flash. But first, save the settings for booting from \code{tftp}:
+
+\begin{verbatim}
+setenv bootcmdtftp ${bootcmd}
+\end{verbatim}
+
+This will be useful to switch back to \code{tftp} booting mode
+later in the labs.
+
+Finally, using \code{editenv bootcmd},
+adjust \code{bootcmd} so that the Xplained board starts
using the kernel in flash.
Now, reset the board to check that it boots
-fine from NAND flash. Check that this is really your own version of
-the kernel that's running.
+in the same way from NAND flash. Check that this is really your own version of
+the kernel that's running\footnote{Look at the kernel log. You will find
+the kernel version number as well as the date when it was compiled.
+That's very useful to check that you're not loading an older version
+of the kernel instead of the one that you've just compiled.}
diff --git a/labs/sysdev-tinysystem/sysdev-tinysystem.tex b/labs/sysdev-tinysystem/sysdev-tinysystem.tex
index f3f2637..2c4a779 100644
--- a/labs/sysdev-tinysystem/sysdev-tinysystem.tex
+++ b/labs/sysdev-tinysystem/sysdev-tinysystem.tex
@@ -98,7 +98,7 @@ Now, boot your system. The kernel should be able to mount the root
filesystem over NFS:
\begin{verbatim}
-VFS: Mounted root (nfs filesystem) on device 0:13.
+VFS: Mounted root (nfs filesystem) on device 0:14.
\end{verbatim}
If the kernel fails to mount the NFS filesystem, look carefully at the
diff --git a/labs/sysdev-u-boot/sysdev-u-boot.tex b/labs/sysdev-u-boot/sysdev-u-boot.tex
index 689e70c..ca9647f 100644
--- a/labs/sysdev-u-boot/sysdev-u-boot.tex
+++ b/labs/sysdev-u-boot/sysdev-u-boot.tex
@@ -132,7 +132,8 @@ going to need a few pieces of information for this:
You can get the list of the supported boards by listing the
\code{board} directory. You'll see that in each of these folders, we
have a bunch of \code{defconfig} files, that are the supported
-combinations. In our case, we will load U-Boot, from NAND flash
+combinations. In our case, using the Atmel SAMA5D3 Xplained
+board, we will load U-Boot, from NAND flash on
(\code{nf} in the \code{defconfig} file names).
After finding the right \code{defconfig} file, load it using
diff --git a/slides/sysdev-block-filesystems/sysdev-block-filesystems.tex b/slides/sysdev-block-filesystems/sysdev-block-filesystems.tex
index e0464f5..c54f424 100644
--- a/slides/sysdev-block-filesystems/sysdev-block-filesystems.tex
+++ b/slides/sysdev-block-filesystems/sysdev-block-filesystems.tex
@@ -10,7 +10,7 @@
filesystems
\end{itemize}
\item {\bf Block devices} can be read and written to on a per-block
- basis, without erasing.
+ basis, in random order, without erasing.
\begin{itemize}
\item Hard disks, floppy disks, RAM disks
\item USB keys, Compact Flash, SD card: these are based on
@@ -178,8 +178,8 @@ major minor #blocks name
\item Now supports the XZ algorithm, for a much better compression
rate, at the expense of higher CPU usage and time.
\end{itemize}
- Benchmarks: (roughly 3 times smaller than ext3, and 2-4 times faster)\\
- \url{http://elinux.org/Squash_Fs_Comparisons}
+ Benchmarks: roughly 3 times smaller than ext3, and 2-4 times faster
+ (\url{http://elinux.org/Squash_Fs_Comparisons})
\end{frame}
\begin{frame}
diff --git a/slides/sysdev-bootloaders-u-boot/sysdev-bootloaders-u-boot.tex b/slides/sysdev-bootloaders-u-boot/sysdev-bootloaders-u-boot.tex
index 6a20ed0..a780a37 100644
--- a/slides/sysdev-bootloaders-u-boot/sysdev-bootloaders-u-boot.tex
+++ b/slides/sysdev-bootloaders-u-boot/sysdev-bootloaders-u-boot.tex
@@ -109,36 +109,34 @@
\begin{frame}
\frametitle{Installing U-Boot}
+ U-Boot must usually be installed in flash memory to be
+ executed by the hardware. Depending on the hardware, the
+ installation of U-Boot is done in a different way:
\begin{itemize}
- \item U-Boot must usually be installed in flash memory to be
- executed by the hardware. Depending on the hardware, the
- installation of U-Boot is done in a different way:
- \begin{itemize}
- \item The CPU provides some kind of specific boot monitor with
- which you can communicate through serial port or USB using a
- specific protocol
- \item The CPU boots first on removable media (MMC) before booting
- from fixed media (NAND). In this case, boot from MMC to reflash
- a new version
- \item U-Boot is already installed, and can be used to flash a new
- version of U-Boot. However, be careful: if the new version of
- U-Boot doesn't work, the board is unusable
- \item The board provides a JTAG interface, which allows to write
- to the flash memory remotely, without any system running on the
- board. It also allows to rescue a board if the bootloader
- doesn't work.
- \end{itemize}
+ \item The CPU provides some kind of specific boot monitor with
+ which you can communicate through serial port or USB using a
+ specific protocol
+ \item The CPU boots first on removable media (MMC) before booting
+ from fixed media (NAND). In this case, boot from MMC to reflash
+ a new version
+ \item U-Boot is already installed, and can be used to flash a new
+ version of U-Boot. However, be careful: if the new version of
+ U-Boot doesn't work, the board is unusable
+ \item The board provides a JTAG interface, which allows to write
+ to the flash memory remotely, without any system running on the
+ board. It also allows to rescue a board if the bootloader
+ doesn't work.
\end{itemize}
\end{frame}
\begin{frame}[fragile]
\frametitle{U-boot prompt}
\begin{itemize}
- \item Connect the target to the host through a serial console
+ \item Connect the target to the host through a serial console.
\item Power-up the board. On the serial console, you will see
- something like:
+ something like:
\end{itemize}
-\scriptsize
+\tiny
\begin{verbatim}
U-Boot 2016.05 (May 17 2016 - 12:41:15 -0400)
@@ -201,10 +199,6 @@ U-Boot 2016.05 (May 17 2016 - 12:41:15 -0400)
\begin{itemize}
\item The exact set of commands depends on the U-Boot configuration
\item \code{help} and \code{help command}
- \item \code{boot}, runs the default boot command, stored in
- \code{bootcmd}
- \item \code{bootz <address>}, starts a kernel image loaded at the
- given address in RAM
\item \code{ext2load}, loads a file from an ext2 filesystem to RAM
\begin{itemize}
\item And also \code{ext2ls} to list files, \code{ext2info} for
@@ -216,6 +210,10 @@ U-Boot 2016.05 (May 17 2016 - 12:41:15 -0400)
\end{itemize}
\item \code{tftp}, loads a file from the network to RAM
\item \code{ping}, to test the network
+ \item \code{boot}, runs the default boot command, stored in
+ \code{bootcmd}
+ \item \code{bootz <address>}, starts a kernel image loaded at the
+ given address in RAM
\end{itemize}
\end{frame}
diff --git a/slides/sysdev-flash-filesystems/sysdev-flash-filesystems.tex b/slides/sysdev-flash-filesystems/sysdev-flash-filesystems.tex
index 0cf45dd..1ab0304 100644
--- a/slides/sysdev-flash-filesystems/sysdev-flash-filesystems.tex
+++ b/slides/sysdev-flash-filesystems/sysdev-flash-filesystems.tex
@@ -237,7 +237,7 @@ setenv mtdparts mtdparts=omap2-nand.0:512k(X-Loader)ro,1536k(U-Boot)ro,512k(Env)
\includegraphics[width=0.85\textwidth]{slides/sysdev-flash-filesystems/kernel-mtd-log.pdf}\\
\end{itemize}
\item \code{mtdparts} defines partitions for the different devices\\
- \code{setenv mtdparts <mtdid>:<partition>[,partition]}\\
+ \code{setenv mtdparts mtdparts=<mtdid>:<partition>[,partition]}\\
\code{partition} format: \code{<size>[@offset](<name>)[ro]}
\end{itemize}
Use the \code{mtdparts} command to setup the configuration
@@ -353,9 +353,11 @@ setenv mtdparts mtdparts=omap2-nand.0:512k(X-Loader)ro,1536k(U-Boot)ro,512k(Env)
\item Flash filesystem image creation tools: \code{mkfs.jffs2},
\code{mkfs.ubifs}, \code{ubinize}, etc.
\end{itemize}
- \item Usually available as the \code{mtd-utils} package in your distribution
- \item Most commands now also available in BusyBox
- \item See \url{http://www.linux-mtd.infradead.org/}
+ \item On your workstation: usually available as the \code{mtd-utils}
+ package in your distribution.
+ \item On your embedded target: most commands now also available
+ in BusyBox.
+ \item See \url{http://www.linux-mtd.infradead.org/}.
\end{itemize}
\end{frame}
@@ -456,8 +458,8 @@ setenv mtdparts mtdparts=omap2-nand.0:512k(X-Loader)ro,1536k(U-Boot)ro,512k(Env)
\item Add some flexibility
\item Focus on scalability, performance and reliability
\end{itemize}
- \item Drawback: introduces noticeable overhead, especially when
- used on small devices or partitions
+ \item Drawback: introduces noticeable space overhead,
+ especially when used on small devices or partitions.
\end{itemize}
\column{0.3\textwidth}
\includegraphics[width=\textwidth]{slides/sysdev-flash-filesystems/ubifs.pdf}
@@ -553,7 +555,7 @@ setenv mtdparts mtdparts=omap2-nand.0:512k(X-Loader)ro,1536k(U-Boot)ro,512k(Env)
\end{frame}
\begin{frame}
- \frametitle{Linux: UBI host tools (1)}
+ \frametitle{Linux: UBI host tools}
\begin{itemize}
\item \code{ubinize} is the only host tool for the UBI layer
\item Creates a UBI image to be flashed on an MTD partition
@@ -569,15 +571,16 @@ setenv mtdparts mtdparts=omap2-nand.0:512k(X-Loader)ro,1536k(U-Boot)ro,512k(Env)
Subpage size, only needed if both your flash and your
flash controller are supporting subpage writes
\item The last argument is a path to a UBI image description file
+ (see next page for an example)
\end{itemize}
\item Example: \code{ubinize -o ubi.img -p 16KiB -m 512 -s 256 cfg.ini}
\end{itemize}
\end{frame}
\begin{frame}[fragile]
- \frametitle{Linux: UBI host tools (2)}
+ \frametitle{ubinize configuration file}
\begin{itemize}
- \item \code{ubinize} config file can contain several sections
+ \item Can contain several sections
\item Each section is describing a UBI volume
\item Example:
\end{itemize}
@@ -735,18 +738,6 @@ vol_flags=autoresize
\end{frame}
\begin{frame}
- \frametitle{Linux: flashing UBI/UBIFS howtos}
- \begin{itemize}
- \item See
- \url{http://free-electrons.com/blog/creating-flashing-ubi-ubifs-images/}
- for details about creating UBI and UBIFS images.
- \item See
- \url{http://www.linux-mtd.infradead.org/doc/ubi.html\#L_flasher_algo}
- for what is required when flashing UBI images.
- \end{itemize}
-\end{frame}
-
-\begin{frame}
\frametitle{Linux: Using a UBIFS filesystem as root filesystem}
\begin{itemize}
\item You just have to pass the following information on the kernel
@@ -787,21 +778,12 @@ ${bootargs_base} ${mtdparts}; bootz 0x81000000 - 0x82000000'}
\frametitle{Linux: Block emulation layers}
\begin{itemize}
\item Sometimes we need block devices to re-use existing block
- filesystems
- \item Particularly useful for read-only block filesystems like squashfs
+ filesystems, especially read-only ones like SquashFs
\item Linux provides two block emulation layers:
\begin{itemize}
\item \code{mtdblock}: block devices emulated on top of MTD devices
\item \code{ubiblock}: block devices emulated on top of UBI volumes
\end{itemize}
- \item For read access, using emulated block devices is exactly the same
- as using regular block devices
- \item Even if supported through the \code{mtdblock} emulation layer,
- writing on emulated block devices is highly discouraged
- \begin{itemize}
- \item the emulation layer does not properly deal with wear
- leveling and data retention issues occurring on the flash media
- \end{itemize}
\end{itemize}
\end{frame}
@@ -811,17 +793,18 @@ ${bootargs_base} ${mtdparts}; bootz 0x81000000 - 0x82000000'}
\item The \code{mtdblock} layer creates a block device for each MTD
device of the system
\item Usually named \code{/dev/mtdblockX}.
- \item Allows read/write block-level access. But bad blocks are not
+ \item Allows read/write block-level access. However bad blocks are not
handled, and no wear leveling is done for writes.
- \item For historical reasons JFFS2 filesystems require a block device
- to be mounted
- \item {\bf Do not write on mtdblock devices}
+ \item For historical reasons, JFFS2 and YAFFS2 filesystems require a
+ block device for the \code{mount} command.
+ \item {\bf Do not write on \code{mtdblock} devices}
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Linux: ubiblock}
\begin{itemize}
+ \item Implemented by Ezequiel Garcia from Free Electrons.
\item Preferred over \code{mtdblock} if UBI is available (UBI accounts
for data retention and wear leveling issues, while MTD does not)
\item The \code{ubiblock} layer creates {\bf read-only} block devices
@@ -834,7 +817,6 @@ ${bootargs_base} ${mtdparts}; bootz 0x81000000 - 0x82000000'}
\item Using the \code{ubiblock} utility provided by \code{mtd-utils}:
\code{ubiblock --create <ubi-volume-dev-file>}
\end{itemize}
-
\item Usually named \code{/dev/ubiblockX_Y}, where X is the UBI device
id and Y is the UBI volume id
\end{itemize}
@@ -847,6 +829,8 @@ ${bootargs_base} ${mtdparts}; bootz 0x81000000 - 0x82000000'}
\url{http://free-electrons.com/blog/managing-flash-storage-with-linux/}
\item Documentation on the linux-mtd website:\\
\url{http://www.linux-mtd.infradead.org/}
+ \item Details about creating UBI and UBIFS images:\\
+ \url{http://free-electrons.com/blog/creating-flashing-ubi-ubifs-images/}
\end{itemize}
\end{frame}
diff --git a/slides/sysdev-toolchains-definition/sysdev-toolchains-definition.tex b/slides/sysdev-toolchains-definition/sysdev-toolchains-definition.tex
index f6ff4c4..698748f 100644
--- a/slides/sysdev-toolchains-definition/sysdev-toolchains-definition.tex
+++ b/slides/sysdev-toolchains-definition/sysdev-toolchains-definition.tex
@@ -67,8 +67,8 @@
used for libraries
\item \code{objdump}, \code{readelf}, \code{size}, \code{nm},
\code{strings}, to inspect binaries. Very useful analysis tools!
- \item \code{strip}, to strip useless parts of binaries in order to
- reduce their size
+ \item \code{strip}, to strip parts of binaries that are just needed
+ for debugging (reducing their size).
\end{itemize}
\item \url{http://www.gnu.org/software/binutils/}
\item GPL license
More information about the training-materials-updates
mailing list