diff --git a/common/labs-header.tex b/common/labs-header.tex
index 1dfddf3aa..00b389376 100644
--- a/common/labs-header.tex
+++ b/common/labs-header.tex
@@ -6,51 +6,60 @@
 \usepackage{verbatim}
 \usepackage{moreverb}
 \usepackage{xcolor}
+\usepackage{mdframed}
 
 % Custom bootlin commands
 
-% environment for long lines of code/cmd input with backslash at end of line 
-\lstnewenvironment{terminalinput}{\lstset{
+\definecolor{mygray}{rgb}{0.8,0.8,0.8}
+
+\lstset{
+  autogobble,
   language=[LaTeX]TeX,
   basicstyle=\ttfamily,
   breaklines=true,
   escapechar={\%},
-  prebreak=\textbackslash,
-  literate={-}{{-\allowbreak}}{1},
-%  aboveskip=0pt
   belowskip=0pt,
-%  postbreak=\mbox{\textcolor{red}{$\rightarrow$}\space},
   columns=fullflexible
+}
+
+% environment for long lines of code/cmd input with backslash at end of line 
+\lstnewenvironment{terminalinput}
+{
+  \lstset{
+  prebreak=\textbackslash,
+  alsoletter={()[].=:-},
 }}{}
 
+\surroundwithmdframed[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=1pt, innerbottommargin=1pt, backgroundcolor=lightgray!20]{terminalinput}
+
+\def\clinput{\lstinline[basicstyle=\ttfamily]}
+
+\newcommand\ubootcli[1]{\colorbox{mygray}{\lstinline[#1]}}
+
+\def\inlinecode#1{%
+    \colorbox{lightgray!15}{\lstinline{#1}}%
+}
+
+\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{
-  autogobble,
-  language=[LaTeX]TeX,
-  basicstyle=\ttfamily,
-  breaklines=true,
-  escapechar={\%},
-  prebreak={},
-  belowskip=0pt,
-%  postbreak=\mbox{\textcolor{red}{$\rightarrow$}\space},
-  columns=fullflexible
+  alsoletter={()[].=:-},
 }}{}
 
-% environment for long lines of cmd output without backslash but with
+\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{
-  language=[LaTeX]TeX,
-  basicstyle=\ttfamily,
   breakautoindent=false,
+  alsoletter={()[].=:-},
   breakindent=0pt,
-  breaklines=true,
-  escapechar={\%},
-  prebreak={},
-  belowskip=0pt,
-%  postbreak=\mbox{\textcolor{red}{$\rightarrow$}\space},
-  columns=fullflexible
 }}{}
 
+%\surroundwithmdframed[innerleftmargin=1pt,innerrightmargin=1pt,skipabove=\topskip,skipbelow=\topskip,linewidth=0pt,innertopmargin=1pt, innerbottommargin=1pt, backgroundcolor=blue!5]{terminaloutput}
+
 \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-sama5d3.tex b/common/sysdev-kernel-cross-compiling-sama5d3.tex
index 2612f62d5..0cfd0aaa6 100644
--- a/common/sysdev-kernel-cross-compiling-sama5d3.tex
+++ b/common/sysdev-kernel-cross-compiling-sama5d3.tex
@@ -17,12 +17,14 @@ \section{Flashing the kernel and DTB in NAND flash}
 
 % Verbatim doesn't seem to work in this \ifdefstring environment
 
-\code{nand erase 0x180000 0x20000} ({\em NAND-offset size})
+\begin{ubootinput}
+=> nand erase 0x180000 0x20000} %\rmfamily({\em NAND-offset size})%
+\end{ubootinput}
 
 Then, let's erase the 5 MiB of NAND flash for the kernel image:
 
 % Verbatim doesn't seem to work in this \ifdefstring environment
-\code{nand erase 0x1a0000 0x500000}
+\ubootcmd{=> nand erase 0x1a0000 0x500000}
 
 Then, copy the DTB and kernel binaries from TFTP into memory, using the
 same addresses as before.
@@ -30,16 +32,20 @@ \section{Flashing the kernel and DTB in NAND flash}
 Then, flash the DTB and kernel binaries:
 
 % Verbatim doesn't seem to work in this \ifdefstring environment
-\code{nand write 0x22000000 0x180000 0x20000} ({\em RAM-addr NAND-offset size})\\
-\code{nand write 0x21000000 0x1a0000 0x500000}
+\begin{ubootinput}
+=> nand write 0x22000000 0x180000 0x20000} %\rmfamily({\em RAM-addr NAND-offset size})%
+=> nand write 0x21000000 0x1a0000 0x500000
+\end{ubootinput}
 
 Power your board off and on, to clear RAM contents. We should now be
 able to load the DTB and kernel image from NAND and boot with:
 
 % Verbatim doesn't seem to work in this \ifdefstring environment
-\code{nand read 0x22000000 0x180000 0x20000} ({\em RAM-addr offset size})\\
-\code{nand read 0x21000000 0x1a0000 0x500000}\\
-\code{bootz 0x21000000 - 0x22000000}
+\begin{ubootinput}
+=> nand read 0x22000000 0x180000 0x20000} %\rmfamily({\em RAM-addr offset size})%
+=> nand read 0x21000000 0x1a0000 0x500000
+=> bootz 0x21000000 - 0x22000000
+\end{ubootinput}
 
 Write a U-Boot script that automates the DTB + kernel download
 and flashing procedure.
@@ -48,7 +54,9 @@ \section{Flashing the kernel and DTB in NAND flash}
 from flash. But first, save the settings for booting from \code{tftp}:
 
 % Verbatim doesn't seem to work in this \ifdefstring environment
-\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 d4f582918..17a707492 100644
--- a/labs/setup/setup.tex
+++ b/labs/setup/setup.tex
@@ -8,9 +8,9 @@ \section{Install lab data}
 
 %{\small % leaving here as a marker if font sizes are needed
 \begin{terminalinput}
-cd
-wget %\sessionurl%/__SESSION_NAME__-labs.tar.xz
-tar xvf __SESSION_NAME__-labs.tar.xz
+$ cd
+$ wget %\sessionurl%/__SESSION_NAME__-labs.tar.xz
+$ tar xvf __SESSION_NAME__-labs.tar.xz
 \end{terminalinput}
 %}
 Lab data are now available in an \code{__SESSION_NAME__-labs} directory in
diff --git a/labs/sysdev-application-debugging/sysdev-application-debugging.tex b/labs/sysdev-application-debugging/sysdev-application-debugging.tex
index 24a71916a..d95d2bc00 100644
--- a/labs/sysdev-application-debugging/sysdev-application-debugging.tex
+++ b/labs/sysdev-application-debugging/sysdev-application-debugging.tex
@@ -67,10 +67,10 @@ \section{Using strace}
 
 
 Update the PATH:
-\footnotesize
-\begin{verbatim}
-export PATH=$HOME/__SESSION_NAME__-labs/debugging/buildroot-2021.02.<n>/output/host/bin:$PATH
-\end{verbatim}
+%\footnotesize
+\begin{terminalinput}
+$ export PATH=$HOME/__SESSION_NAME__-labs/debugging/buildroot-2021.02.<n>/output/host/bin:$PATH
+\end{terminalinput}
 \normalsize
 
 With your cross-compiling toolchain
@@ -119,19 +119,13 @@ \section{Using gdbserver}
 connection from \code{gdb}, and will control the execution of
 \code{vista-emulator} according to the \code{gdb} commands:
 
-\begin{verbatim}
-gdbserver localhost:2345 vista-emulator
-\end{verbatim}
+\ubootcmd{=> gdbserver localhost:2345 vista-emulator}
 
 On the host side, run \code{arm-linux-gdb} (also found in your toolchain):
-\begin{verbatim}
-arm-linux-gdb vista-emulator
-\end{verbatim}
+\bashcmd{$ arm-linux-gdb vista-emulator}
 
 You can also start the debugger through the \code{ddd} interface:
-\begin{verbatim}
-ddd --debugger arm-linux-gdb vista-emulator
-\end{verbatim}
+\bashcmd{$ ddd --debugger arm-linux-gdb vista-emulator}
 
 \code{gdb} starts and loads the debugging information from the
 \code{vista-emulator} binary that has been compiled with \code{-g}.
@@ -141,31 +135,31 @@ \section{Using gdbserver}
 your workstation. This is done by setting the \code{gdb} \code{sysroot}
 variable (on one line):
 
-\begin{verbatim}
-(gdb) set sysroot /home/<user>/__SESSION_NAME__-labs/debugging/
-buildroot-2021.02.<n>/output/staging
-\end{verbatim}
+\begin{terminalinput}
+(gdb) set sysroot /home/<user>/__SESSION_NAME__-labs/debugging/\
+    buildroot-2021.02.<n>/output/staging
+\end{terminalinput}
 
 Of course, replace \code{<user>} by your actual user name.
 
 And tell \code{gdb} to connect to the remote system:
-\begin{verbatim}
+\begin{terminalinput}
 (gdb) target remote <target-ip-address>:2345
-\end{verbatim}
+\end{terminalinput}
 
 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{verbatim}
+\begin{terminalinput}
 (gdb) continue
-\end{verbatim}
+\end{terminalinput}
 
 You could then ask for a backtrace to see where this happened:
-\begin{verbatim}
+\begin{terminalinput}
 (gdb) backtrace
-\end{verbatim}
+\end{terminalinput}
 
 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 51a073797..5d17c64f2 100644
--- a/labs/sysdev-application-development/sysdev-application-development.tex
+++ b/labs/sysdev-application-development/sysdev-application-development.tex
@@ -23,17 +23,14 @@ \section{Compile your own application}
 
 Let's add this directory to our \code{PATH}:
 
-\footnotesize
-\begin{verbatim}
-export PATH=$HOME/__SESSION_NAME__-labs/buildroot/buildroot-2021.02.X/output/host/usr/bin:$PATH
-\end{verbatim}
+\begin{terminalinput}
+$ export PATH=$HOME/__SESSION_NAME__-labs/buildroot/buildroot-2021.02.X/output/host/usr/bin:$PATH
+\end{terminalinput}
 \normalsize
 
 Let's try to compile the application:
 
-\begin{verbatim}
-arm-linux-gcc -o app app.c
-\end{verbatim}
+\bashcmd{$ arm-linux-gcc -o app app.c}
 
 It complains about undefined references to some symbols. This is
 normal, since we didn't tell the compiler to link with the necessary
@@ -45,9 +42,7 @@ \section{Compile your own application}
 already knows the right paths to find \code{.pc} files and their
 sysroot.}:
 
-\begin{verbatim}
-arm-linux-gcc -o app app.c $(pkg-config --libs --cflags ncurses)
-\end{verbatim}
+\bashcmd{$ arm-linux-gcc -o app app.c $(pkg-config --libs --cflags ncurses)}
 
 Our application is now compiled! Copy the generated binary to the NFS
 root filesystem (in the \code{root/} directory for example), start
diff --git a/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex b/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
index 5a6a67607..b287f021a 100644
--- a/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
+++ b/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex
@@ -60,23 +60,17 @@ \section{Prepare the SD card}
 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=1M count=256
-\end{verbatim}
+\bashcmd{$ sudo dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=256}
 
 Now, let's use the \code{cfdisk} command to create the partitions that
 we are going to use:
 
-\begin{verbatim}
-$ sudo cfdisk /dev/mmcblk0
-\end{verbatim}
+\bashcmd{$ sudo cfdisk /dev/mmcblk0}
 
 If \code{cfdisk} asks you to \code{Select a label type}, choose
 \code{dos}. This corresponds to traditional partitions tables that DOS/Windows
@@ -119,9 +113,7 @@ \section{Data partition on the SD card}
 Using the \code{mkfs.ext4} create a journaled file system on the
 third partition of the SD card:
 
-\begin{verbatim}
-sudo mkfs.ext4 -L data -E nodiscard /dev/mmcblk0p3
-\end{verbatim}
+\bashcmd{$ sudo mkfs.ext4 -L data -E nodiscard /dev/mmcblk0p3}
 
 \begin{itemize}
 \item \code{-L} assigns a volume name to the partition
@@ -195,9 +187,7 @@ \section{Booting on the SquashFS partition}
 \section{Store the kernel image and DTB on the SD card}
 
 You'll first need to format the first partition, using:
-\begin{verbatim}
-sudo mkfs.vfat -F 32 -n boot /dev/mmcblk0p1
-\end{verbatim}
+\bashcmd{$ sudo mkfs.vfat -F 32 -n boot /dev/mmcblk0p1}
 
 It will create a new FAT32 partition, called \code{boot}. Remove and
 plug the SD card back in. You can now copy the kernel image and
@@ -209,11 +199,7 @@ \section{Store the kernel image and DTB on the SD card}
 
 In U-boot, you can load a file from a FAT filesystem using a command
 like
-
-\begin{verbatim}
-fatload mmc 0:1 0x21000000 filename
-\end{verbatim}
-
+\ubootcmd{=> fatload mmc 0:1 0x21000000 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{0x21000000}.
diff --git a/labs/sysdev-buildroot/sysdev-buildroot.tex b/labs/sysdev-buildroot/sysdev-buildroot.tex
index d956ece84..b87b4b253 100644
--- a/labs/sysdev-buildroot/sysdev-buildroot.tex
+++ b/labs/sysdev-buildroot/sysdev-buildroot.tex
@@ -58,9 +58,7 @@ \section{Configure Buildroot}
 
 To run the configuration utility of Buildroot, simply run:
 
-\begin{verbatim}
-make menuconfig
-\end{verbatim}
+\bashcmd{$ make menuconfig}
 
 Set the following options. Don't hesitate to press the \code{Help}
 button whenever you need more details about a given option:
@@ -141,9 +139,7 @@ \section{Generate the embedded Linux system}
 
 Just run:
 
-\begin{verbatim}
-make
-\end{verbatim}
+\bashcmd{$ make}
 
 Buildroot will first create a small environment with the external
 toolchain, then download, extract, configure, compile and install each
@@ -190,9 +186,7 @@ \section{Run the generated system}
 a new \code{nfsroot} directory that is going to hold our system,
 exported over NFS. Go into this directory, and untar the rootfs using:
 
-\begin{verbatim}
-tar xvf ../buildroot-2021.02.<n>/output/images/rootfs.tar
-\end{verbatim}
+\bashcmd{$ tar xvf ../buildroot-2021.02.<n>/output/images/rootfs.tar}
 
 Add our \code{nfsroot} directory to the list of directories exported
 by NFS in \code{/etc/exports}, and make sure the board uses it too.
diff --git a/labs/sysdev-flash-filesystems/sysdev-flash-filesystems.tex b/labs/sysdev-flash-filesystems/sysdev-flash-filesystems.tex
index cf05ad14a..659c3af78 100644
--- a/labs/sysdev-flash-filesystems/sysdev-flash-filesystems.tex
+++ b/labs/sysdev-flash-filesystems/sysdev-flash-filesystems.tex
@@ -94,11 +94,11 @@ \section{Filesystem image preparation}
 To do so, erase your \code{UBI} partition and let U-Boot initialize
 a new UBI space on it:
 
-\begin{verbatim}
-nand erase.part UBI
-ubi part UBI
-ubi info
-\end{verbatim}
+\begin{ubootinput}
+=> nand erase.part UBI
+=> ubi part UBI
+=> ubi info
+\end{ubootinput}
 
 This will give you plenty of information about UBI on your NAND flash,
 in particular the {\em PEB} and {\em LEB} sizes.
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 13b82564b..8a22ff6e2 100644
--- a/labs/sysdev-kernel-cross-compiling/sysdev-kernel-cross-compiling.tex
+++ b/labs/sysdev-kernel-cross-compiling/sysdev-kernel-cross-compiling.tex
@@ -24,9 +24,7 @@ \section{Cross-compiling environment setup}
 toolchain. We will use the cross-compiling toolchain that we
 previously produced, so we just need to make it available in the PATH:
 
-\begin{verbatim}
-export PATH=$HOME/x-tools/arm-training-linux-uclibcgnueabihf/bin:$PATH
-\end{verbatim}
+\bashcmd{$ export PATH=$HOME/x-tools/arm-training-linux-uclibcgnueabihf/bin:$PATH}
 
 Also, don't forget to either:
 
@@ -75,9 +73,7 @@ \section{Cross compiling}
 
 You're now ready to cross-compile your kernel. Simply run:
 
-\begin{verbatim}
-make
-\end{verbatim}
+\bashcmd{$ make}
 
 and wait a while for the kernel to compile. Don't forget to use
 \code{make -j<n>} if you have multiple cores on your machine!
@@ -96,8 +92,9 @@ \section{Load and boot the kernel using U-Boot}
 we need to set the \code{bootargs} environment corresponding
 to the Linux kernel command line:
 
-\texttt{setenv bootargs console=\ttyname}
-
+\begin{ubootinput}
+=> setenv bootargs console=%\ttyname%
+\end{ubootinput}
 We will use TFTP to load the kernel image on the board:
 
 \begin{itemize}
@@ -106,14 +103,20 @@ \section{Load and boot the kernel using U-Boot}
 (\texttt\dtbname) to the directory exposed by the TFTP server.
 
 \item On the target (in the U-Boot prompt), load \code{zImage} from
-TFTP into RAM:\\
-\texttt{tftp \zimageboardaddr\ zImage}
+TFTP into RAM:
+\begin{ubootinput}
+=> tftp %\zimageboardaddr% zImage
+\end{ubootinput}
 
-\item Now, also load the DTB file into RAM:\\
-\texttt{tftp \dtbboardaddr\ \dtbname}
+\item Now, also load the DTB file into RAM:
+\begin{ubootinput}
+=> tftp %\dtbboardaddr% %\dtbname%
+\end{ubootinput}
 
-\item Boot the kernel with its device tree:\\
-\texttt{bootz \zimageboardaddr\ - \dtbboardaddr}
+\item Boot the kernel with its device tree:
+\begin{ubootinput}
+=> bootz %\zimageboardaddr% - %\dtbboardaddr%
+\end{ubootinput}
 
 \end{itemize}
 
@@ -123,11 +126,10 @@ \section{Load and boot the kernel using U-Boot}
 You can now automate all this every time the board is booted or
 reset. Reset the board, and customize \code{bootcmd}:
 
-\footnotesize
-\texttt {setenv bootcmd 'tftp \zimageboardaddr\ zImage; tftp \dtbboardaddr\ \dtbname;
-bootz \zimageboardaddr\ - \dtbboardaddr'}\\
-\code{saveenv}
-\normalsize
+\begin{ubootinput}
+=> setenv bootcmd 'tftp %\zimageboardaddr\ zImage; tftp \dtbboardaddr\ \dtbname; bootz \zimageboardaddr - \dtbboardaddr'%
+=> saveenv
+\end{ubootinput}
 
 Restart the board to make sure that booting the kernel is now automated.
 
diff --git a/labs/sysdev-real-time/sysdev-real-time.tex b/labs/sysdev-real-time/sysdev-real-time.tex
index a25e526c5..289152870 100644
--- a/labs/sysdev-real-time/sysdev-real-time.tex
+++ b/labs/sysdev-real-time/sysdev-real-time.tex
@@ -81,9 +81,9 @@ \subsection{Root filesystem}
 The last thing to do is to add a few files that we will need in our
 tests:
 
-\begin{verbatim}
-cp data/* nfsroot/root
-\end{verbatim}
+\begin{terminalinput}
+$ cp data/* nfsroot/root
+\end{terminalinput}
 
 \subsection{Downloading Linux kernel sources and patches}
 
@@ -122,10 +122,10 @@ \subsection{Measure the effect of high-resolution timers}
 
 Let's configure our \code{PATH} to use this toolchain:
 
-\small
-\begin{verbatim}
-export PATH=$HOME/__SESSION_NAME__-labs/realtime/buildroot-2021.02.X/output/host/usr/bin:$PATH
-\end{verbatim}
+%\simall
+\begin{terminalinput}
+$ export PATH=$HOME/__SESSION_NAME__-labs/realtime/buildroot-2021.02.X/output/host/usr/bin:$PATH
+\end{terminalinput}
 \normalsize
 
 Have a look at the \code{rttest.c} source file available in
@@ -133,9 +133,9 @@ \subsection{Measure the effect of high-resolution timers}
 resolution of the \code{CLOCK_MONOTONIC} clock.
 
 Now compile this program:
-\begin{verbatim}
-arm-linux-gnueabihf-gcc -o rttest rttest.c
-\end{verbatim}
+\begin{terminalinput}
+$ arm-linux-gnueabihf-gcc -o rttest rttest.c
+\end{terminalinput}
 
 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 @@ \subsection{Build a Xenomai-enabled kernel}
 Xenomai itself. Go to Buildroot \code{output/build/xenomai-3.1/}
 folder, and run:
 
-\begin{verbatim}
-./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{verbatim}
+\begin{terminalinput}
+$ ./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}
 
 Now that your kernel is patched, you can configure it:
 
-\begin{verbatim}
-make ARCH=arm sama5_defconfig
-\end{verbatim}
+\begin{terminalinput}
+$ make ARCH=arm sama5_defconfig
+\end{terminalinput}
 
 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{verbatim}
-export CROSS_COMPILE=arm-linux-gnueabihf-
-\end{verbatim}
+\begin{terminalinput}
+$ export CROSS_COMPILE=arm-linux-gnueabihf-
+\end{terminalinput}
 
 Build your kernel. Copy the kernel image and the Device Tree to your TFTP
 directory, and boot this new kernel.
@@ -254,21 +254,22 @@ \subsection{Testing Xenomai latencies}
 the Xenomai user-space libraries. This can be done by using the
 \code{xeno-config} script provided by Xenomai, as follows:
 
-\small
-\begin{verbatim}
-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{verbatim}
+%\small
+\begin{terminalinput}
+$ 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}
 \normalsize
 
 Run the following commands on the board:
 
-\begin{verbatim}
-echo 0 > /proc/xenomai/latency
-\end{verbatim}
+\begin{terminalinput}
+$ echo 0 > /proc/xenomai/latency
+\end{terminalinput}
 
 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 8ecb5b5d2..c3840adf5 100644
--- a/labs/sysdev-thirdparty/sysdev-thirdparty.tex
+++ b/labs/sysdev-thirdparty/sysdev-thirdparty.tex
@@ -101,9 +101,7 @@ \section{Preparation}
   tiny embedded system} lab, so copy this system in the target
 directory:
 
-\begin{verbatim}
-cp -a $HOME/__SESSION_NAME__-labs/tinysystem/nfsroot/* target/
-\end{verbatim}
+\bashcmd{$ cp -a $HOME/__SESSION_NAME__-labs/tinysystem/nfsroot/* target/}
 
 Note that for this lab, a lot of typing will be required. To save time
 typing, we advise you to copy and paste commands from the electronic
@@ -136,20 +134,20 @@ \section{alsa-lib}
 Makefiles from \code{Makefile.am} files. So alsa-lib uses a rather
 common build system. Let's try to configure and build it:
 
-\begin{verbatim}
-./configure
-make
-\end{verbatim}
+\begin{terminalinput}
+$ ./configure
+$ make
+\end{terminalinput}
 
 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{verbatim}
-make clean
-CC=arm-linux-gcc ./configure
-\end{verbatim}
+\begin{terminalinput}
+$ make clean
+$ CC=arm-linux-gcc ./configure
+\end{terminalinput}
 
 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
@@ -158,13 +156,13 @@ \section{alsa-lib}
 
 Quickly, you should get an error saying:
 
-\footnotesize
-\begin{verbatim}
+%\footnotesize
+\begin{terminaloutput}
 checking whether we are cross compiling... configure: error: in `.../thirdparty/alsa-lib-1.1.6':
 configure: error: cannot run C compiled programs.
 If you meant to cross compile, use `--host'.
 See `config.log' for more details
-\end{verbatim}
+\end{terminaloutput}
 \normalsize
 
 If you look at the \code{config.log} file, you can see that the
@@ -202,9 +200,7 @@ \section{alsa-lib}
 
 So, let's override the value of the \code{--host} option:
 
-\begin{verbatim}
-CC=arm-linux-gcc ./configure --host=arm-linux
-\end{verbatim}
+\bashcmd{$ CC=arm-linux-gcc ./configure --host=arm-linux}
 
 The \code{configure} script should end properly now, and create a
 Makefile. Run the \code{make} command, which should run just fine.
@@ -216,20 +212,17 @@ \section{alsa-lib}
 library. The shared library itself is \code{libasound.so.2.0.0}, it has
 been generated by the following command line:
 
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 And creates the symbolic links \code{libasound.so} and
 \code{libasound.so.2}.
 
-\begin{verbatim}
-ln -s libasound.so.2.0.0 libasound.so.2
-ln -s libasound.so.2.0.0 libasound.so
-\end{verbatim}
+\begin{terminalinput}
+$ ln -s libasound.so.2.0.0 libasound.so.2
+$ ln -s libasound.so.2.0.0 libasound.so
+\end{terminalinput}
 
 These symlinks are needed for two different reasons:
 
@@ -251,9 +244,7 @@ \section{alsa-lib}
 \end{itemize}
 
 To know what's the {\em SONAME} of a library, you can use:
-\begin{verbatim}
-arm-linux-readelf -d libasound.so.2.0.0
-\end{verbatim}
+\bashcmd{$ arm-linux-readelf -d libasound.so.2.0.0}
 
 and look at the \code{(SONAME)} line. You'll also see that this
 library needs the C library, because of the \code{(NEEDED)} line on
@@ -284,10 +275,10 @@ \section{alsa-lib}
 the libraries to be installed in the \code{/usr} prefix, so let's tell
 the \code{configure} script about this:
 
-\begin{verbatim}
-CC=arm-linux-gcc ./configure --host=arm-linux --disable-python --prefix=/usr
-make
-\end{verbatim}
+\begin{terminalinput}
+$ CC=arm-linux-gcc ./configure --host=arm-linux --disable-python --prefix=/usr
+$ make
+\end{terminalinput}
 
 For this library, this option may not change anything to the resulting
 binaries, but for safety, it is always recommended to make sure that
@@ -318,9 +309,7 @@ \section{alsa-lib}
 We now only have the installation process left to do.
 
 First, 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}
 
 Now look at what has been installed by alsa-lib:
 \begin{itemize}
@@ -341,13 +330,13 @@ \section{alsa-lib}
   since \code{libasound.so.2} is the {\em SONAME} of the library and
   \code{libasound.so.2.0.0} is the real binary:
   \begin{itemize}
-  \item \code{cp -a staging/usr/lib/libasound.so.2* target/usr/lib}
+  \item \bashcmd{$ cp -a staging/usr/lib/libasound.so.2* target/usr/lib}
   \end{itemize}
 \item Measure the size of the \code{target/usr/lib/libasound.so.2.0.0}
   library before stripping.
 \item Strip the library:
   \begin{itemize}
-  \item \code{arm-linux-strip target/usr/lib/libasound.so.2.0.0}
+  \item \bashcmd{$ arm-linux-strip target/usr/lib/libasound.so.2.0.0}
   \end{itemize}
 \item Measure the size of the \code{target/usr/lib/libasound.so.2.0.0}
   library library again after stripping. How many unnecessary bytes
@@ -368,9 +357,7 @@ \section{Alsa-utils}
 As we've seen previously, we will have to provide the prefix and host
 options and the CC variable:
 
-\begin{verbatim}
-CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr
-\end{verbatim}
+\bashcmd{$ CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr}
 
 Now, we should quiclky get an error in the execution of the
 \code{configure} script:
@@ -383,12 +370,12 @@ \section{Alsa-utils}
 Again, we can check in \code{config.log} what the \code{configure}
 script is trying to do:
 
-\footnotesize
-\begin{verbatim}
+%\footnotesize
+\begin{terminaloutput}
 configure:7146: checking for libasound headers version >= 1.0.27
 configure:7208: arm-linux-gcc -c -g -O2  conftest.c >&5
 conftest.c:12:10: fatal error: alsa/asoundlib.h: No such file or directory
-\end{verbatim}
+\end{terminaloutput}
 \normalsize
 
 Of course, since {\em alsa-utils} uses {\em alsa-lib}, it includes
@@ -405,11 +392,11 @@ \section{Alsa-utils}
 
 Let's use it:
 
-\begin{verbatim}
-CPPFLAGS=-I$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \
-CC=arm-linux-gcc \
+\begin{terminalinput}
+$ CPPFLAGS=-I$HOME/__SESSION_NAME__-labs/thirdparty/staging/usr/include \%\linebreak
+CC=arm-linux-gcc %\% \linebreak
 ./configure --host=arm-linux --prefix=/usr
-\end{verbatim}
+\end{terminalinput}
 
 Now, it should stop a bit later, this time with the error:
 \begin{verbatim}
@@ -436,12 +423,12 @@ \section{Alsa-utils}
 
 Let's use this \code{LDFLAGS} variable:
 
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 Once again, it should fail a bit further down the tests, this time
 complaining about a missing {\em curses helper header}. {\em curses}
@@ -454,13 +441,13 @@ \section{Alsa-utils}
 just like we built {\em alsa-lib}. We will also need to disable support
 for {\em xmlto} that generates the documentation.
 
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 Then, run the compilation with \code{make}. Hopefully, it works!
 
@@ -470,9 +457,7 @@ \section{Alsa-utils}
 afterwards, it is only to verify what will be installed before
 polluting the staging space):
 
-\begin{verbatim}
-make DESTDIR=/tmp/alsa-utils/ install
-\end{verbatim}
+\bashcmd{$ make DESTDIR=/tmp/alsa-utils/ install}
 
 The \code{DESTDIR} variable can be used with all Makefiles based on
 \code{automake}. It allows to override the installation directory:
@@ -596,18 +581,18 @@ \section{Alsa-utils}
 Then, let's install only the necessary files in the {\em target}
 space, manually:
 
-\begin{verbatim}
-cd ..
-cp -a staging/usr/bin/a* staging/usr/bin/speaker-test target/usr/bin/
-cp -a staging/usr/sbin/alsa* target/usr/sbin
-arm-linux-strip target/usr/bin/a*
-arm-linux-strip target/usr/bin/speaker-test
-arm-linux-strip target/usr/sbin/alsactl
-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{verbatim}
+\begin{terminalinput}
+$ cd ..
+$ cp -a staging/usr/bin/a* staging/usr/bin/speaker-test target/usr/bin/
+$ cp -a staging/usr/sbin/alsa* target/usr/sbin
+$ arm-linux-strip target/usr/bin/a*
+$ arm-linux-strip target/usr/bin/speaker-test
+$ arm-linux-strip target/usr/sbin/alsactl
+$ 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}
 
 And we're finally done with {\em alsa-utils}!
 
@@ -635,31 +620,25 @@ \section{libogg}
 Configuring {\em libogg} is very similar to the configuration of the
 previous libraries:
 
-\begin{verbatim}
-CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr
-\end{verbatim}
+\bashcmd{$ CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr}
 
 Of course, compile the library:
 
-\begin{verbatim}
-make
-\end{verbatim}
+\bashcmd{$ make}
 
 Installation to the {\em staging} space can be done using the
 classical \code{DESTDIR} mechanism:
 
-\begin{verbatim}
-make DESTDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/ install
-\end{verbatim}
+\bashcmd{$ make DESTDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/ install}
 
 And finally, only install manually in the {\em target} space the files
 needed at runtime:
 
-\begin{verbatim}
-cd ..
-cp -a staging/usr/lib/libogg.so.0* target/usr/lib/
-arm-linux-strip target/usr/lib/libogg.so.0.8.4
-\end{verbatim}
+\begin{terminalinput}
+$ 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}
 
 Done with {\em libogg}!
 
@@ -673,10 +652,7 @@ \section{libvorbis}
 libvorbis} is very easy, and almost identical to what we've seen
 with {\em alsa-utils}. First, the \code{configure} step:
 
-\begin{verbatim}
-CC=arm-linux-gcc \
-./configure --host=arm-linux --prefix=/usr
-\end{verbatim}
+\bashcmd{$ CC=arm-linux-gcc ./configure --host=arm-linux --prefix=/usr}
 
 It will fail with:
 
@@ -688,33 +664,29 @@ \section{libvorbis}
 \code{--with-ogg-libraries} and \code{--with-ogg-includes} options.
 Use these:
 
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 Then, compile the library:
 
-\begin{verbatim}
-make
-\end{verbatim}
+\bashcmd{$ make}
 
 Install it 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}
 
 And install only the required files in the {\em target} space:
 
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 And we're done with {\em libvorbis}!
 
@@ -726,41 +698,36 @@ \section{libao}
 Configuring {\em libao} is once again fairly easy, and similar to
 every sane autotools based build system:
 
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 Of course, compile the library:
 
-\begin{verbatim}
-make
-\end{verbatim}
+\bashcmd{$ make}
 
 Installation to the {\em staging} space can be done using the
 classical \code{DESTDIR} mechanism:
 
-\begin{verbatim}
-make DESTDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/ install
-\end{verbatim}
+\bashcmd{$ make DESTDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/ install}
 
 And finally, install manually the only needed files at runtime in the
 {\em target} space:
 
-\begin{verbatim}
-cd ..
-cp -a staging/usr/lib/libao.so.4* target/usr/lib/
-arm-linux-strip target/usr/lib/libao.so.4.1.0
-\end{verbatim}
+\begin{terminalinput}
+$ 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}
 
 We will also need the alsa plugin that is loaded dynamically by
 {\em libao} at startup:
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 Done with {\em libao}!
 
@@ -787,12 +754,12 @@ \section{vorbis-tools}
 
 So, let's begin with our usual \code{configure} line:
 
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 At the end, you should see the following warning:
 
@@ -867,15 +834,14 @@ \section{vorbis-tools}
 the \code{PKG_CONFIG_LIBDIR} and \code{PKG_CONFIG_SYSROOT_DIR}
 environment variables:
 
-\small
-\begin{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 \normalsize
 
 Now, the \code{configure} script should end properly, we can now start the
@@ -885,14 +851,14 @@ \section{vorbis-tools}
 \end{verbatim}
 
 It should fail with the following cryptic message:
-\footnotesize
-\begin{verbatim}
+%\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; \
 then mv -f ".deps/audio.Tpo" ".deps/audio.Po"; else rm -f ".deps/audio.Tpo"; exit 1; fi
 In file included from audio.c:22:
 /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
-\end{verbatim}
+\end{terminaloutput}
 \normalsize
 
 You can notice that \code{/usr/include} is added to the include paths.
@@ -907,17 +873,15 @@ \section{vorbis-tools}
 
 Now, install the vorbis-tools to the {\em staging} space using:
 
-\begin{verbatim}
-make DESTDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/ install
-\end{verbatim}
+\bashcmd{$ make DESTDIR=$HOME/__SESSION_NAME__-labs/thirdparty/staging/ install}
 
 And then install them in the {\em target} space:
 
-\begin{verbatim}
-cd ..
-cp -a staging/usr/bin/ogg* target/usr/bin
-arm-linux-strip target/usr/bin/ogg*
-\end{verbatim}
+\begin{terminalinput}
+$ cd ..
+$ cp -a staging/usr/bin/ogg* target/usr/bin
+$ arm-linux-strip target/usr/bin/ogg*
+\end{terminalinput}
 
 You can now test that everything works! Run \code{ogg123} on the
 sample file found in \code{thirdparty/data}.
@@ -937,12 +901,10 @@ \section{vorbis-tools}
 toolchain \code{target/usr/bin} directory.
 
 You can now run \code{ogg123} through \code{strace}:
-\begin{verbatim}
-strace ogg123 /sample.ogg
-\end{verbatim}
+\bashcmd{$ strace ogg123 /sample.ogg}
 
 You can see that the command fails to open the \code{ld-uClibc.so.1} file:
-\begin{verbatim}
+\begin{terminaloutput}
 open("/lib/ld-uClibc.so.1", O_RDONLY)   = -1 ENOENT (No such file or directory)
 open("/lib/ld-uClibc.so.1", O_RDONLY)   = -1 ENOENT (No such file or directory)
 open("/usr/lib/ld-uClibc.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
@@ -951,7 +913,7 @@ \section{vorbis-tools}
 write(2, "ERROR: Failed to load plugin ", 29ERROR: Failed to load plugin ) = 29
 write(2, "/usr/lib/ao/plugins-4/libalsa.so", 32/usr/lib/ao/plugins-4/libalsa.so) = 32
 write(2, " => dlopen() failed\n", 20 => dlopen() failed
-\end{verbatim}
+\end{terminaloutput}
 
 Now, look for \code{ld-uClibc.so.1} in the toolchain. You can see that both \code{ld-uClibc.so.1}
 and \code{ld-uClibc.so.0} are symbolic links to the same file. So, create the missing
@@ -968,7 +930,4 @@ \section{vorbis-tools}
 
 To finish this lab completely, and to be consistent with what we've done before,
 let's strip the libraries in \code{target/lib}:
-
-\begin{verbatim}
-arm-linux-strip target/lib/*
-\end{verbatim}
+\bashcmd{$ arm-linux-strip target/lib/*}
diff --git a/labs/sysdev-tinysystem/sysdev-tinysystem.tex b/labs/sysdev-tinysystem/sysdev-tinysystem.tex
index 88ed84f46..8024cf7ee 100644
--- a/labs/sysdev-tinysystem/sysdev-tinysystem.tex
+++ b/labs/sysdev-tinysystem/sysdev-tinysystem.tex
@@ -57,11 +57,7 @@ \section{Setting up the NFS server}
 \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}:
 
-\footnotesize
-\begin{verbatim}
-/home/<user>/__SESSION_NAME__-labs/tinysystem/nfsroot 192.168.0.100(rw,no_root_squash,no_subtree_check)
-\end{verbatim}
-\normalsize
+\clinput{/home/<user>/__SESSION_NAME__-labs/tinysystem/nfsroot 192.168.0.100(rw,no_root_squash,no_subtree_check)}
 
 Of course, replace \code{<user>} by your actual user name.
 
@@ -72,9 +68,7 @@ \section{Setting up the NFS server}
 
 Then, restart the NFS server:
 
-\begin{verbatim}
-sudo service nfs-kernel-server restart
-\end{verbatim}
+\bashcmd{$ sudo service nfs-kernel-server restart}
 
 \section{Booting the system}
 
@@ -85,10 +79,11 @@ \section{Booting the system}
 So add settings to the \code{bootargs} environment variable,
 {\bf in just 1 line}:
 
-\begin{verbatim}
-setenv bootargs ${bootargs} root=/dev/nfs ip=192.168.0.100:::::eth0
-   nfsroot=192.168.0.1:/home/<user>/__SESSION_NAME__-labs/tinysystem/nfsroot,nfsvers=3,tcp rw
-\end{verbatim}
+\begin{ubootinput}
+=> setenv bootargs ${bootargs} root=/dev/nfs ip=192.168.0.100:::::eth0 
+    nfsroot=192.168.0.1:/home/<user>/__SESSION_NAME__-labs/tinysystem/nfsroot,
+    nfsvers=3,tcp rw
+\end{ubootinput}
 
 Once again, replace \code{<user>} by your actual user name.
 
@@ -123,12 +118,11 @@ \section{Booting the system}
 Now, the kernel should complain for the last time, saying that it can't
 find an init application:
 
-\footnotesize
 \begin{verbatim}
-Kernel panic - not syncing: No working init found.  Try passing init= option to kernel.
+Kernel panic - not syncing: No working init found.  Try passing init= option to 
+kernel.
   See Linux Documentation/init.txt for guidance.
 \end{verbatim}
-\normalsize
 
 Obviously, our root filesystem being mostly empty, there isn't such an
 application yet. In the next paragraph, you will add Busybox to your root
@@ -279,9 +273,7 @@ \section{Implement a web interface for your device}
 
 Now, run the BusyBox http server from the target command line:
 
-\begin{verbatim}
-/usr/sbin/httpd -h /www/
-\end{verbatim}
+\ubootcmd{=> /usr/sbin/httpd -h /www/}
 
 It will automatically background itself.
 
diff --git a/labs/sysdev-toolchain/sysdev-toolchain.tex b/labs/sysdev-toolchain/sysdev-toolchain.tex
index cbe5429f7..f103101e8 100644
--- a/labs/sysdev-toolchain/sysdev-toolchain.tex
+++ b/labs/sysdev-toolchain/sysdev-toolchain.tex
@@ -18,7 +18,7 @@ \section{Install needed packages}
 Install the packages needed for this lab:
 
 \begin{terminalinput}
-sudo apt install build-essential git autoconf bison flex texinfo help2man gawk libtool-bin libncurses5-dev
+$ sudo apt install build-essential git autoconf bison flex texinfo help2man gawk libtool-bin libncurses5-dev
 \end{terminalinput}
 
 \section{Getting Crosstool-ng}
@@ -26,11 +26,11 @@ \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{verbatim}
-git clone https://github.com/crosstool-ng/crosstool-ng.git
-cd crosstool-ng/
-git checkout 79fcfa17
-\end{verbatim}
+\begin{terminalinput}
+$ git clone https://github.com/crosstool-ng/crosstool-ng.git
+$ cd crosstool-ng/
+$ git checkout 79fcfa17
+\end{terminalinput}
 
 \section{Building and installing Crosstool-ng}
 
@@ -39,21 +39,21 @@ \section{Building and installing Crosstool-ng}
 solution. As documented at
 \url{https://crosstool-ng.github.io/docs/install/#hackers-way}, do:
 
-\begin{verbatim}
-./bootstrap
-\end{verbatim}
+\begin{terminalinput}
+$ ./bootstrap
+\end{terminalinput}
 
 You can continue:
-\begin{verbatim}
-./configure --enable-local
-make
-\end{verbatim}
+\begin{terminalinput}
+$ ./configure --enable-local
+$ make
+\end{terminalinput}
 
 Then you can get Crosstool-ng help by running
 
-\begin{verbatim}
-./ct-ng help
-\end{verbatim}
+\begin{terminalinput}
+$ ./ct-ng help
+\end{terminalinput}
 
 \section{Configure the toolchain to produce}
 
@@ -72,9 +72,9 @@ \section{Configure the toolchain to produce}
 
 Then, to refine the configuration, let's run the \code{menuconfig} interface:
 
-\begin{verbatim}
-./ct-ng menuconfig
-\end{verbatim}
+\begin{terminalinput}
+$ ./ct-ng menuconfig
+\end{terminalinput}
 
 In \code{Path and misc options}:
 \begin{itemize}
@@ -138,9 +138,9 @@ \section{Produce the toolchain}
 
 Nothing is simpler:
 
-\begin{verbatim}
-./ct-ng build
-\end{verbatim}
+\begin{terminalinput}
+$ ./ct-ng build
+\end{terminalinput}
 
 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 @@ \section{Testing the toolchain}
 \code{hello.c} program in your main lab directory with
 \code{arm-linux-gcc}:
 
-\begin{verbatim}
-arm-linux-gcc -o hello hello.c
-\end{verbatim}
+\begin{terminalinput}
+$ arm-linux-gcc -o hello hello.c
+\end{terminalinput}
 
 You can use the \code{file} command on your binary to make sure it has
 correctly been compiled for the ARM architecture.
@@ -183,23 +183,29 @@ \section{Testing the toolchain}
 To do this, install the QEMU user emulator, which just emulates target
 instruction sets, not an entire system with devices:
 
-\begin{verbatim}
-sudo apt install qemu-user
-\end{verbatim}
+\begin{terminalinput}
+$ sudo apt install qemu-user
+\end{terminalinput}
 
 Now, try to run QEMU ARM user emulator:
 
 \begin{terminalinput}
-qemu-arm hello
-/lib/ld-uClibc.so.0: No such file or directory
+$ qemu-arm hello
 \end{terminalinput}
 
+\begin{terminaloutput}
+/lib/ld-uClibc.so.0: No such file or directory
+\end{terminaloutput}
+
 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}
+$ find ~/x-tools -name ld-uClibc.so.0
+\end{terminalinput} 
+
 \begin{terminaloutput}
-find ~/x-tools -name ld-uClibc.so.0
 /home/tux/x-tools/arm-training-linux-uclibcgnueabihf/arm-training-linux-uclibcgnueabihf/sysroot/lib/ld-uClibc.so.0
 \end{terminaloutput}
 
@@ -207,10 +213,13 @@ \section{Testing the toolchain}
 where shared libraries are:
 
 \begin{terminalinput}
-qemu-arm -L ~/x-tools/arm-training-linux-uclibcgnueabihf/arm-training-linux-uclibcgnueabihf/sysroot hello
-Hello world!
+$ qemu-arm -L ~/x-tools/arm-training-linux-uclibcgnueabihf/arm-training-linux-uclibcgnueabihf/sysroot hello
 \end{terminalinput}
 
+\begin{terminaloutput}
+Hello world!
+\end{terminaloutput}
+
 \section{Cleaning up}
 
 {\em Do this only if you have limited storage space. In case you made a
diff --git a/labs/sysdev-u-boot/sysdev-u-boot.tex b/labs/sysdev-u-boot/sysdev-u-boot.tex
index b10389680..4d9563b03 100644
--- a/labs/sysdev-u-boot/sysdev-u-boot.tex
+++ b/labs/sysdev-u-boot/sysdev-u-boot.tex
@@ -31,19 +31,18 @@
 
 \section{Downloading Microchip's flashing tool}
 
-Go to the \code{$HOME/__SESSION_NAME__-labs/bootloader} directory.
-
+Go to the \code{$HOME/__SESSION_NAME__-labs/bootloader} directory.\\
 We're going to use that fallback mode, and its associated tool,
-\code{sam-ba} ({\em SAM Boot Assistant}).
-
+\code{sam-ba} ({\em SAM Boot Assistant}).\\
 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{verbatim}
-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{verbatim}
+\begin{terminalinput}
+$ 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}
 
 \section{Setting up serial communication with the board}
 
@@ -62,16 +61,16 @@ \section{Setting up serial communication with the board}
 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}
+\begin{terminalinput}
+$ sudo apt install picocom
+\end{terminalinput}
 
 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}
+\begin{terminalinput}
+$ sudo adduser $USER dialout
+\end{terminalinput}
 
 {\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
@@ -120,11 +119,11 @@ \section{Configuring and compiling U-Boot}
 
 Get U-Boot sources:
 
-\begin{verbatim}
-git clone https://gitlab.denx.de/u-boot/u-boot
-cd u-boot
-git checkout v2020.07
-\end{verbatim}
+\begin{terminalinput}
+$ git clone https://gitlab.denx.de/u-boot/u-boot
+$ cd u-boot
+$ git checkout v2020.07
+\end{terminalinput}
 
 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
@@ -140,7 +139,7 @@ \section{Configuring and compiling U-Boot}
 
 \item Set the \code{CROSS_COMPILE} environment variable;
 
-\item Run \code{make <NAME>_defconfig}, where the list of available
+\item Run \inlinecode{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
@@ -148,14 +147,14 @@ \section{Configuring and compiling U-Boot}
   on the NAND, use the latter.
 
 \item Now that you have a valid initial configuration, you can now
-  run \code{make menuconfig} to further edit your bootloader features.
+  run \inlinecode{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{verbatim}
-sudo apt install device-tree-compiler
-\end{verbatim}
+\begin{terminalinput}
+$ sudo apt install device-tree-compiler
+\end{terminalinput}
 
 \item Finally, run \code{make}, which should build the two stages of U-Boot:
 \begin{itemize}
@@ -185,23 +184,21 @@ \section{Flashing SPL and U-Boot}
 Getting back to the \code{bootloader} directory, use \code{sam-ba} to erase
 NAND flash before writing images to it:
 
-\begin{verbatim}
-./sam-ba_3.3.1/sam-ba -p serial -b sama5d3-xplained -a nandflash -c erase
-\end{verbatim}
+\begin{terminalinput}
+$ ./sam-ba_3.3.1/sam-ba -p serial -b sama5d3-xplained -a nandflash -c erase
+\end{terminalinput}
 
 Then flash the U-Boot SPL:
 
-\begin{verbatim}
-./sam-ba_3.3.1/sam-ba -p serial -b sama5d3-xplained -a nandflash \
--c writeboot:u-boot/spl/u-boot-spl.bin
-\end{verbatim}
+\begin{terminalinput}
+$ ./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}
 
 Then flash the U-Boot binary:
 
-\begin{verbatim}
-./sam-ba_3.3.1/sam-ba -p serial -b sama5d3-xplained -a nandflash \
--c write:u-boot/u-boot.bin:0x40000
-\end{verbatim}
+\begin{terminalinput}
+$ ./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}
 
 \section{Testing U-Boot}
 
@@ -234,9 +231,9 @@ \section{Setting up Ethernet communication}
 Linux system.
 
 Find the name of this interface by typing:
-\begin{verbatim}
-ip a
-\end{verbatim}
+\begin{terminalinput}
+$ ip a
+\end{terminalinput}
 
 The network interface name is likely to be
 \code{enxxx}\footnote{Following the {\em Predictable Network Interface
@@ -248,38 +245,38 @@ \section{Setting up Ethernet communication}
 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}
+\begin{terminalinput}
+$ nmcli con add type ethernet ifname en... ip4 192.168.0.1/24
+\end{terminalinput}
 
 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}
 
 The first time you use your board, you also need to set the MAC
 address in U-boot:
 
-\begin{verbatim}
-setenv ethaddr 12:34:56:ab:cd:ef
-\end{verbatim}
+\begin{ubootinput}
+=> setenv ethaddr 12:34:56:ab:cd:ef
+\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 0x22000000 textfile.txt
-\end{verbatim}
+\begin{ubootinput}
+=> tftp 0x22000000 textfile.txt
+\end{ubootinput}
 
 The \code{tftp} command should have downloaded the
 \code{textfile.txt} file from your development workstation into
@@ -301,9 +298,9 @@ \section{Setting up Ethernet communication}
 You can verify that the download was successful by dumping the
 contents of the memory:
 
-\begin{verbatim}
-md 0x22000000
-\end{verbatim}
+\begin{ubootinput}
+=> md 0x22000000
+\end{ubootinput}
 
 We will see in the next labs how to use U-Boot to download, flash and
 boot a kernel.