treewide: Correct a bunch of typos found using codespell

Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>

Author: rgantois

labs/boot-time-bootloader/boot-time-bootloader.tex

@@ -104,7 +104,7 @@ \section{Using U-Boot's {\em Falcon} mode}
 Now, let's run the final preparation step. We will set the
 \code{bootargs} environment variable, load the kernel and DTB, and
 use U-Boot's \code{spl export} command to prepare a ready to boot record
-with the DTB contents, the \code{bootargs}, the kernel loading addreses
+with the DTB contents, the \code{bootargs}, the kernel loading address
 and other information that Linux would need to boot. Note that the
 U-Boot SPL will still load the \code{uImage} file from the FAT
 filesystem in the first partition of the SD card.

labs/boot-time-build-kernel-and-start-system/boot-time-build-kernel-and-start-system.tex

@@ -179,7 +179,7 @@ \section{Bootloader configuration}
 filesystem checks at boot time, depending on how the system was shut
 down, switched off or rebooted. Such filesystem checks can add a lot
 of jitter from one boot to another, making boot time measurements
-unpredicable and difficult to reproduce.
+unpredictable and difficult to reproduce.
 \end{itemize}
 
 Last but not least, save your changes:

labs/boot-time-init-scripts/boot-time-init-scripts.tex

@@ -164,7 +164,7 @@ \subsection{Detecting and eliminating unused files}
 It doesn't seem to be possible through the kernel command line, so,
 all we can do is change this mount option in our init executable.
 So, add the following two lines right after the first line at
-the begining of the \code{/playvideo} file:
+the beginning of the \code{/playvideo} file:
 
 \begin{verbatim}
 mount -t proc nodev /proc
@@ -455,7 +455,7 @@ \subsection{Switching to static executables}
 This should save a few extra bytes.
 
 Once more, write down the new size of the root filesystem tar archive.
-You should observe substancial space reduction. Let's keep this option!
+You should observe substantial space reduction. Let's keep this option!
 
 \subsection{Testing}
 Boot your system again.

labs/buildroot-appdev/buildroot-appdev.tex

@@ -79,7 +79,7 @@ \section{Build and run your own application}
 pkg-config --list-all
 \end{bashinput}
 
-And check you have \code{libconfig} mentionned. You can query the
+And check you have \code{libconfig} mentioned. You can query the
 compiler and linker flags for \code{libconfig}:
 
 \begin{bashinput}

labs/buildroot-basic-stm32/buildroot-basic-stm32.tex

@@ -219,7 +219,7 @@ \section{Configuring Buildroot}
 
   \item Select \code{Kconfig} as the \code{Build system}. U-Boot is
     transitioning from a situation where all the hardware platforms
-    were described in C header files to a system where U-Boot re-uses
+    were described in C header files to a system where U-Boot reuses
     the Linux kernel configuration logic. Since we are going to use a
     recent enough U-Boot version, we are going to use the latter,
     called {\em Kconfig}.

labs/buildroot-basic/buildroot-basic.tex

@@ -211,7 +211,7 @@ \section{Configuring Buildroot}
 
   \item Select \code{Kconfig} as the \code{Build system}. U-Boot is
     transitioning from a situation where all the hardware platforms
-    were described in C header files to a system where U-Boot re-uses
+    were described in C header files to a system where U-Boot reuses
     the Linux kernel configuration logic. Since we are going to use a
     recent enough U-Boot version, we are going to use the latter,
     called {\em Kconfig}.

labs/debugging-ebpf-bcc/debugging-ebpf-bcc.tex

@@ -44,7 +44,7 @@
 
 {\em Notes:
 \begin{itemize}
-    \item Since eBPF subsystem needs root priviledges to be manipulated, you need sudo to run the script
+    \item Since eBPF subsystem needs root privileges to be manipulated, you need sudo to run the script
     \item If you have made some mistakes in your eBPF program, the verifier
     will refuse to load it, or worse, it will not even build. BCC makes sure to
     print the relevant logs to ease debugging, so make sure to read

labs/debugging-ebpf-libbpf/debugging-ebpf-libbpf.tex

@@ -131,7 +131,7 @@ \section{Improving our program}
 part in this directory, as you will iterate on it. The directory provides a
 makefile which automates all build steps performed manually earlier. To use
 this makefile, make sure to have your \code{CROSS_COMPILE} variable
-properly set, as well as a \code{KDIR} variable pointing to your kernerl
+properly set, as well as a \code{KDIR} variable pointing to your kernel
 directory:
 \begin{bashinput}
 export KDIR=/home/$USER/__SESSION_NAME__-labs/buildroot/output/build/linux-%\workingkernel%

labs/debugging-kernel-debugging-frameworks/debugging-kernel-debugging-frameworks.tex

@@ -84,7 +84,7 @@ \section{Kmemleak}
 \end{bashinput}
 
 You can use \code{addr2line} to identify the location in source code of the
-lines that did cause the reports. You may need to substract module loading address:
+lines that did cause the reports. You may need to subtract module loading address:
 you can guess the address by taking a look at \code{/proc/modules} while the module
 is loaded.
 

labs/debugging-kernel-debugging-kexec-kdump-beagleplay/debugging-kernel-debugging-kexec-kdump-beagleplay.tex

@@ -61,7 +61,7 @@ \subsection{Configuring kexec}
 
 \textbf{Note:} it would have been very convenient to be able to retrieve
 the vmcore file over the network (e.g. using SSH), but as we are just
-restarting a new kernel without going throught the nominal boot chain, many
+restarting a new kernel without going through the nominal boot chain, many
 peripherals are not going to work correctly. This issue is due to other
 firmwares running on the board that are not properly reinitialized, and so
 refusing to reinit peripherals. The AM625 internal switch is one of those