[bootlin/training-materials updates] master: Boot time slides: updates from previous session notes (8fd69c1f)
Michael Opdenacker
michael.opdenacker at bootlin.com
Sun Jun 20 21:52:43 CEST 2021
Repository : https://github.com/bootlin/training-materials
On branch : master
Link : https://github.com/bootlin/training-materials/commit/8fd69c1fd301f924ca46af46e80ee39693fc3683
>---------------------------------------------------------------
commit 8fd69c1fd301f924ca46af46e80ee39693fc3683
Author: Michael Opdenacker <michael.opdenacker at bootlin.com>
Date: Sun Jun 20 21:52:43 2021 +0200
Boot time slides: updates from previous session notes
Signed-off-by: Michael Opdenacker <michael.opdenacker at bootlin.com>
>---------------------------------------------------------------
8fd69c1fd301f924ca46af46e80ee39693fc3683
common/boneblack-sdcard-preparation.tex | 3 +-
.../boot-time-bootloader/boot-time-bootloader.tex | 21 +++----
.../boot-time-filesystems.tex | 8 ++-
slides/boot-time-measuring/boot-time-measuring.tex | 38 +++++-------
slides/boot-time-measuring/using-grabserial.dia | 69 +++++++++++++++++++++-
.../boot-time-principles/boot-time-principles.tex | 20 +++----
6 files changed, 106 insertions(+), 53 deletions(-)
diff --git a/common/boneblack-sdcard-preparation.tex b/common/boneblack-sdcard-preparation.tex
index 5035fa38..34810090 100644
--- a/common/boneblack-sdcard-preparation.tex
+++ b/common/boneblack-sdcard-preparation.tex
@@ -8,8 +8,7 @@ Our SD card needs to be split in two partitions:
the requirements of the AM335x SoC so that it can find the bootloader in
this partition. It should be a FAT32 partition. We will store the
bootloader (\code{MLO} and \code{u-boot.img}), the kernel image
- (\code{zImage}), the Device Tree (\code{am335x-boneblack.dtb}) and a
- special U-Boot script for the boot.
+ (\code{zImage})and the Device Tree (\code{am335x-boneblack.dtb}).
\item A second partition for the root filesystem. It can use
whichever filesystem type you want, but for our system, we'll use
diff --git a/slides/boot-time-bootloader/boot-time-bootloader.tex b/slides/boot-time-bootloader/boot-time-bootloader.tex
index b70fb138..95077c47 100644
--- a/slides/boot-time-bootloader/boot-time-bootloader.tex
+++ b/slides/boot-time-bootloader/boot-time-bootloader.tex
@@ -1,5 +1,7 @@
\section{Bootloader optimizations}
+\subsection{Generic bootloader optimizations}
+
\begin{frame}
\frametitle{Bootloader}
\begin{itemize}
@@ -32,11 +34,6 @@ Recompile U-Boot to remove features not needed in production
\item Remove the boot delay:\\
\code{setenv bootdelay 0}
\item This usually saves several seconds!
-\item Before you do that, recompile U-Boot with
- \kconfig{CONFIG_ZERO_BOOTDELAY_CHECK}, documented in
- \code{doc/README.autoboot}. It allows to stop the autoboot
- process by hitting a key even if the boot delay is set to
- \code{0}.
\end{itemize}
\end{frame}
@@ -66,13 +63,13 @@ This saved 56 ms on this ARM9 system (400 MHz)!
\begin{frame}
\frametitle{Bootloader: copy the exact kernel size}
\begin{itemize}
-\item When copying the kernel from flash to RAM, we still see
+\item When copying the kernel from {\bf raw} flash to RAM, we still see
many systems that copy too many bytes, not taking the
exact kernel size into account.
-\item In U-Boot, use the \code{nboot} command:\\
- \code{nboot ramaddr 0 nandoffset}
-\item U-Boot using the kernel size information stored in the
- \code{uImage} header to know how many bytes to copy.
+\item A solution is to store the exact size of the kernel in an environment
+ variable, and use it a kernel loading time.
+\item Of course, that's not needed when the kernel is loaded from a
+ filesystem, which knows how big the file is.
\end{itemize}
\end{frame}
@@ -151,9 +148,9 @@ Measured between \code{Booting kernel} and \code{Starting kernel ...}
\frametitle{Further U-Boot optimizations}
\begin{itemize}
\item Silence U-Boot console output. You will need to compile
- U-Boot with \kconfig{CONFIG_SILENT_CONSOLE} and
+ U-Boot with \projconfig{u-boot}{CONFIG_SILENT_CONSOLE} and
\code{setenv silent yes}.\\
- See \code{doc/README.silent} for details.
+ See \projfile{u-boot}{doc/README.silent} for details.
\end{itemize}
\end{frame}
diff --git a/slides/boot-time-filesystems/boot-time-filesystems.tex b/slides/boot-time-filesystems/boot-time-filesystems.tex
index 7e33444a..6a531d98 100644
--- a/slides/boot-time-filesystems/boot-time-filesystems.tex
+++ b/slides/boot-time-filesystems/boot-time-filesystems.tex
@@ -77,6 +77,8 @@ For raw flash storage
from 16 s to 0.8 s for a 128 MB partition.
\item Rather poor read and write performance,\\
compared to YAFFS2 and UBIFS.
+\item JFFS2 only makes sense on small storage space,
+ where UBI would have too much overhead.
\end{itemize}
\end{frame}
@@ -92,18 +94,18 @@ For raw flash storage
\begin{frame}
\frametitle{UBIFS}
-For raw flash storage
+For raw flash storage, on top of the UBI layer
\begin{itemize}
\item Advantages:
\begin{itemize}
\item Good read and write performance (similar to YAFFS2)
\item Other advantages: better for wear leveling (can operate on the
- whole UBI space, not only within a single partition).
+ whole UBI space, not only within a single partition).
\end{itemize}
\item Drawbacks:
\begin{itemize}
\item Not appropriate for small partitions (too much metadata
- overhead). Use JFFS2 or JAFFS2 instead.
+ overhead). Use JFFS2 or JAFFS2 instead.
\item Not so good mount time, because of the time needed
to initialize UBI ({\em UBI Attach}: at boot time or running
\code{ubi_attach} in user space).
diff --git a/slides/boot-time-measuring/boot-time-measuring.tex b/slides/boot-time-measuring/boot-time-measuring.tex
index d575f4f1..a6a166f7 100644
--- a/slides/boot-time-measuring/boot-time-measuring.tex
+++ b/slides/boot-time-measuring/boot-time-measuring.tex
@@ -55,6 +55,7 @@
\frametitle{Time measurement equipment: serial port}
\begin{columns}
\column{0.75\textwidth}
+\small
\begin{itemize}
\item Useful when you don't have monitoring hardware, or don't want to make
take any risk connecting wires to the hardware.
@@ -63,31 +64,19 @@
runs on a PC connected to the serial port.
\item On the board, requires a real serial port (directly connected to the CPU),
immediately usable from the earliest parts of the boot process.
+ Attaching a USB-to-serial dongle to a USB {\bf host} port on
+ the device won't do: USB is available much later and messages
+ go through more complex software stacks (loss of time accuracy).
\item Limitation: won't be able to time the "Power on" event in
an accurate way. But acceptable as you can assume that
the time to run the first stage bootloader is constant.
\end{itemize}
\column{0.25\textwidth}
% From https://openclipart.org/detail/173570/serial-db9-female-by-deusinvictus-173570
-\includegraphics[width=\textwidth]{slides/boot-time-measuring/serial_db9_female.pdf}
-\end{columns}
-\end{frame}
-
-\begin{frame}
-\frametitle{Time measurement equipment: USB to serial}
-\begin{columns}
- \column{0.65\textwidth}
- \begin{itemize}
- \item Serial ports over USB {\bf device} are fine if there's an on-board
- serial-to-USB chip directly connected to the CPU serial port (very frequent).
- \item Attaching a USB-to-serial dongle to a USB {\bf host} port on
- the device won't do: USB is available much later and messages
- go through more complex software stacks (loss of time accuracy).
- \item All development boards have a standard or USB serial port.
- \end{itemize}
- \column{0.35\textwidth}
- % From https://openclipart.org/detail/135721/usb-cable-by-gsagri04
- \includegraphics[width=\textwidth]{slides/boot-time-measuring/GS_USB_Cable.pdf}
+\includegraphics[width=\textwidth]{slides/boot-time-measuring/serial_db9_female.pdf}\\
+\vspace{1cm}
+% From https://openclipart.org/detail/135721/usb-cable-by-gsagri04
+\includegraphics[width=\textwidth]{slides/boot-time-measuring/GS_USB_Cable.pdf}
\end{columns}
\end{frame}
@@ -95,8 +84,8 @@
\frametitle{grabserial}
\url{https://elinux.org/Grabserial} (by Tim Bird)
\begin{itemize}
-\item A Python script to add timestamps to messages coming from a
- serial console.
+\item A Python script to add timestamps to messages received on a
+ serial console.
\item Key advantage: starts counting very early (bootstrap and bootloader)
\item Another advantage: no overhead on the target, because run on the host machine.
\item Drawbacks: may not be precise enough. Can't measure power up time.
@@ -121,7 +110,8 @@ was received at that time.}
\begin{itemize}
\item You can interrupt \code{grabserial} manually (with
\code{[Ctrl][c]}) when you have gone far enough.
- \item The \code{-m} and \code{-q} options actually expect a regular expression.
+ \item The \code{-m} ({\bf m}atch start pattern) and \code{-q} ({\bf
+ q}uit pattern) options actually expect a regular expression.
A normal string may not match in the middle of a line.
\item Example: you may have to replace \code{-m "Starting kernel"} by
\code{-m ".*Starting Kernel.*"}.
@@ -134,7 +124,9 @@ Later, we will see specific resources for measuring time
\begin{itemize}
\item \code{time} for measuring application time
\item \code{strace} for application tracing
- \item \code{bootchartd} for tracing the execution of system services
+ \item \code{bootchartd} for tracing the execution of system services.
+ \item More specifically, \code{systemd-analyze} if your system
+ is started with {\em Systemd}.
\item \kconfig{CONFIG_PRINTK_TIME} and \code{initcall_debug} for
tracing kernel code and functions.
\end{itemize}
diff --git a/slides/boot-time-measuring/using-grabserial.dia b/slides/boot-time-measuring/using-grabserial.dia
index 0281e664..b8644ccc 100644
--- a/slides/boot-time-measuring/using-grabserial.dia
+++ b/slides/boot-time-measuring/using-grabserial.dia
@@ -227,12 +227,12 @@
<dia:point val="10.1,5.975"/>
</dia:attribute>
<dia:attribute name="obj_bb">
- <dia:rectangle val="10.1,5.23644;31.0975,15.7728"/>
+ <dia:rectangle val="10.1,5.21303;31.1209,15.8196"/>
</dia:attribute>
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
- <dia:string>#$ ~/bin/grabserial -d /dev/ttyACM0 -m RomBOOT -t -e 30
+ <dia:string>#$ ~/bin/grabserial -d /dev/ttyACM0 -m RomBOOT -t -e 30 -o boot.log
[0.000002 0.000002] RomBOOT
[0.054440 0.054440]
[0.054594 0.000154]
@@ -662,5 +662,70 @@ the previous time stamp#</dia:string>
<dia:enum val="3"/>
</dia:attribute>
</dia:object>
+ <dia:object type="Standard - ZigZagLine" version="1" id="O18">
+ <dia:attribute name="obj_pos">
+ <dia:point val="26.95,6.2"/>
+ </dia:attribute>
+ <dia:attribute name="obj_bb">
+ <dia:rectangle val="26.5882,6.15;39.5,8.75"/>
+ </dia:attribute>
+ <dia:attribute name="orth_points">
+ <dia:point val="26.95,6.2"/>
+ <dia:point val="26.95,7.35"/>
+ <dia:point val="39.45,7.35"/>
+ <dia:point val="39.45,8.7"/>
+ </dia:attribute>
+ <dia:attribute name="orth_orient">
+ <dia:enum val="1"/>
+ <dia:enum val="0"/>
+ <dia:enum val="1"/>
+ </dia:attribute>
+ <dia:attribute name="autorouting">
+ <dia:boolean val="false"/>
+ </dia:attribute>
+ <dia:attribute name="start_arrow">
+ <dia:enum val="22"/>
+ </dia:attribute>
+ <dia:attribute name="start_arrow_length">
+ <dia:real val="0.5"/>
+ </dia:attribute>
+ <dia:attribute name="start_arrow_width">
+ <dia:real val="0.5"/>
+ </dia:attribute>
+ </dia:object>
+ <dia:object type="Standard - Text" version="1" id="O19">
+ <dia:attribute name="obj_pos">
+ <dia:point val="38.025,9.49856"/>
+ </dia:attribute>
+ <dia:attribute name="obj_bb">
+ <dia:rectangle val="38.025,8.76;42.4025,10.4963"/>
+ </dia:attribute>
+ <dia:attribute name="text">
+ <dia:composite type="text">
+ <dia:attribute name="string">
+ <dia:string>#Copy the output
+to a file too#</dia:string>
+ </dia:attribute>
+ <dia:attribute name="font">
+ <dia:font family="Latin Modern Sans" style="0" name="Courier"/>
+ </dia:attribute>
+ <dia:attribute name="height">
+ <dia:real val="0.80000000000000004"/>
+ </dia:attribute>
+ <dia:attribute name="pos">
+ <dia:point val="38.025,9.49856"/>
+ </dia:attribute>
+ <dia:attribute name="color">
+ <dia:color val="#0000ffff"/>
+ </dia:attribute>
+ <dia:attribute name="alignment">
+ <dia:enum val="0"/>
+ </dia:attribute>
+ </dia:composite>
+ </dia:attribute>
+ <dia:attribute name="valign">
+ <dia:enum val="3"/>
+ </dia:attribute>
+ </dia:object>
</dia:layer>
</dia:diagram>
diff --git a/slides/boot-time-principles/boot-time-principles.tex b/slides/boot-time-principles/boot-time-principles.tex
index 54d6537f..f8b9479c 100644
--- a/slides/boot-time-principles/boot-time-principles.tex
+++ b/slides/boot-time-principles/boot-time-principles.tex
@@ -77,17 +77,15 @@ Donald Knuth}
\begin{frame}
\frametitle{Build automation}
\begin{itemize}
-\item Very important to automate the way the root filesystem is built,
- if not done yet. That's always the first thing we do in boot time
- reduction projects, and it's worth investing 1 or 2 days doing
- this.
-\item Otherwise, you may lose existing optimizations or introduce new bugs
- when making further optimizations. Without a build system,
- you will waste a lot of time too.
-\item Can be done through build systems such as Buildroot or Yocto,
- or using the original build automation of the project.
-\item Can also be done for kernel and bootloader optimizations, though
- the need is less critical.
+\item Build automation is a very important part of a successful project.
+\item So, through the build system, you should automate any remaining
+ manual step and all the new optimizations that you will implement
+ to reduce boot time. Without such automation, you may forget some
+ optimizations, or introduce new bugs when making further optimizations.
+\item Boot time optimization projects required countless rebuilds too,
+ automating image generation will save a lot of time too.
+\item Kernel and bootloader compiling and optimizations can also be
+ taken care of by the build system, though the need is less critical.
\end{itemize}
\end{frame}
More information about the training-materials-updates
mailing list