[bootlin/training-materials updates] master: add formatting to bash/uboot commands (dc88032a)
Thomas Petazzoni
thomas.petazzoni at bootlin.com
Fri Oct 29 10:46:36 CEST 2021
Repository : https://github.com/bootlin/training-materials
On branch : master
Link : https://github.com/bootlin/training-materials/commit/dc88032a70bd3b989455a9ddf4f8e80c01bd4f98
>---------------------------------------------------------------
commit dc88032a70bd3b989455a9ddf4f8e80c01bd4f98
Author: Manuel Reis <mluis.reis at gmail.com>
Date: Sat Apr 10 10:59:31 2021 +0100
add formatting to bash/uboot commands
created new listings environments to highlight and control breaklines
in different settigns, such as uboot, bash, terminal ouput, file
input
new environments for multi-line, single line and inline are now
available
Signed-off-by: Manuel Reis <mluis.reis at gmail.com>
>---------------------------------------------------------------
dc88032a70bd3b989455a9ddf4f8e80c01bd4f98
common/labs-header.tex | 57 +++++++-----
common/sysdev-kernel-cross-compiling-stm32mp1.tex | 19 ++--
labs/setup/setup.tex | 6 +-
.../sysdev-application-debugging.tex | 20 ++---
.../sysdev-application-development.tex | 4 +-
.../sysdev-block-filesystems-qemu.tex | 22 ++---
.../sysdev-block-filesystems-stm32.tex | 8 +-
labs/sysdev-real-time/sysdev-real-time.tex | 32 +++----
labs/sysdev-thirdparty/sysdev-thirdparty.tex | 81 ++++++++---------
labs/sysdev-tinysystem/sysdev-tinysystem.tex | 10 ++-
labs/sysdev-toolchain/sysdev-toolchain.tex | 52 +++++------
labs/sysdev-u-boot-qemu/sysdev-u-boot-qemu.tex | 100 ++++++++-------------
labs/sysdev-u-boot-stm32/sysdev-u-boot-stm32.tex | 96 ++++++++------------
labs/sysdev-u-boot/sysdev-u-boot.tex | 46 +++++-----
14 files changed, 254 insertions(+), 299 deletions(-)
diff --git a/common/labs-header.tex b/common/labs-header.tex
index 00b38937..68bb7cd6 100644
--- a/common/labs-header.tex
+++ b/common/labs-header.tex
@@ -22,43 +22,58 @@
columns=fullflexible
}
-% environment for long lines of code/cmd input with backslash at end of line
-\lstnewenvironment{terminalinput}
-{
+% Multi-line command environments ---------------------------------------------
+
+\lstnewenvironment{bashinput}{
\lstset{
prebreak=\textbackslash,
alsoletter={()[].=:-},
}}{}
-\surroundwithmdframed[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=1pt, innerbottommargin=1pt, backgroundcolor=lightgray!20]{terminalinput}
+\lstnewenvironment{terminaloutput}{\lstset{
+ breakautoindent=false,
+ alsoletter={()[].=:-},
+ breakindent=0pt,
+}}{}
+
+\lstnewenvironment{fileinput}{\lstset{
+ breakautoindent=false,
+ alsoletter={()[].=:-_},
+ breakindent=0pt,
+}}{}
+
+\lstnewenvironment{ubootinput}{\lstset{
+ alsoletter={()[].=:-_},
+}}{}
+
+% Background for muli-line environments
-\def\clinput{\lstinline[basicstyle=\ttfamily]}
+\surroundwithmdframed[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=1pt, innerbottommargin=1pt, backgroundcolor=blue!5]{ubootinput}
-\newcommand\ubootcli[1]{\colorbox{mygray}{\lstinline[#1]}}
+\surroundwithmdframed[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=1pt, innerbottommargin=1pt, backgroundcolor=lightgray!20]{bashinput}
+
+% inline commands -------------------------------------------------------------
+\def\inlinebash#1{%
+ \colorbox{lightgray!20}{\lstinline{#1}}%
+}
+
+\def\inlineuboot#1{
+ \colorbox{blue!5}{\lstinline{#1}}%
+}
\def\inlinecode#1{%
- \colorbox{lightgray!15}{\lstinline{#1}}%
+ {\lstinline{#1}}%
}
+\def\inlinefile{\lstinline[basicstyle=\ttfamily]}
+
+% single line commands --------------------------------------------------------
\newcommand\bashcmd[1]{\begin{mdframed}[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=4pt, innerbottommargin=4pt,backgroundcolor=lightgray!20]{\lstinline{#1}}\end{mdframed}}
\newcommand\ubootcmd[1]{\begin{mdframed}[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=4pt, innerbottommargin=4pt,backgroundcolor=blue!5]{\lstinline[]{#1}}\end{mdframed}}
-% environment for long lines of u-boot cmd input without backslash at end of line
-\lstnewenvironment{ubootinput}{\lstset{
- alsoletter={()[].=:-},
-}}{}
-
-\surroundwithmdframed[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=1pt, innerbottommargin=1pt, backgroundcolor=blue!5]{ubootinput}
-
-% following lines aligned at left margin
-\lstnewenvironment{terminaloutput}{\lstset{
- breakautoindent=false,
- alsoletter={()[].=:-},
- breakindent=0pt,
-}}{}
-%\surroundwithmdframed[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=1pt, innerbottommargin=1pt, backgroundcolor=blue!5]{terminaloutput}
+% others... ------------------------------------------------------------------
\newcommand{\sourcecode}[1]{\verbatimtabinput{../#1}{\small (Source code link:
\url{https://raw.githubusercontent.com/bootlin/training-materials/master/#1})}}
diff --git a/common/sysdev-kernel-cross-compiling-stm32mp1.tex b/common/sysdev-kernel-cross-compiling-stm32mp1.tex
index f51f604c..786529b3 100644
--- a/common/sysdev-kernel-cross-compiling-stm32mp1.tex
+++ b/common/sysdev-kernel-cross-compiling-stm32mp1.tex
@@ -7,23 +7,28 @@ previously.
Insert the SD card in your PC, it will get auto-mounted. Copy the
kernel and device tree:
-\small
-\code{sudo cp arch/arm/boot/dts/stm32mp157a-dk1.dtb arch/arm/boot/zImage /media/training/boot/}\\
-\code{sudo umount /dev/mmcblk0p4}
+\begin{bashinput}
+$ sudo cp arch/arm/boot/dts/stm32mp157a-dk1.dtb arch/arm/boot/zImage /media/training/boot/
+$ sudo umount /dev/mmcblk0p4
+\end{bashinput}
\normalsize
Insert the SD card back in the board and reset it. You should now be
able to load the DTB and kernel image from the SD card and boot with:
-\code{ext2load mmc 0:4 0xc0000000 zImage}\\
-\code{ext2load mmc 0:4 0xc4000000 stm32mp157a-dk1.dtb}\\
-\code{bootz 0xc0000000 - 0xc4000000}
+\begin{ubootinput}
+=> ext2load mmc 0:4 0xc0000000 zImage
+=> ext2load mmc 0:4 0xc4000000 stm32mp157a-dk1.dtb
+=> bootz 0xc0000000 - 0xc4000000
+\end{ubootinput}
You are now ready to modify \code{bootcmd} to boot the board
from SD card. But first, save the settings for booting from
\code{tftp}:
-\code{setenv bootcmdtftp \${bootcmd}}
+\begin{ubootinput}
+=> setenv bootcmdtftp %\$%{bootcmd}
+\end{ubootinput}
This will be useful to switch back to \code{tftp} booting mode
later in the labs.
diff --git a/labs/setup/setup.tex b/labs/setup/setup.tex
index 17a70749..d577f398 100644
--- a/labs/setup/setup.tex
+++ b/labs/setup/setup.tex
@@ -7,11 +7,11 @@ set of data (kernel images, kernel configurations, root filesystems
and more). Download and extract its tarball from a terminal:
%{\small % leaving here as a marker if font sizes are needed
-\begin{terminalinput}
+\begin{bashinput}
$ cd
$ wget %\sessionurl%/__SESSION_NAME__-labs.tar.xz
$ tar xvf __SESSION_NAME__-labs.tar.xz
-\end{terminalinput}
+\end{bashinput}
%}
Lab data are now available in an \code{__SESSION_NAME__-labs} directory in
your home directory. This directory contains directories and files used in
@@ -64,7 +64,7 @@ Can be useful throughout any of the labs
user may no longer be able to handle the corresponding generated
files. In this case, use the \code{chown -R} command to give the new
files back to your regular user.\\
- Example: \code{chown -R myuser.myuser linux/}
+ Example: \inlinebash{$ chown -R myuser.myuser linux/}
\end{itemize}
diff --git a/labs/sysdev-application-debugging/sysdev-application-debugging.tex b/labs/sysdev-application-debugging/sysdev-application-debugging.tex
index d95d2bc0..9a5bc28d 100644
--- a/labs/sysdev-application-debugging/sysdev-application-debugging.tex
+++ b/labs/sysdev-application-debugging/sysdev-application-debugging.tex
@@ -68,9 +68,9 @@ you don't have the source code.
Update the PATH:
%\footnotesize
-\begin{terminalinput}
+\begin{bashinput}
$ export PATH=$HOME/__SESSION_NAME__-labs/debugging/buildroot-2021.02.<n>/output/host/bin:$PATH
-\end{terminalinput}
+\end{bashinput}
\normalsize
With your cross-compiling toolchain
@@ -135,31 +135,31 @@ present in the default \code{/lib} and \code{/usr/lib} directories on
your workstation. This is done by setting the \code{gdb} \code{sysroot}
variable (on one line):
-\begin{terminalinput}
+\begin{bashinput}
(gdb) set sysroot /home/<user>/__SESSION_NAME__-labs/debugging/\
buildroot-2021.02.<n>/output/staging
-\end{terminalinput}
+\end{bashinput}
Of course, replace \code{<user>} by your actual user name.
And tell \code{gdb} to connect to the remote system:
-\begin{terminalinput}
+\begin{bashinput}
(gdb) target remote <target-ip-address>:2345
-\end{terminalinput}
+\end{bashinput}
Then, use \code{gdb} as usual to set breakpoints, look at the source
code, run the application step by step, etc. Graphical versions of
\code{gdb}, such as \code{ddd} can also be used in the same way.
In our case, we'll just start the program and wait for it to hit
the segmentation fault:
-\begin{terminalinput}
+\begin{bashinput}
(gdb) continue
-\end{terminalinput}
+\end{bashinput}
You could then ask for a backtrace to see where this happened:
-\begin{terminalinput}
+\begin{bashinput}
(gdb) backtrace
-\end{terminalinput}
+\end{bashinput}
This will tell you that the segmentation fault occurred in a function
of the C library, called by our program. This should help you in
diff --git a/labs/sysdev-application-development/sysdev-application-development.tex b/labs/sysdev-application-development/sysdev-application-development.tex
index 5d17c64f..3d1ff4f0 100644
--- a/labs/sysdev-application-development/sysdev-application-development.tex
+++ b/labs/sysdev-application-development/sysdev-application-development.tex
@@ -23,9 +23,9 @@ for the headers and libraries).
Let's add this directory to our \code{PATH}:
-\begin{terminalinput}
+\begin{bashinput}
$ export PATH=$HOME/__SESSION_NAME__-labs/buildroot/buildroot-2021.02.X/output/host/usr/bin:$PATH
-\end{terminalinput}
+\end{bashinput}
\normalsize
Let's try to compile the application:
diff --git a/labs/sysdev-block-filesystems-qemu/sysdev-block-filesystems-qemu.tex b/labs/sysdev-block-filesystems-qemu/sysdev-block-filesystems-qemu.tex
index 4d412a46..86ca1cfd 100644
--- a/labs/sysdev-block-filesystems-qemu/sysdev-block-filesystems-qemu.tex
+++ b/labs/sysdev-block-filesystems-qemu/sysdev-block-filesystems-qemu.tex
@@ -43,15 +43,11 @@ 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}
+\bashcmd{$ sudo losetup -f --show --partscan sd.img}
And then format the third partition:
-\begin{verbatim}
-sudo mkfs.ext4 -L data /dev/loop<x>p3
-\end{verbatim}
+\bashcmd{$ 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
@@ -60,10 +56,10 @@ 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}
+\begin{bashinput}
+$ sudo umount /mnt/data
+$ sudo losetup -d /dev/loop<x>
+\end{bashinput}
Now, restart QEMU and from the Linux command line and
mount this third partition on \code{/www/upload/files}.
@@ -136,13 +132,11 @@ 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}
+\ubootcmd{=> 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
+Type \inlineuboot{=> reset} in U-Boot to reboot the board and make
sure that your system still boots fine.
diff --git a/labs/sysdev-block-filesystems-stm32/sysdev-block-filesystems-stm32.tex b/labs/sysdev-block-filesystems-stm32/sysdev-block-filesystems-stm32.tex
index 680628cf..06534cdb 100644
--- a/labs/sysdev-block-filesystems-stm32/sysdev-block-filesystems-stm32.tex
+++ b/labs/sysdev-block-filesystems-stm32/sysdev-block-filesystems-stm32.tex
@@ -43,9 +43,7 @@ We're going to use the SD card for our block device.
Plug the SD card in your workstation. If partitions are mounted,
unmount them:
-\begin{verbatim}
-$ sudo umount /dev/mmcblk0p*
-\end{verbatim}
+\bashcmd{$ sudo umount /dev/mmcblk0p*}
Using \code{parted}, add two partitions, starting from the beginning
of the remaining space, with the following properties:
@@ -66,9 +64,7 @@ Use \code{quit} when you are done.
Using the \code{mkfs.ext4} create a journaled file system on the
sixth partition of the SD card:
-\begin{verbatim}
-sudo mkfs.ext4 -L data -E nodiscard /dev/mmcblk0p6
-\end{verbatim}
+\bashcmd{$ sudo mkfs.ext4 -L data -E nodiscard /dev/mmcblk0p6}
\begin{itemize}
\item \code{-L} assigns a volume name to the partition
diff --git a/labs/sysdev-real-time/sysdev-real-time.tex b/labs/sysdev-real-time/sysdev-real-time.tex
index 28915287..8adb7afe 100644
--- a/labs/sysdev-real-time/sysdev-real-time.tex
+++ b/labs/sysdev-real-time/sysdev-real-time.tex
@@ -81,9 +81,9 @@ directory.
The last thing to do is to add a few files that we will need in our
tests:
-\begin{terminalinput}
+\begin{bashinput}
$ cp data/* nfsroot/root
-\end{terminalinput}
+\end{bashinput}
\subsection{Downloading Linux kernel sources and patches}
@@ -123,9 +123,9 @@ test application with the toolchain that Buildroot used.
Let's configure our \code{PATH} to use this toolchain:
%\simall
-\begin{terminalinput}
+\begin{bashinput}
$ export PATH=$HOME/__SESSION_NAME__-labs/realtime/buildroot-2021.02.X/output/host/usr/bin:$PATH
-\end{terminalinput}
+\end{bashinput}
\normalsize
Have a look at the \code{rttest.c} source file available in
@@ -133,9 +133,9 @@ Have a look at the \code{rttest.c} source file available in
resolution of the \code{CLOCK_MONOTONIC} clock.
Now compile this program:
-\begin{terminalinput}
+\begin{bashinput}
$ arm-linux-gnueabihf-gcc -o rttest rttest.c
-\end{terminalinput}
+\end{bashinput}
Execute the program on the board. Is the clock resolution good or bad?
Compare it to the timer tick of your system, as defined by
@@ -223,27 +223,27 @@ modules to our kernel sources, we will use a helper script provided by
Xenomai itself. Go to Buildroot \code{output/build/xenomai-3.1/}
folder, and run:
-\begin{terminalinput}
+\begin{bashinput}
$ ./scripts/prepare-kernel.sh \
--linux=$HOME/embedded-linux-labs/realtime/linux-4.19.144/ \
--ipipe=$HOME/embedded-linux-labs/realtime/ipipe-core-4.19.144-arm-10.patch \
--arch=arm
-\end{terminalinput}
+\end{bashinput}
Now that your kernel is patched, you can configure it:
-\begin{terminalinput}
+\begin{bashinput}
$ make ARCH=arm sama5_defconfig
-\end{terminalinput}
+\end{bashinput}
Make sure \code{CONFIG_XENOMAI} is enabled.
We are going to use the Linaro toochain used by Buildroot to compile the
kernel, so we will need to update our \code{CROSS_COMPILE} setting:
-\begin{terminalinput}
+\begin{bashinput}
$ export CROSS_COMPILE=arm-linux-gnueabihf-
-\end{terminalinput}
+\end{bashinput}
Build your kernel. Copy the kernel image and the Device Tree to your TFTP
directory, and boot this new kernel.
@@ -255,21 +255,21 @@ the Xenomai user-space libraries. This can be done by using the
\code{xeno-config} script provided by Xenomai, as follows:
%\small
-\begin{terminalinput}
+\begin{bashinput}
$ cd $HOME/__SESSION_NAME__-labs/realtime/nfsroot/root
$ export PATH=$HOME/__SESSION_NAME__-labs/realtime/buildroot-2021.02.X/output/host/usr/bin:$PATH
$ arm-linux-gnueabihf-gcc -o rttest rttest.c \
$(DESTDIR=../../buildroot-2021.02.X/output/staging/ \
../../buildroot-2021.02.X/output/staging/usr/bin/xeno-config \
--skin=posix --cflags --ldflags)
-\end{terminalinput}
+\end{bashinput}
\normalsize
Run the following commands on the board:
-\begin{terminalinput}
+\begin{bashinput}
$ echo 0 > /proc/xenomai/latency
-\end{terminalinput}
+\end{bashinput}
This will disable the timer compensation feature of Xenomai. This
feature allows Xenomai to adjust the timer programming to take into
diff --git a/labs/sysdev-thirdparty/sysdev-thirdparty.tex b/labs/sysdev-thirdparty/sysdev-thirdparty.tex
index c3840adf..245833ec 100644
--- a/labs/sysdev-thirdparty/sysdev-thirdparty.tex
+++ b/labs/sysdev-thirdparty/sysdev-thirdparty.tex
@@ -134,20 +134,20 @@ the time, \code{autoconf} comes with \code{automake}, that generates
Makefiles from \code{Makefile.am} files. So alsa-lib uses a rather
common build system. Let's try to configure and build it:
-\begin{terminalinput}
+\begin{bashinput}
$ ./configure
$ make
-\end{terminalinput}
+\end{bashinput}
You can see that the files are getting compiled with gcc, which
generates code for x86 and not for the target platform. This is
obviously not what we want, so we clean-up the object and tell the
configure script to use the ARM cross-compiler:
-\begin{terminalinput}
+\begin{bashinput}
$ make clean
$ CC=arm-linux-gcc ./configure
-\end{terminalinput}
+\end{bashinput}
Of course, the \code{arm-linux-gcc} cross-compiler must be in your
\code{PATH} prior to running the configure script. The \code{CC} environment
@@ -212,17 +212,17 @@ The \code{libasound.so*} files are a dynamic version of the
library. The shared library itself is \code{libasound.so.2.0.0}, it has
been generated by the following command line:
-\begin{terminalinput}
+\begin{bashinput}
$ arm-linux-gcc -shared conf.o confmisc.o input.o output.o async.o error.o dlmisc.o socket.o shmarea.o userfile.o names.o -lm -ldl -lpthread -lrt -Wl,-soname -Wl,libasound.so.2 -o libasound.so.2.0.0
-\end{terminalinput}
+\end{bashinput}
And creates the symbolic links \code{libasound.so} and
\code{libasound.so.2}.
-\begin{terminalinput}
+\begin{bashinput}
$ ln -s libasound.so.2.0.0 libasound.so.2
$ ln -s libasound.so.2.0.0 libasound.so
-\end{terminalinput}
+\end{bashinput}
These symlinks are needed for two different reasons:
@@ -275,10 +275,10 @@ installed in \code{/usr/local/lib}, the headers in
the libraries to be installed in the \code{/usr} prefix, so let's tell
the \code{configure} script about this:
-\begin{terminalinput}
+\begin{bashinput}
$ CC=arm-linux-gcc ./configure --host=arm-linux --disable-python --prefix=/usr
$ make
-\end{terminalinput}
+\end{bashinput}
For this library, this option may not change anything to the resulting
binaries, but for safety, it is always recommended to make sure that
@@ -392,11 +392,11 @@ can be found: there are not in the default directory
Let's use it:
-\begin{terminalinput}
+\begin{bashinput}
$ CPPFLAGS=-I$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \%\linebreak
CC=arm-linux-gcc %\% \linebreak
./configure --host=arm-linux --prefix=/usr
-\end{terminalinput}
+\end{bashinput}
Now, it should stop a bit later, this time with the error:
\begin{verbatim}
@@ -423,12 +423,12 @@ help text of the \code{configure} script:
Let's use this \code{LDFLAGS} variable:
-\begin{terminalinput}
+\begin{bashinput}
$ LDFLAGS=-L$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr
-\end{terminalinput}
+\end{bashinput}
Once again, it should fail a bit further down the tests, this time
complaining about a missing {\em curses helper header}. {\em curses}
@@ -441,13 +441,13 @@ Of course, if we wanted it, we would have had to build {\em ncurses} first,
just like we built {\em alsa-lib}. We will also need to disable support
for {\em xmlto} that generates the documentation.
-\begin{terminalinput}
+\begin{bashinput}
$ LDFLAGS=-L$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr \
--disable-alsamixer --disable-xmlto
-\end{terminalinput}
+\end{bashinput}
Then, run the compilation with \code{make}. Hopefully, it works!
@@ -574,14 +574,12 @@ So, we have:
Now, let's make the installation in the {\em staging} space:
-\begin{verbatim}
-make DESTDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/ install
-\end{verbatim}
+\bashcmd{$ make DESTDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/ install}
Then, let's install only the necessary files in the {\em target}
space, manually:
-\begin{terminalinput}
+\begin{bashinput}
$ cd ..
$ cp -a staging/usr/bin/a* staging/usr/bin/speaker-test target/usr/bin/
$ cp -a staging/usr/sbin/alsa* target/usr/sbin
@@ -592,7 +590,7 @@ $ mkdir -p target/usr/share/alsa/pcm
$ cp -a staging/usr/share/alsa/alsa.conf* target/usr/share/alsa/
$ cp -a staging/usr/share/alsa/cards target/usr/share/alsa/
$ cp -a staging/usr/share/alsa/pcm/default.conf target/usr/share/alsa/pcm/
-\end{terminalinput}
+\end{bashinput}
And we're finally done with {\em alsa-utils}!
@@ -634,11 +632,11 @@ classical \code{DESTDIR} mechanism:
And finally, only install manually in the {\em target} space the files
needed at runtime:
-\begin{terminalinput}
+\begin{bashinput}
$ cd ..
$ cp -a staging/usr/lib/libogg.so.0* target/usr/lib/
$ arm-linux-strip target/usr/lib/libogg.so.0.8.4
-\end{terminalinput}
+\end{bashinput}
Done with {\em libogg}!
@@ -664,11 +662,11 @@ By running \code{./configure --help}, you will find the
\code{--with-ogg-libraries} and \code{--with-ogg-includes} options.
Use these:
-\begin{terminalinput}
+\begin{bashinput}
$ CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr \
--with-ogg-includes=$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \
--with-ogg-libraries=$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/lib
-\end{terminalinput}
+\end{bashinput}
Then, compile the library:
@@ -680,13 +678,13 @@ Install it in the {\em staging} space:
And install only the required files in the {\em target} space:
-\begin{terminalinput}
+\begin{bashinput}
$ cd ..
$ cp -a staging/usr/lib/libvorbis.so.0* target/usr/lib/
$ arm-linux-strip target/usr/lib/libvorbis.so.0.4.9
$ cp -a staging/usr/lib/libvorbisfile.so.3* target/usr/lib/
$ arm-linux-strip target/usr/lib/libvorbisfile.so.3.3.8
-\end{terminalinput}
+\end{bashinput}
And we're done with {\em libvorbis}!
@@ -698,11 +696,11 @@ Now, let's work on {\em libao}. Download the 1.2.0 version from
Configuring {\em libao} is once again fairly easy, and similar to
every sane autotools based build system:
-\begin{terminalinput}
+\begin{bashinput}
$ LDFLAGS=-L$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr
-\end{terminalinput}
+\end{bashinput}
Of course, compile the library:
@@ -716,18 +714,18 @@ classical \code{DESTDIR} mechanism:
And finally, install manually the only needed files at runtime in the
{\em target} space:
-\begin{terminalinput}
+\begin{bashinput}
$ cd ..
$ cp -a staging/usr/lib/libao.so.4* target/usr/lib/
$ arm-linux-strip target/usr/lib/libao.so.4.1.0
-\end{terminalinput}
+\end{bashinput}
We will also need the alsa plugin that is loaded dynamically by
{\em libao} at startup:
-\begin{terminalinput}
+\begin{bashinput}
$ mkdir -p target/usr/lib/ao/plugins-4/
$ cp -a staging/usr/lib/ao/plugins-4/libalsa.so target/usr/lib/ao/plugins-4/
-\end{terminalinput}
+\end{bashinput}
Done with {\em libao}!
@@ -754,12 +752,12 @@ configuration options:
So, let's begin with our usual \code{configure} line:
-\begin{terminalinput}
+\begin{bashinput}
$ LDFLAGS=-L$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr
-\end{terminalinput}
+\end{bashinput}
At the end, you should see the following warning:
@@ -834,24 +832,21 @@ Then, let's run the configuration of the vorbis-tools again, passing
the \code{PKG_CONFIG_LIBDIR} and \code{PKG_CONFIG_SYSROOT_DIR}
environment variables:
-\begin{terminalinput}
+\begin{bashinput}
$ LDFLAGS=-L$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/lib \
CPPFLAGS=-I$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \
PKG_CONFIG_LIBDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/lib/pkgconfig \
PKG_CONFIG_SYSROOT_DIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging \
CC=arm-linux-gcc \
./configure --host=arm-linux --prefix=/usr
-\end{terminalinput}
+\end{bashinput}
\normalsize
Now, the \code{configure} script should end properly, we can now start the
compilation:
-\begin{verbatim}
-make
-\end{verbatim}
+\bashcmd{$ make}
It should fail with the following cryptic message:
-%\footnotesize
\begin{terminaloutput}
make[2]: Entering directory '/home/tux/__SESSION_NAME__-labs/thirdparty/vorbis-tools-1.4.0/ogg123'
if arm-linux-gcc -DSYSCONFDIR=\"/usr/etc\" -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include -I../include -I../intl -I/home/tux/__SESSION_NAME__-labs/thirdparty/staging/usr/include -O2 -Wall -ffast-math -fsigned-char -g -O2 -MT audio.o -MD -MP -MF ".deps/audio.Tpo" -c -o audio.o audio.c; \
@@ -877,11 +872,11 @@ Now, install the vorbis-tools to the {\em staging} space using:
And then install them in the {\em target} space:
-\begin{terminalinput}
+\begin{bashinput}
$ cd ..
$ cp -a staging/usr/bin/ogg* target/usr/bin
$ arm-linux-strip target/usr/bin/ogg*
-\end{terminalinput}
+\end{bashinput}
You can now test that everything works! Run \code{ogg123} on the
sample file found in \code{thirdparty/data}.
diff --git a/labs/sysdev-tinysystem/sysdev-tinysystem.tex b/labs/sysdev-tinysystem/sysdev-tinysystem.tex
index 8024cf7e..647e824c 100644
--- a/labs/sysdev-tinysystem/sysdev-tinysystem.tex
+++ b/labs/sysdev-tinysystem/sysdev-tinysystem.tex
@@ -57,7 +57,9 @@ package if you don't have it yet. Once installed, edit the
\code{/etc/exports} file as root to add the following line, assuming that the
IP address of your board will be \code{192.168.0.100}:
-\clinput{/home/<user>/__SESSION_NAME__-labs/tinysystem/nfsroot 192.168.0.100(rw,no_root_squash,no_subtree_check)}
+\begin{fileinput}
+/home/<user>/__SESSION_NAME__-labs/tinysystem/nfsroot 192.168.0.100(rw,no_root_squash,no_subtree_check)
+\end{fileinput}
Of course, replace \code{<user>} by your actual user name.
@@ -136,7 +138,7 @@ To configure BusyBox, we won't be able to use \code{make xconfig},
which is currently broken for BusyBox in Ubuntu 20.04,
because it requires an old version of the Qt library.
-So, let's use \code{make menuconfig}.
+So, let's use \inlinebash{$ make menuconfig}.
Now, configure BusyBox with the configuration file provided in the
\code{data/} directory (remember that the Busybox configuration file
@@ -155,7 +157,7 @@ specify the installation directory for BusyBox\footnote{You will find
this setting in \code{Settings -> Install Options -> BusyBox installation prefix}.}.
It should be the path to your \code{nfsroot} directory.
-Now run \code{make install} to install BusyBox in this directory.
+Now run \inlinebash{$ make install} to install BusyBox in this directory.
Try to boot your new system on the board. You should now reach a
command line prompt, allowing you to execute the commands of your
@@ -163,7 +165,7 @@ choice.
\section{Virtual filesystems}
-Run the \code{ps} command. You can see that it complains that the
+Run the \inlinebash{$ ps} command. You can see that it complains that the
\code{/proc} directory does not exist. The ps command and other
process-related commands use the \code{proc} virtual filesystem to get
their information from the kernel.
diff --git a/labs/sysdev-toolchain/sysdev-toolchain.tex b/labs/sysdev-toolchain/sysdev-toolchain.tex
index f103101e..ce2a97e8 100644
--- a/labs/sysdev-toolchain/sysdev-toolchain.tex
+++ b/labs/sysdev-toolchain/sysdev-toolchain.tex
@@ -17,20 +17,20 @@ Go to the \code{$HOME/__SESSION_NAME__-labs/toolchain} directory.
Install the packages needed for this lab:
-\begin{terminalinput}
+\begin{bashinput}
$ sudo apt install build-essential git autoconf bison flex texinfo help2man gawk libtool-bin libncurses5-dev
-\end{terminalinput}
+\end{bashinput}
\section{Getting Crosstool-ng}
Let's download the sources of Crosstool-ng, through its git
source repository, and switch to a commit that we have tested:
-\begin{terminalinput}
+\begin{bashinput}
$ git clone https://github.com/crosstool-ng/crosstool-ng.git
$ cd crosstool-ng/
$ git checkout 79fcfa17
-\end{terminalinput}
+\end{bashinput}
\section{Building and installing Crosstool-ng}
@@ -39,21 +39,21 @@ locally in its download directory. We'll choose the latter
solution. As documented at
\url{https://crosstool-ng.github.io/docs/install/#hackers-way}, do:
-\begin{terminalinput}
+\begin{bashinput}
$ ./bootstrap
-\end{terminalinput}
+\end{bashinput}
You can continue:
-\begin{terminalinput}
+\begin{bashinput}
$ ./configure --enable-local
$ make
-\end{terminalinput}
+\end{bashinput}
Then you can get Crosstool-ng help by running
-\begin{terminalinput}
+\begin{bashinput}
$ ./ct-ng help
-\end{terminalinput}
+\end{bashinput}
\section{Configure the toolchain to produce}
@@ -72,9 +72,9 @@ any sample for Cortex A7 yet}. Load it with the \code{./ct-ng} command.
Then, to refine the configuration, let's run the \code{menuconfig} interface:
-\begin{terminalinput}
+\begin{bashinput}
$ ./ct-ng menuconfig
-\end{terminalinput}
+\end{bashinput}
In \code{Path and misc options}:
\begin{itemize}
@@ -138,9 +138,9 @@ toolchain configuration.
Nothing is simpler:
-\begin{terminalinput}
+\begin{bashinput}
$ ./ct-ng build
-\end{terminalinput}
+\end{bashinput}
The toolchain will be installed by default in \code{$HOME/x-tools/}.
That's something you could have changed in Crosstool-ng's configuration.
@@ -172,9 +172,9 @@ You can now test your toolchain by adding
\code{hello.c} program in your main lab directory with
\code{arm-linux-gcc}:
-\begin{terminalinput}
+\begin{bashinput}
$ arm-linux-gcc -o hello hello.c
-\end{terminalinput}
+\end{bashinput}
You can use the \code{file} command on your binary to make sure it has
correctly been compiled for the ARM architecture.
@@ -183,28 +183,24 @@ Did you know that you can still execute this binary from your x86 host?
To do this, install the QEMU user emulator, which just emulates target
instruction sets, not an entire system with devices:
-\begin{terminalinput}
+\begin{bashinput}
$ sudo apt install qemu-user
-\end{terminalinput}
+\end{bashinput}
Now, try to run QEMU ARM user emulator:
-\begin{terminalinput}
+\begin{bashinput}
$ qemu-arm hello
-\end{terminalinput}
-
-\begin{terminaloutput}
/lib/ld-uClibc.so.0: No such file or directory
-\end{terminaloutput}
+\end{bashinput}
What's happening is that \code{qemu-arm} is missing the shared C library
(compiled for ARM) that this binary uses. Let's find it in our newly
compiled toolchain:
-\begin{terminalinput}
+\begin{bashinput}
$ find ~/x-tools -name ld-uClibc.so.0
-\end{terminalinput}
-
+\end{bashinput}
\begin{terminaloutput}
/home/tux/x-tools/arm-training-linux-uclibcgnueabihf/arm-training-linux-uclibcgnueabihf/sysroot/lib/ld-uClibc.so.0
\end{terminaloutput}
@@ -212,9 +208,9 @@ $ find ~/x-tools -name ld-uClibc.so.0
We can now use the \code{-L} option of \code{qemu-arm} to let it know
where shared libraries are:
-\begin{terminalinput}
+\begin{bashinput}
$ qemu-arm -L ~/x-tools/arm-training-linux-uclibcgnueabihf/arm-training-linux-uclibcgnueabihf/sysroot hello
-\end{terminalinput}
+\end{bashinput}
\begin{terminaloutput}
Hello world!
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 4ef17b49..4f7d9a20 100644
--- a/labs/sysdev-u-boot-qemu/sysdev-u-boot-qemu.tex
+++ b/labs/sysdev-u-boot-qemu/sysdev-u-boot-qemu.tex
@@ -14,10 +14,10 @@ following ones, we will use a QEMU emulated ARM Vexpress Cortex A9 board.
Download U-Boot v2020.04.
First apply a patch that fixes the \code{editenv} command in U-Boot:
-\begin{verbatim}
-cd u-boot-2020.04
-cat ../data/vexpress_flags_reset.patch | patch -p1
-\end{verbatim}
+\begin{bashinput}
+$ cd u-boot-2020.04
+$ cat ../data/vexpress_flags_reset.patch | patch -p1
+\end{bashinput}
Now configure U-Boot to support the ARM Vexpress Cortex A9 board
(\code{vexpress_ca9x4_defconfig}).
@@ -28,9 +28,7 @@ the Software} section.
Basically, you need to specify the cross-compiler prefix
(the part before \code{gcc} in the cross-compiler executable name):
-\begin{verbatim}
-export CROSS_COMPILE=arm-linux-
-\end{verbatim}
+\bashcmd{$ export CROSS_COMPILE=arm-linux-}
Now that you have a valid initial configuration, run \code{make menuconfig}
to further edit your bootloader features:
@@ -57,9 +55,7 @@ to further edit your bootloader features:
In recent versions of U-Boot and for some boards, you will
need to have the Device Tree compiler:
-\begin{verbatim}
-sudo apt install device-tree-compiler
-\end{verbatim}
+\bashcmd{$ sudo apt install device-tree-compiler}
Finally, run \code{make}\footnote{You can speed up the
compiling by using the \code{-jX} option with \code{make}, where X
@@ -73,9 +69,7 @@ This generates several binaries, including \code{u-boot} and
Still in U-Boot sources, test that U-Boot works:
-\begin{verbatim}
-qemu-system-arm -M vexpress-a9 -m 128M -nographic -kernel u-boot
-\end{verbatim}
+\bashcmd{$ qemu-system-arm -M vexpress-a9 -m 128M -nographic -kernel u-boot}
\begin{itemize}
\item \code{-M}: emulated machine
@@ -110,18 +104,14 @@ during the {\em Block filesystems} lectures.
First, using the \code{dd} command, create a 1 GB file
filled with zeros, called code{sd.img}:
-\begin{verbatim}
-dd if=/dev/zero of=sd.img bs=1M count=1024
-\end{verbatim}
+\bashcmd{$ dd if=/dev/zero of=sd.img bs=1M count=1024}
This will be used by QEMU as an SD card disk image
Now, let's use the \code{cfdisk} command to create the partitions that
we are going to use:
-\begin{verbatim}
-$ cfdisk sd.img
-\end{verbatim}
+\bashcmd{$ cfdisk sd.img}
If \code{cfdisk} asks you to \code{Select a label type}, choose
\code{dos}, as we don't really need a \code{gpt} partition table for
@@ -154,9 +144,7 @@ We will now use the {\em loop} driver\footnote{Once again, this will
be properly be explained during our {\em Block filesystems} lectures.}
to emulate block devices from this image and its partitions:
-\begin{verbatim}
-sudo losetup -f --show --partscan sd.img
-\end{verbatim}
+\bashcmd{$ sudo losetup -f --show --partscan sd.img}
\begin{itemize}
\item \code{-f}: finds a free loop device
@@ -168,41 +156,35 @@ sudo losetup -f --show --partscan sd.img
Last but not least, format the first partition as FAT16 with
a \code{boot} label:
-\begin{verbatim}
-sudo mkfs.vfat -F 16 -n boot /dev/loop<x>p1
-\end{verbatim}
+\bashcmd{$ 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}
+\bashcmd{$ sudo losetup -d /dev/loop<x>}
\section{Testing U-Boot's environment}
Start QEMU again, but this time with the emulated SD card
(you can type the command in a single line):
-\begin{verbatim}
-qemu-system-arm -M vexpress-a9 -m 128M -nographic \
- -kernel u-boot-2020.04/u-boot \
- -sd sd.img
-\end{verbatim}
+\begin{bashcmd}
+$ qemu-system-arm -M vexpress-a9 -m 128M -nographic \
+ -kernel u-boot-2020.04/u-boot \
+ -sd sd.img
+\end{bashcmd}
Now, in the U-Boot prompt, make sure that you can set and store an environment variable:
-\begin{verbatim}
-setenv foo bar
-saveenv
-\end{verbatim}
+\begin{bashinput}
+$ setenv foo bar
+$ saveenv
+\end{bashinput}
Type \code{reset} which reboots the board, and then check that the
\code{foo} variable is still set:
-\begin{verbatim}
-printenv foo
-\end{verbatim}
+\bashcmd{$ printenv foo}
\section{Setup networking between QEMU and the host}
@@ -219,9 +201,7 @@ network interface between QEMU and the host. Here are its contents:
\end{verbatim}
Of course, make this script executable:
-\begin{verbatim}
-chmod +x qemu-myifup
-\end{verbatim}
+\bashcmd{$ chmod +x qemu-myifup}
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.
@@ -231,12 +211,12 @@ local network.
Then, you will need root privileges to run QEMU this time,
because of the need to bring up the network interface:
-\begin{verbatim}
-sudo qemu-system-arm -M vexpress-a9 -m 128M -nographic \
--kernel u-boot-2020.04/u-boot \
--sd sd.img \
--net tap,script=./qemu-myifup -net nic
-\end{verbatim}
+\begin{bashinput}
+$ sudo qemu-system-arm -M vexpress-a9 -m 128M -nographic \
+ -kernel u-boot-2020.04/u-boot \
+ -sd sd.img \
+ -net tap,script=./qemu-myifup -net nic
+\end{bashinput}
Note the new net options:
\begin{itemize}
@@ -251,16 +231,14 @@ address.
On the U-Boot command line, you will have to configure the environment
variables for networking:
-\begin{verbatim}
-setenv ipaddr 192.168.0.100
-setenv serverip 192.168.0.1
-saveenv
-\end{verbatim}
+\begin{ubootinput}
+=> setenv ipaddr 192.168.0.100
+=> setenv serverip 192.168.0.1
+=> saveenv
+\end{ubootinput}
You can now test the connection to the host:
-\begin{verbatim}
-ping 192.168.0.1
-\end{verbatim}
+\ubootcmd{=> ping 192.168.0.1}
It should finish by:
\begin{verbatim}
@@ -279,9 +257,7 @@ To test the TFTP connection, put a small text file in
the directory exported through TFTP on your development
workstation. Then, from U-Boot, do:
-\begin{verbatim}
-tftp 0x61000000 textfile.txt
-\end{verbatim}
+\ubootcmd{$ tftp 0x61000000 textfile.txt}
The \code{tftp} command should have downloaded the
\code{textfile.txt} file from your development workstation into
@@ -290,9 +266,7 @@ the board's memory at location \code{0x61000000}.
You can verify that the download was successful by dumping the
contents of the memory:
-\begin{verbatim}
-md 0x61000000
-\end{verbatim}
+\ubootcmd{=> md 0x61000000}
\section{Rescue binary}
diff --git a/labs/sysdev-u-boot-stm32/sysdev-u-boot-stm32.tex b/labs/sysdev-u-boot-stm32/sysdev-u-boot-stm32.tex
index 44d8e2e9..8d083393 100644
--- a/labs/sysdev-u-boot-stm32/sysdev-u-boot-stm32.tex
+++ b/labs/sysdev-u-boot-stm32/sysdev-u-boot-stm32.tex
@@ -43,23 +43,19 @@ You can also see this device appear by looking at the output of
To communicate with the board through the serial port, install a
serial communication program, such as \code{picocom}:
-\begin{verbatim}
-sudo apt install picocom
-\end{verbatim}
+\bashcmd{$ sudo apt install picocom}
You also need to make your user belong to the \code{dialout} group to be
allowed to write to the serial console:
-\begin{verbatim}
-sudo adduser $USER dialout
-\end{verbatim}
+\bashcmd{$ sudo adduser $USER dialout}
{\bf Important}: for the group change to be effective, you have to
{\em completely log out} from your session and log in again (no need to
reboot). A workaround is to run \code{newgrp dialout}, but it is not global.
You have to run it in each terminal.
-Run \code{picocom -b 115200 /dev/ttyACM0}, to start serial
+Run \inlinebash{$ picocom -b 115200 /dev/ttyACM0}, to start serial
communication on \code{/dev/ttyACM0}, with a baudrate of 115200.
If you wish to exit \code{picocom}, press \code{[Ctrl][a]} followed by
@@ -76,11 +72,11 @@ In our case, both programs are provided by U-Boot.
Download U-Boot:
-\begin{verbatim}
-git clone https://gitlab.denx.de/u-boot/u-boot.git
-cd u-boot
-git checkout v2021.01
-\end{verbatim}
+\begin{bashinput}
+$ git clone https://gitlab.denx.de/u-boot/u-boot.git
+$ cd u-boot
+$ git checkout v2021.01
+\end{bashinput}
Get an understanding of U-Boot's configuration and compilation steps
by reading the \code{README} file, and specifically the {\em Building
@@ -92,18 +88,16 @@ Basically, you need to:
\item Specify the cross-compiler prefix
(the part before \code{gcc} in the cross-compiler executable name):
-\begin{verbatim}
-export CROSS_COMPILE=arm-linux-
-\end{verbatim}
+\bashcmd{$ export CROSS_COMPILE=arm-linux-}
-\item Run \code{make <NAME>_defconfig}, where the list of available
+\item Run \inlinebash{$ make <NAME>_defconfig}, where the list of available
configurations can be found in the \code{configs/} directory. There
are three flavors of the stm32mp15 configuration: two to boot using
secure boot and a basic one (\code{stm32mp15_basic}). This is the
one we will use.
\item Now that you have a valid initial configuration, you can now
- run \code{make menuconfig} to further edit your bootloader features.
+ run \inlinebash{$ make menuconfig} to further edit your bootloader features.
\begin{itemize}
\item In the \code{SPL / TPL} submenu, disable \code{Support an environment}, as
@@ -135,11 +129,9 @@ export CROSS_COMPILE=arm-linux-
\item In recent versions of U-Boot and for some boards, you will
need to have the Device Tree compiler:
-\begin{verbatim}
-sudo apt install device-tree-compiler
-\end{verbatim}
+\bashcmd{$ sudo apt install device-tree-compiler}
-\item Finally, run \code{make
+\item Finally, run \inlinebash{$ make
DEVICE_TREE=stm32mp157a-dk1}\footnote{You can speed up the
compiling by using the \code{-jX} option with \code{make}, where X
is the number of parallel jobs used for compiling. Twice the
@@ -193,23 +185,17 @@ seen as \code{/dev/mmcblk0} by your PC workstation.
Type the \code{mount} command to check your currently mounted
partitions. If SD partitions are mounted, unmount them:
-\begin{verbatim}
-$ sudo umount /dev/mmcblk0p*
-\end{verbatim}
+\bashcmd{$ sudo umount /dev/mmcblk0p*}
Then, clear possible SD card contents remaining from previous
training sessions (only the first megabytes matter):
-\begin{verbatim}
-$ sudo dd if=/dev/zero of=/dev/mmcblk0 bs=4k count=200
-\end{verbatim}
+\bashcmd{$ sudo dd if=/dev/zero of=/dev/mmcblk0 bs=4k count=200}
Now, let's use the \code{parted} command to create the partitions that
we are going to use:
-\begin{verbatim}
-$ sudo parted /dev/mmcblk0
-\end{verbatim}
+\bashcmd{$ sudo parted /dev/mmcblk0}
The ROM monitor handles {\em GPT} partition tables, let's create one:
@@ -240,22 +226,18 @@ Once done, quit:
Now, format the boot partition as an ext2 filesystem. This is where
U-Boot saves its environment:
-\begin{verbatim}
-sudo mkfs.ext2 -L boot /dev/mmcblk0p4
-\end{verbatim}
+\bashcmd{$ sudo mkfs.ext2 -L boot /dev/mmcblk0p4}
The U-Boot SPL is {\em fsbl}. Write it in both fsbl partitions:
-\begin{verbatim}
-sudo dd if=spl/u-boot-spl.stm32 of=/dev/mmcblk0p1 bs=1M conv=fdatasync
-sudo dd if=spl/u-boot-spl.stm32 of=/dev/mmcblk0p2 bs=1M conv=fdatasync
-\end{verbatim}
+\begin{bashinput}
+$ sudo dd if=spl/u-boot-spl.stm32 of=/dev/mmcblk0p1 bs=1M conv=fdatasync
+$ sudo dd if=spl/u-boot-spl.stm32 of=/dev/mmcblk0p2 bs=1M conv=fdatasync
+\end{bashinput}
Then flash {\em ssbl}, this is the main U-Boot binary:
-\begin{verbatim}
-sudo dd if=u-boot.img of=/dev/mmcblk0p3 bs=1M conv=fdatasync
-\end{verbatim}
+\bashcmd{$ sudo dd if=u-boot.img of=/dev/mmcblk0p3 bs=1M conv=fdatasync}
\section{Testing U-Boot}
@@ -328,9 +310,7 @@ a USB Ethernet adapter. A new network interface should appear on your
Linux system.
Find the name of this interface by typing:
-\begin{verbatim}
-ip a
-\end{verbatim}
+\ubootcmd{=> ip a}
The network interface name is likely to be
\code{enxxx}\footnote{Following the {\em Predictable Network Interface
@@ -342,31 +322,29 @@ the one that shows up after pluging in the device.
Then, instead of configuring the host IP address from NetWork Manager’s graphical interface,
let’s do it through its command line interface, which is so much easier to use:
-\begin{verbatim}
-nmcli con add type ethernet ifname en... ip4 192.168.0.1/24
-\end{verbatim}
+\bashcmd{$ nmcli con add type ethernet ifname en... ip4 192.168.0.1/24}
Now, configure the network on the board in U-Boot by setting the \code{ipaddr}
and \code{serverip} environment variables:
-\begin{verbatim}
-setenv ipaddr 192.168.0.100
-setenv serverip 192.168.0.1
-\end{verbatim}
+\begin{ubootinput}
+=> setenv ipaddr 192.168.0.100
+=> setenv serverip 192.168.0.1
+\end{ubootinput}
To make these settings permanent, save the environment:
-\begin{verbatim}
-saveenv
-\end{verbatim}
+\begin{ubootinput}
+=> saveenv
+\end{ubootinput}
You can then test the TFTP connection. First, put a small text file in
the directory exported through TFTP on your development
workstation. Then, from U-Boot, do:
-\begin{verbatim}
-tftp 0xc4000000 textfile.txt
-\end{verbatim}
+\begin{ubootinput}
+=> tftp 0xc4000000 textfile.txt
+\end{ubootinput}
The \code{tftp} command should have downloaded the
\code{textfile.txt} file from your development workstation into
@@ -385,9 +363,9 @@ for RAM. You can also try with other values in the same address range.}.
You can verify that the download was successful by dumping the
contents of the memory:
-\begin{verbatim}
-md 0xc4000000
-\end{verbatim}
+\begin{ubootinput}
+=> md 0xc4000000
+\end{ubootinput}
We will see in the next labs how to use U-Boot to download, flash and
boot a kernel.
diff --git a/labs/sysdev-u-boot/sysdev-u-boot.tex b/labs/sysdev-u-boot/sysdev-u-boot.tex
index 4d9563b0..39b37440 100644
--- a/labs/sysdev-u-boot/sysdev-u-boot.tex
+++ b/labs/sysdev-u-boot/sysdev-u-boot.tex
@@ -38,11 +38,11 @@ We first need to download this tool, from Microchip's website\footnote{
In case this website is down, you can also find this
tool on \url{https://bootlin.com/labs/tools/}.}.
-\begin{terminalinput}
+\begin{bashinput}
$ wget https://ww1.microchip.com/downloads/en/DeviceDoc/\
sam-ba_3.3.1-linux_x86_64.tar.gz
$ tar xf sam-ba_3.3.1-linux_x86_64.tar.gz
-\end{terminalinput}
+\end{bashinput}
\section{Setting up serial communication with the board}
@@ -61,23 +61,23 @@ You can also see this device appear by looking at the output of
To communicate with the board through the serial port, install a
serial communication program, such as \code{picocom}:
-\begin{terminalinput}
+\begin{bashinput}
$ sudo apt install picocom
-\end{terminalinput}
+\end{bashinput}
You also need to make your user belong to the \code{dialout} group to be
allowed to write to the serial console:
-\begin{terminalinput}
+\begin{bashinput}
$ sudo adduser $USER dialout
-\end{terminalinput}
+\end{bashinput}
{\bf Important}: for the group change to be effective, you have to
{\em completely log out} from your session and log in again (no need to
reboot). A workaround is to run \code{newgrp dialout}, but it is not global.
You have to run it in each terminal.
-Run \code{picocom -b 115200 /dev/ttyUSB0}, to start serial
+Run \inlinebash{$ picocom -b 115200 /dev/ttyUSB0}, to start serial
communication on \code{/dev/ttyUSB0}, with a baudrate of 115200.
You can now power-up the board by connecting the micro-USB cable to
@@ -119,11 +119,11 @@ look like:
Get U-Boot sources:
-\begin{terminalinput}
+\begin{bashinput}
$ git clone https://gitlab.denx.de/u-boot/u-boot
$ cd u-boot
$ git checkout v2020.07
-\end{terminalinput}
+\end{bashinput}
Note that the latest versions of U-Boot (v2021.01 at the time of this
writing) are broken for the SAMA5D3 Xplained board. We're trying
@@ -139,7 +139,7 @@ Basically, you need to:
\item Set the \code{CROSS_COMPILE} environment variable;
-\item Run \inlinecode{make <NAME>_defconfig}, where the list of available
+\item Run \inlinebash{$ make <NAME>_defconfig}, where the list of available
configurations can be found in the \code{configs/} directory. There
are two flavors of the Xplained configuration: one to run from the
SD card (\code{sama5d3_xplained_mmc}) and one to run from the NAND
@@ -147,14 +147,14 @@ Basically, you need to:
on the NAND, use the latter.
\item Now that you have a valid initial configuration, you can now
- run \inlinecode{make menuconfig} to further edit your bootloader features.
+ run \inlinebash{$ make menuconfig} to further edit your bootloader features.
\item In recent versions of U-Boot and for some boards, you will
need to have the Device Tree compiler:
-\begin{terminalinput}
+\begin{bashinput}
$ sudo apt install device-tree-compiler
-\end{terminalinput}
+\end{bashinput}
\item Finally, run \code{make}, which should build the two stages of U-Boot:
\begin{itemize}
@@ -184,21 +184,21 @@ Put the jumper back.
Getting back to the \code{bootloader} directory, use \code{sam-ba} to erase
NAND flash before writing images to it:
-\begin{terminalinput}
+\begin{bashinput}
$ ./sam-ba_3.3.1/sam-ba -p serial -b sama5d3-xplained -a nandflash -c erase
-\end{terminalinput}
+\end{bashinput}
Then flash the U-Boot SPL:
-\begin{terminalinput}
+\begin{bashinput}
$ ./sam-ba_3.3.1/sam-ba -p serial -b sama5d3-xplained -a nandflash \%\linebreak% -c writeboot:u-boot/spl/u-boot-spl.bin
-\end{terminalinput}
+\end{bashinput}
Then flash the U-Boot binary:
-\begin{terminalinput}
+\begin{bashinput}
$ ./sam-ba_3.3.1/sam-ba -p serial -b sama5d3-xplained -a nandflash \%\linebreak% -c write:u-boot/u-boot.bin:0x40000
-\end{terminalinput}
+\end{bashinput}
\section{Testing U-Boot}
@@ -231,9 +231,9 @@ a USB Ethernet adapter. A new network interface should appear on your
Linux system.
Find the name of this interface by typing:
-\begin{terminalinput}
+\begin{bashinput}
$ ip a
-\end{terminalinput}
+\end{bashinput}
The network interface name is likely to be
\code{enxxx}\footnote{Following the {\em Predictable Network Interface
@@ -245,9 +245,9 @@ the one that shows up after pluging in the device.
Then, instead of configuring the host IP address from NetWork Manager’s graphical interface,
let’s do it through its command line interface, which is so much easier to use:
-\begin{terminalinput}
+\begin{bashinput}
$ nmcli con add type ethernet ifname en... ip4 192.168.0.1/24
-\end{terminalinput}
+\end{bashinput}
Now, configure the network on the board in U-Boot by setting the \code{ipaddr}
and \code{serverip} environment variables:
More information about the training-materials-updates
mailing list