# [FE training-materials-updates] Footnote spacing fixes

Michael Opdenacker michael.opdenacker at free-electrons.com
Thu Jul 16 09:55:50 CEST 2015

Repository : git://git.free-electrons.com/training-materials.git

On branch  : master

>---------------------------------------------------------------

commit 4ac68a91d98883666d2ec4253bf37c1c266c39e2
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date:   Thu Jul 16 09:53:36 2015 +0200

Footnote spacing fixes

- Bad to have a space or punctuation mark before a footnote,
as LaTeX could decice to put the footnote on the next line (ugly)

Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>

>---------------------------------------------------------------

4ac68a91d98883666d2ec4253bf37c1c266c39e2
labs/android-boot/android-boot.tex                 |  4 ++--
.../android-native-library.tex                     |  2 +-
labs/android-new-board/android-new-board.tex       |  6 +++---
labs/boottime-application/boottime-application.tex |  8 ++++----
.../boottime-getting-started.tex                   |  6 +++---
.../boottime-init-scripts.tex                      | 14 ++++++-------
labs/boottime-kernel/boottime-kernel.tex           | 21 ++++++++++----------
labs/boottime-measuring/boottime-measuring.tex     | 14 ++++++-------
labs/buildroot-basic/buildroot-basic.tex           |  4 ++--
labs/kernel-board-setup/kernel-board-setup.tex     | 19 +++++++++---------
.../kernel-compiling-and-nfs-booting.tex           |  4 ++--
labs/kernel-debugging/kernel-debugging.tex         |  2 +-
.../kernel-i2c-communication.tex                   |  8 ++++----
.../kernel-i2c-device-model.tex                    |  4 ++--
.../kernel-i2c-input-interface.tex                 |  2 +-
.../kernel-serial-interrupt.tex                    |  2 +-
labs/kernel-serial-iomem/kernel-serial-iomem.tex   |  2 +-
labs/kernel-serial-output/kernel-serial-output.tex |  5 ++---
.../kernel-sources-exploring.tex                   |  6 +++---
.../sysdev-application-development.tex             |  4 ++--
.../sysdev-block-filesystems.tex                   | 23 +++++++++++-----------
.../sysdev-flash-filesystems.tex                   | 20 +++++++++----------
labs/sysdev-tinysystem/sysdev-tinysystem.tex       |  7 +++----
labs/sysdev-u-boot/sysdev-u-boot.tex               | 23 +++++++++++-----------
labs/yocto-first-build/yocto-first-build.tex       |  4 ++--
25 files changed, 102 insertions(+), 112 deletions(-)

diff --git a/labs/android-boot/android-boot.tex b/labs/android-boot/android-boot.tex
index a8164af..bf73f42 100644
--- a/labs/android-boot/android-boot.tex
+++ b/labs/android-boot/android-boot.tex
@@ -58,8 +58,8 @@ and every time you work with a new terminal.
Go back to \code{$HOME/android-labs/source}. All you need to do is source the environment and run the \code{lunch} -command to specify which product you're working with -\footnote{Remember that Android sources allow you to work with +command to specify which product you're working with\footnote +{Remember that Android sources allow you to work with multiple products}: \begin{verbatim} diff --git a/labs/android-native-library/android-native-library.tex b/labs/android-native-library/android-native-library.tex index 09d6d39..bb72cd6 100644 --- a/labs/android-native-library/android-native-library.tex +++ b/labs/android-native-library/android-native-library.tex @@ -35,7 +35,7 @@ You will find one missing header that you will need to generate. Indeed, the \code{config.h} generated by autoconf is not generated at all, because the Android build system ignores other build systems. You will have to generate it by yourself, by running the -\code{configure} script \footnote{You can have some hints about the +\code{configure} script\footnote{You can have some hints about the available options available by passing the \code{--help} argument to \code{configure}} that you can find in the \code{libusb} source code. The git repository doesn't have this \code{configure} script diff --git a/labs/android-new-board/android-new-board.tex b/labs/android-new-board/android-new-board.tex index 5af08d5..b10a5fd 100644 --- a/labs/android-new-board/android-new-board.tex +++ b/labs/android-new-board/android-new-board.tex @@ -143,10 +143,10 @@ You can also see this device appear by looking at the output of the \code{dmesg} command. To communicate with the board through the serial port, install a -serial communication program, such as \code{picocom}: -\footnote{\code{picocom} is one of the simplest utilities to access a +serial communication program, such as \code{picocom}\footnote +{\code{picocom} is one of the simplest utilities to access a serial console. \code{minicom} looks more featureful, but is also - more complex to configure.} + more complex to configure.}: \begin{verbatim} sudo apt-get install picocom diff --git a/labs/boottime-application/boottime-application.tex b/labs/boottime-application/boottime-application.tex index 9877880..bd83b74 100644 --- a/labs/boottime-application/boottime-application.tex +++ b/labs/boottime-application/boottime-application.tex @@ -54,8 +54,8 @@ Also have \code{strace} generate a summary: strace -c -f -o strace-summary.log /root/go.sh \end{verbatim} -Take some time to read \code{strace.log} -\footnote{At this stage, when you have to open files directly on the +Take some time to read \code{strace.log}\footnote{ +At this stage, when you have to open files directly on the board, some familiarity with the basic commands of the \code{vi} editor becomes useful. See \url{http://free-electrons.com/doc/command_memento.pdf} for a basic @@ -90,6 +90,6 @@ which the code is familiar to you. In this particular case, \code{gst-launch} is far from being the most efficient way of opening the video. It is really meant to help creating a multimedia pipeline. Once it is well defined, the \code{GStreamer} -developers recommend to directly program with the \code{GStreamer} API -\footnote{See the details on +developers recommend to directly program with the \code{GStreamer} +API\footnote{See the details on \url{http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+10\%3A+GStreamer+tools}}. diff --git a/labs/boottime-getting-started/boottime-getting-started.tex b/labs/boottime-getting-started/boottime-getting-started.tex index a56ec8e..6e245fd 100644 --- a/labs/boottime-getting-started/boottime-getting-started.tex +++ b/labs/boottime-getting-started/boottime-getting-started.tex @@ -41,10 +41,10 @@ sudo adduser$USER dialout
You need to log out and in again for the group change to be effective.

To communicate with the board through the serial port, install a
-serial communication program, such as \code{picocom}:
-\footnote{\code{picocom} is one of the simplest utilities to access a
+serial communication program, such as \code{picocom}\footnote{
+\code{picocom} is one of the simplest utilities to access a
serial console. It works in a simple terminal. \code{minicom} has more
-features, but is also more complex to configure.}
+features, but is also more complex to configure.}:

\begin{verbatim}
sudo apt-get install picocom
diff --git a/labs/boottime-init-scripts/boottime-init-scripts.tex b/labs/boottime-init-scripts/boottime-init-scripts.tex
--- a/labs/boottime-init-scripts/boottime-init-scripts.tex
+++ b/labs/boottime-init-scripts/boottime-init-scripts.tex
@@ -9,8 +9,8 @@ time consumers.

\subsection{Use bootchartd on the board}

-\footnote{Hint: to find where \code{bootchartd} support can be
+Hint: to find where \code{bootchartd} support can be
added in the \code{BusyBox} configuration interface, press the \code{/}
key (search command). This will tell you in which submenu the
corresponding option can be found.}.
@@ -75,8 +75,8 @@ install a few Java packages:
sudo apt-get install ant openjdk-6-jdk
\end{verbatim}

-Now, get the \code{bootchart} source code
-\footnote{The source code was originally found on
+Now, get the \code{bootchart} source code\footnote{The source
+code was originally found on
\footnote{Don't try to get the \code{bootchart} package supplied by
Ubuntu instead. While it has similar functionality, it looks like a completely
@@ -223,10 +223,10 @@ Now run \code{make} and make sure that
\code{output/target/etc/init.d/rcS} has the new right contents.

Reflash your system, and reboot it through \code{grabserial} to
-measure the new total boot time.
-\footnote{Note that we are no longer bothered by SSH key generation,
+measure the new total boot time\footnote{Note that we are no longer
+bothered by SSH key generation,
as it starts after our video is played. Therefore, one reboot
-after reflashing is now sufficient.}
+after reflashing is now sufficient.}.

Write down your results in the table at the end of this chapter.

diff --git a/labs/boottime-kernel/boottime-kernel.tex b/labs/boottime-kernel/boottime-kernel.tex
index c40f693..44d8a26 100644
--- a/labs/boottime-kernel/boottime-kernel.tex
+++ b/labs/boottime-kernel/boottime-kernel.tex
@@ -47,13 +47,13 @@ Save your configuration. We are ready to compile our kernel:
make -j 8 uImage
\end{verbatim}

-Keep a backup copy of your original kernel image, and copy the new one:
-\footnote{So far, we are lucky to have a kernel with most drivers
+Keep a backup copy of your original kernel image, and copy the new
+one\footnote{So far, we are lucky to have a kernel with most drivers
compiled inside the kernel. If we had important drivers compiled
as modules, we would need to compile the kernel with Buildroot,
to put the updated modules in the root filesystem. We are also lucky
not to have to update the Device Tree Binary, as we are using
-the same kernel sources as the demo.}
+the same kernel sources as the demo.}:

\begin{verbatim}
cd ../../flashing/sama5d3xek-demo
@@ -66,8 +66,8 @@ Reflash your system and make it boots in the same way as before.
Now, let's enable \code{initcall_debug}. Reboot your board and press
a key to stop the U-boot countdown.

-In the U-boot command line, add settings to the kernel command line
-\footnote{Don't save these settings with \code{saveenv}. We
+In the U-boot command line, add settings to the kernel command
+line\footnote{Don't save these settings with \code{saveenv}. We
will just need them once.}
\begin{verbatim}
@@ -106,10 +106,9 @@ inkscape boot.svg

Now review the longuest initcalls in detail. Each label is the name of
a function in the kernel sources. Try to find out in which source file
-each function is defined
-\footnote{You can do it with utilities such as \code{cscope}, which your
-instructor will be happy to demonstrate, or through our on-line service
-to explore the Linux kernel sources:
+each function is defined\footnote{You can do it with utilities such as
+\code{cscope}, which your instructor will be happy to demonstrate,
+or through our on-line service to explore the Linux kernel sources:
\url{http://lxr.free-electrons.com}}, and what each driver corresponds
to.

@@ -190,8 +189,8 @@ Check that your modules have been added to the root filesystem:
find output/target -name *.ko
\end{verbatim}

-The last thing to do is to load the necessary modules in a manual way
-\footnote{Oops, we don't have \code{udev} any more, and it would have
+The last thing to do is to load the necessary modules in a manual
+way\footnote{Oops, we don't have \code{udev} any more, and it would have
done it for us. However, manually loading modules is no big deal, and a
simpler solution for hotplug events can still be put in place anyway.}
from the \code{/etc/init.d/rcS} file, before starting the services (SSH
diff --git a/labs/boottime-measuring/boottime-measuring.tex b/labs/boottime-measuring/boottime-measuring.tex
--- a/labs/boottime-measuring/boottime-measuring.tex
+++ b/labs/boottime-measuring/boottime-measuring.tex
@@ -198,7 +198,7 @@ a 64 bit version of Ubuntu.
It's important to understand how the various user space programs
are started in the system. They all originate from the \code{init}
program, which is the first and only program executed by the Linux
-kernel \footnote{There is one exception: the kernel can also run
+kernel\footnote{There is one exception: the kernel can also run
helpers to handle hotplug events.}, when it's done booting the device.

The programs that are executed by the \code{init} program can
@@ -214,18 +214,16 @@ understand how the video player is started.

Make sure you are in the \code{/opt/boot-time-labs/buildroot/buildroot-at91} directory.

-Copy the \code{../data/1frame.avi} file
-\footnote {Here's the command that was used to generate a video
-containing only the first frame of the original video: \\
+Copy the \code{../data/1frame.avi} file\footnote {Here's the command that
+was used to generate a video containing only the first frame of the original video: \\
\code{avconv -i MPEG2_480_272.avi -vcodec copy -acodec copy -frames 1
1frame.avi}}
to \code{board/atmel/sama5d3ek_demo/}, where the original video is
stored.

-Now, modify the \code{board/atmel/sama5d3ek_demo/post-build.sh} file
-\footnote{This script is called after compiling the root filesystem
-components, and is used to add custom scripts and files to the system.}
-
+Now, modify the \code{board/atmel/sama5d3ek_demo/post-build.sh}
+file\footnote{This script is called after compiling the root filesystem
+components, and is used to add custom scripts and files to the system.}:
\begin{itemize}
\item To copy the \code{1frame.avi} video to \code{/root} on the target
file system. Do this by looking for the instruction that copies the
diff --git a/labs/buildroot-basic/buildroot-basic.tex b/labs/buildroot-basic/buildroot-basic.tex
index 80590ca..189a75e 100644
--- a/labs/buildroot-basic/buildroot-basic.tex
+++ b/labs/buildroot-basic/buildroot-basic.tex
@@ -258,9 +258,9 @@ to one of the 48 pins headers. Using your special USB to Serial
the pin closest to the power supply connector (let's call it pin 1),
and the \code{TX} (red) and \code{RX} (green) wires to the pins 4
-(board \code{RX}) and 5 (board \code{TX}). \footnote{See
+(board \code{RX}) and 5 (board \code{TX})\footnote{See
\url{https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/}
-  for details about the USB to Serial adapter that we are using.}
+  for details about the USB to Serial adapter that we are using.}.

You always should make sure that you connect the \code{TX} pin of the
cable to the \code{RX} pin of the board, and vice-versa, whatever the
diff --git a/labs/kernel-board-setup/kernel-board-setup.tex b/labs/kernel-board-setup/kernel-board-setup.tex
index b70040e..f75b37c 100644
--- a/labs/kernel-board-setup/kernel-board-setup.tex
+++ b/labs/kernel-board-setup/kernel-board-setup.tex
@@ -26,8 +26,8 @@ We are going to download documents which we will need during our
practical labs.

The first document to download is the board System Reference Manual found at
-\url{https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true}
-\footnote{There is a link to this manual on the above page}.
+\url{https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true}\footnote{
+There is a link to this manual on the above page}.
This is the ultimate reference about the board, giving all the details
about the design of the board and the components which were chosen.
You don't have to start reading this document now but you will need it
@@ -50,9 +50,9 @@ of the 48 pins headers. Using your special USB to Serial adaptor provided
by your instructor, connect the ground wire (blue) to the pin closest
to the power supply connector (let's call it pin 1), and the \code{TX} (red)
and \code{RX} (green) wires to the pins 4 (board \code{RX}) and
-5 (board \code{TX}). \footnote{See
+5 (board \code{TX})\footnote{See
\url{https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/}
-for details about the USB to Serial adaptor that we are using.}
+for details about the USB to Serial adaptor that we are using.}.

You always should make sure that you connect the \code{TX} pin of the cable
to the \code{RX} pin of the board, and vice versa, whatever the board and
@@ -112,10 +112,9 @@ You can now use U-Boot. Run the \code{help} command to see the available
commands.

Using the \code{version} command, make sure that you have at least version
-\code{2013.10}.
-\footnote{This will be needed to use the \code{saveenv} command to
+\code{2013.10}\footnote{This will be needed to use the \code{saveenv} command to
save your U-Boot environment settings to the boards' eMMC storage.
-Some earlier versions do not support this.}
+Some earlier versions do not support this.}.

If you are doing these labs on your own (i.e. without participating to a Free Electrons
course), we ask you to install the U-Boot binary that we compiled and
@@ -185,12 +184,12 @@ setenv ipaddr 192.168.0.100
setenv serverip 192.168.0.1
\end{verbatim}

-Save these settings to the eMMC storage on the board:
-\footnote{The U-boot environment settings are stored in some free space
+Save these settings to the eMMC storage on the board\footnote{
+The U-boot environment settings are stored in some free space
between the master boot record (512 bytes, containing the partition
tables and other stuff), and the beginning of the first partition (often
at \code{32256}). This is why you won't find any related file in the
-first partition of the eMMC storage.}
+first partition of the eMMC storage.}:

\begin{verbatim}
saveenv
diff --git a/labs/kernel-compiling-and-nfs-booting/kernel-compiling-and-nfs-booting.tex b/labs/kernel-compiling-and-nfs-booting/kernel-compiling-and-nfs-booting.tex
index c1d36b2..cfd7fc1 100644
--- a/labs/kernel-compiling-and-nfs-booting/kernel-compiling-and-nfs-booting.tex
+++ b/labs/kernel-compiling-and-nfs-booting/kernel-compiling-and-nfs-booting.tex
@@ -8,11 +8,11 @@ After this lab, you will be able to:
\item Cross-compile the Linux kernel for the ARM platform.

\item Boot this kernel on an NFS root filesystem, which is somewhere
-on your development workstation.\footnote{NFS root filesystems are
+on your development workstation\footnote{NFS root filesystems are
particularly useful to compile modules on your host, and make them
directly visible on the target. You no longer have to update the root
filesystem by hand and transfer it to the target (requiring a shutdown
-and reboot).}
+and reboot).}.

\end{itemize}

diff --git a/labs/kernel-debugging/kernel-debugging.tex b/labs/kernel-debugging/kernel-debugging.tex
index 55cd6c8..0ba7fdc 100644
--- a/labs/kernel-debugging/kernel-debugging.tex
+++ b/labs/kernel-debugging/kernel-debugging.tex
@@ -107,7 +107,7 @@ arm-linux-gnueabi-objdump -S vmlinux > vmlinux.disasm

or, using \code{gdb-multiarch}\footnote{gdb-multiarch is a new package
supporting multiple architectures at once. If you have a cross
-toolchain including gdb, you can also run arm-linux-gdb directly.}
+toolchain including gdb, you can also run arm-linux-gdb directly.}:

\begin{verbatim}
sudo apt-get install gdb-multiarch
diff --git a/labs/kernel-i2c-communication/kernel-i2c-communication.tex b/labs/kernel-i2c-communication/kernel-i2c-communication.tex
index aa5c686..691096e 100644
--- a/labs/kernel-i2c-communication/kernel-i2c-communication.tex
+++ b/labs/kernel-i2c-communication/kernel-i2c-communication.tex
@@ -204,8 +204,8 @@ In the probe routine (run every time a matching device is found):

\begin{enumerate}
\item Using the I2C raw API (see the slides), send two bytes to the
-      device: \code{0xf0} and \code{0x55}
-      \footnote{The I2C messages to communicate with a wiimote
+      device: \code{0xf0} and \code{0x55}\footnote{
+	The I2C messages to communicate with a wiimote
extension are in the form: \code{<i2c_address> <register> }
writing. The address, \code{0x52} is sent by the i2c framework
@@ -275,8 +275,8 @@ As explained on
Using boolean operators, write code that initializes a \code{zpressed}
integer variable, which value is \code{1} when the \code{Z} button is
pressed, and \code{0} otherwise. Create a similar \code{cpressed}
-variable for the \code{C} button.\footnote{You may use the \code{BIT()}
-macro, which will make your life easier. See LXR for details.}
+variable for the \code{C} button\footnote{You may use the \code{BIT()}
+macro, which will make your life easier. See LXR for details.}.

The last thing is to test the states of these new variables at the end
of the \code{probe()} function, and log a message to the console
diff --git a/labs/kernel-i2c-device-model/kernel-i2c-device-model.tex b/labs/kernel-i2c-device-model/kernel-i2c-device-model.tex
index 4c19382..7346ec6 100644
--- a/labs/kernel-i2c-device-model/kernel-i2c-device-model.tex
+++ b/labs/kernel-i2c-device-model/kernel-i2c-device-model.tex
@@ -88,7 +88,7 @@ In this new file, we will have to do two things:
First, find the DT definitions for (\code{i2c1}).

What is the base address of its registers? Also find the same address in
-the processor datasheet \footnote{Tip: to do your search, put an
+the processor datasheet\footnote{Tip: to do your search, put an
underscore character in the middle of the address, as in
\code{FFFF_FFFF}... that's how addresses are written in the
TI datasheet).}.
@@ -102,7 +102,7 @@ enough so far!
As a child node to this second bus, declare the \code{nunchuk}
device, choosing \code{nintendo,nunchuk} for its \code{compatible}
property. You will find the I2C slave address of the nunchuk on the
-nunckuk document that we have used earlier \footnote{This I2C slave
+nunckuk document that we have used earlier\footnote{This I2C slave
addressed is enforced by the device itself. You can't change it.}.

\subsection{Checking the device tree on the running system}
diff --git a/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex b/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
index 2bff805..fb44da3 100644
--- a/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
+++ b/labs/kernel-i2c-input-interface/kernel-i2c-input-interface.tex
@@ -182,7 +182,7 @@ private \code{nunchuk} structure.
Now that you have a handle on the I2C physical device, you can move the
code reading the nunchuk registers to this function. You can
remove the double reading of the device state, as the polling function
-will make periodic reads anyway \footnote{During the move, you will have
+will make periodic reads anyway\footnote{During the move, you will have
to handle communication errors in a slightly different way, as the
\code{nunchuk_poll()} routine has a \code{void} type. When the function
diff --git a/labs/kernel-serial-interrupt/kernel-serial-interrupt.tex b/labs/kernel-serial-interrupt/kernel-serial-interrupt.tex
index a3a4108..18d1104 100644
--- a/labs/kernel-serial-interrupt/kernel-serial-interrupt.tex
+++ b/labs/kernel-serial-interrupt/kernel-serial-interrupt.tex
@@ -135,7 +135,7 @@ To do so, add a wait queue to our \code{feserial_dev} structure,
named for example \code{serial_wait}. In the \code{read()} function,
keep things simple by directly using \code{wait_event_interruptible()}
right from the start, to wait until \code{serial_buf_wr}
-is different from \code{serial_buf_rd}. \footnote{A single test in the
+is different from \code{serial_buf_rd}\footnote{A single test in the
\code{wait_event_interruptible()} function is sufficient. If the
condition is met, you don't go to sleep and read one character right away.
Otherwise, when you wake up, you can proceed to the reading part.}.
diff --git a/labs/kernel-serial-iomem/kernel-serial-iomem.tex b/labs/kernel-serial-iomem/kernel-serial-iomem.tex
index 493ce4f..76305dc 100644
--- a/labs/kernel-serial-iomem/kernel-serial-iomem.tex
+++ b/labs/kernel-serial-iomem/kernel-serial-iomem.tex
@@ -85,7 +85,7 @@ just declared in the device tree.

messages, that should confirm that the \code{probe()} routine was
-called \footnote{Don't be surprised if the \code{probe()} routine is
+called\footnote{Don't be surprised if the \code{probe()} routine is
actually called twice! That's because we have declared two devices.
Even if we only connect a serial-to-USB dongle to one of them, both
of them are ready to be used!}.
diff --git a/labs/kernel-serial-output/kernel-serial-output.tex b/labs/kernel-serial-output/kernel-serial-output.tex
index cf4383b..2dcfc98 100644
--- a/labs/kernel-serial-output/kernel-serial-output.tex
+++ b/labs/kernel-serial-output/kernel-serial-output.tex
@@ -96,10 +96,9 @@ At the moment, it is necessary to implement an \code{open} file
operation to attach a private structure to an open device file. This is
a bit ugly as we would have nothing special to do in such a function.

-Let's apply a patch that addresses this issue:
-\footnote{This patch has been submitted but hasn't been accepted yet in
+Let's apply a patch that addresses this issue\footnote{This patch has been submitted but hasn't been accepted yet in
the mainline kernel, because it breaks the \code{FUSE} code which makes
-weird assumptions about the {\em misc} framework.}
+weird assumptions about the {\em misc} framework.}:

\begin{itemize}
\item Go back to the Linux source directory. Make sure you are still in
diff --git a/labs/kernel-sources-exploring/kernel-sources-exploring.tex b/labs/kernel-sources-exploring/kernel-sources-exploring.tex
index 5f9408f..52a7691 100644
--- a/labs/kernel-sources-exploring/kernel-sources-exploring.tex
+++ b/labs/kernel-sources-exploring/kernel-sources-exploring.tex
@@ -46,9 +46,9 @@ implements a given function. So, it is useful to be familiar with
exploring the kernel sources.

\begin{enumerate}
-\item Find the Linux logo image in the sources.
-      \footnote{Look for files in \code{logo} in their name. It's an
-      opportunity to practise with the \code{find} command.}
+\item Find the Linux logo image in the sources\footnote{Look for
+      files in \code{logo} in their name. It's an
+      opportunity to practise with the \code{find} command.}.
\item Find who the maintainer of the MVNETA network driver is.
\item Find the declaration of the \code{platform_device_register()} function.
\end{enumerate}
diff --git a/labs/sysdev-application-development/sysdev-application-development.tex b/labs/sysdev-application-development/sysdev-application-development.tex
index ae6be40..f51170c 100644
--- a/labs/sysdev-application-development/sysdev-application-development.tex
+++ b/labs/sysdev-application-development/sysdev-application-development.tex
@@ -40,10 +40,10 @@ normal, since we didn't tell the compiler to link with the necessary
libraries. So let's use \code{pkg-config} to query the {\em
list of libraries needed to build an application against
-{\em ncurses}:\footnote{Again, \code{output/host/usr/bin} has a special
+{\em ncurses}\footnote{Again, \code{output/host/usr/bin} has a special
\code{pkg-config} that automatically knows where to look, so it
already knows the right paths to find \code{.pc} files and their
-sysroot.}
+sysroot.}:

\begin{verbatim}
arm-linux-gcc -o app app.c $(pkg-config --libs --cflags ncurses) diff --git a/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex b/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex index 7c0ef39..0163b33 100644 --- a/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex +++ b/labs/sysdev-block-filesystems/sysdev-block-filesystems.tex @@ -28,9 +28,9 @@ Recompile your kernel with support for SquashFS and ext3. Update your kernel image in NAND flash. Boot your board with this new kernel and on the NFS filesystem you -used in this previous lab.\footnote{If you didn't do or complete the +used in this previous lab\footnote{If you didn't do or complete the tinysystem lab, you can use the \code{data/rootfs} directory - instead.} + instead.}. Now, check the contents of \code{/proc/filesystems}. You should see that ext3 and SquashFS are now supported. @@ -50,7 +50,7 @@ sd 3:0:0:0: [sdb] 3842048 512-byte hardware sectors: (1.96 GB/1.83 GiB) If your PC has an internal MMC/SD card reader, the device may also been seen as \code{/dev/mmcblk0}, and the first partition as -\code{mmcblk0p1}. \footnote{This is not always the case with internal +\code{mmcblk0p1}\footnote{This is not always the case with internal MMC/SD card readers. On some PCs, such devices are behind an internal USB bus, and thus are visible in the same way external card readers are}. You will see that the MMC/SD card is seen in the same @@ -108,15 +108,14 @@ following properties: \item One partition, 64MB big, with the \code{FAT16} partition type. -\item One partition, 8 MB big - \footnote{For the needs of our system, the partition could even be - much smaller, and 1 MB would be enough. However, with the 8 GB SD - cards that we use in our labs, 8 MB will be the smallest partition - that \code{cfdisk} will allow you to create.}, - that will be used for the root - filesystem. Due to the geometry of the device, the partition might - be larger than 8 MB, but it does not matter. Keep the \code{Linux} - type for the partition. +\item One partition, 8 MB big\footnote{For the needs of our system, + the partition could even be much smaller, and 1 MB would be enough. + However, with the 8 GB SD cards that we use in our labs, 8 MB will + be the smallest partition that \code{cfdisk} will allow you to + create.}, that will be used for the root filesystem. Due to the + geometry of the device, the partition might be larger than 8 MB, + but it does not matter. Keep the \code{Linux} type for the + partition. \item One partition, that fills the rest of the MMC card, that will be used for the data filesystem. Here also, keep the \code{Linux} type diff --git a/labs/sysdev-flash-filesystems/sysdev-flash-filesystems.tex b/labs/sysdev-flash-filesystems/sysdev-flash-filesystems.tex index 02010fb..db19bdb 100644 --- a/labs/sysdev-flash-filesystems/sysdev-flash-filesystems.tex +++ b/labs/sysdev-flash-filesystems/sysdev-flash-filesystems.tex @@ -141,15 +141,14 @@ Download the UBI image (using \code{tftp}) you have created in the previous section and flash it on the UBI partition. When flashing the UBI image, use the \code{trimffs} version of the -command \code{nand write}. -\footnote{The command \code{nand write.trimffs} skips +command \code{nand write}\footnote{The command \code{nand write.trimffs} skips the blank sectors instead of writing them. It is needed because the algorithm used by the hardware ECC for the SAMA5D3 SoC generates a checksum with bytes different of 0xFF if the page is blank. Linux only checks the page, and if it is blank it doesn't erase it, but as the OOB is not blank it leads to ECC errors. More generally it is not recommended writing more than one time on a page and its OOB - even if the page is blank.} + even if the page is blank.}. Because of a bug in the UBI layer implemented by U-Boot, you'll have to reboot the board after flashing the UBI image. @@ -164,14 +163,13 @@ Set the \code{bootargs} variable so that: \begin{itemize} \item The \code{mtdparts} environment variable content is passed to - the kernel through cmdline -\footnote{Remember you can tweak your bootargs using u-boot env - variables before booting the kernel. To achieve that, create a - \code{bootargs_base} variable where you will store all the kernel - parameters except the mtdparts one. Then modify your \code{bootcmd} - to append the \code{mtdparts} definition to \code{bootargs_base} - before calling \code{bootz}: - \code{setenv bootargs$bootargs_base $mtdparts}} + the kernel through cmdline\footnote{Remember you can tweak your + \code{bootargs} using u-boot env variables before booting the kernel. + To achieve that, create a \code{bootargs_base} variable where you + will store all the kernel parameters except the \code{mtdparts} + one. Then modify your \code{bootcmd} to append the \code{mtdparts} + definition to \code{bootargs_base} before calling \code{bootz}: + \code{setenv bootargs$bootargs_base \$mtdparts}}.
\item The UBI partition is automatically attached to the UBI layer at
boot time
\item The root filesystem is mounted from the root volume, and is mounted
diff --git a/labs/sysdev-tinysystem/sysdev-tinysystem.tex b/labs/sysdev-tinysystem/sysdev-tinysystem.tex
--- a/labs/sysdev-tinysystem/sysdev-tinysystem.tex
+++ b/labs/sysdev-tinysystem/sysdev-tinysystem.tex
@@ -158,9 +158,8 @@ up shared libraries and recompile Busybox.
Build BusyBox using the toolchain that you used to build the kernel.

Going back to the BusyBox configuration interface
-specify the installation directory for BusyBox
-\footnote{You will find this setting in
-\code{Install Options -> BusyBox installation prefix}.}.
+specify the installation directory for BusyBox\footnote{You will find
+this setting in \code{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.
@@ -183,7 +182,7 @@ Now mount the \code{proc} virtual filesystem. Now that \code{/proc} is
available, test again the \code{ps} command.

Note that you can also now halt your target in a clean way with the \code{halt}
-command, thanks to \code{proc} being mounted \footnote{\code{halt}
+command, thanks to \code{proc} being mounted\footnote{\code{halt}
can find the list of mounted filesystems in \code{/proc/mounts}, and
unmount each of them in a clean way before shutting down.}.

diff --git a/labs/sysdev-u-boot/sysdev-u-boot.tex b/labs/sysdev-u-boot/sysdev-u-boot.tex
index 5d28ba8..cbaf0f6 100644
--- a/labs/sysdev-u-boot/sysdev-u-boot.tex
+++ b/labs/sysdev-u-boot/sysdev-u-boot.tex
@@ -49,8 +49,8 @@ sudo apt-get install libxss1 libxft2
We're going to use that fallback mode, and its associated tool,
\code{sam-ba}.

-\footnote{In case this website is down, you can also find this
+In case this website is down, you can also find this
tool on \url{http://free-electrons.com/labs/tools/}.}.

\begin{verbatim}
@@ -155,11 +155,10 @@ The next thing to do is to specific the cross-compiler prefix
export CROSS_COMPILE=arm-linux-
\end{verbatim}

-You can now start compiling using \code{make}
-\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 number of CPU cores is a
-  good value.}.
+You can now start compiling using \code{make}\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 number of CPU cores is a good value.}.

At the end of the compilation, you should have a file called
\code{sama5d3_xplained-nandflashboot-uboot-*.bin}, in the
@@ -355,7 +354,7 @@ To make these settings permanent, save the environment:
saveenv
\end{verbatim}

don't, U-boot will complain that \code{ethaddr} is not
set.}.
@@ -370,10 +369,10 @@ tftp 0x22000000 textfile.txt

\input{../errata/tftpd-hpa.tex}

-the \code{textfile.txt} file from your development
-workstation into the board's memory at location \code{0x22000000}
-\footnote{This location is part of the board DRAM. If you want
+\code{textfile.txt} file from your development workstation into
+the board's memory at location \code{0x22000000}\footnote{
+This location is part of the board DRAM. If you want
to check where this value comes from, you can check the Atmel SAMA5D3
datasheet at \url{http://www.atmel.com/tools/ATSAMA5D3-XPLD.aspx},
following the {\em Documents} link. It's a big document (more than 1,800
diff --git a/labs/yocto-first-build/yocto-first-build.tex b/labs/yocto-first-build/yocto-first-build.tex
index 8da07d7..1476d48 100644
--- a/labs/yocto-first-build/yocto-first-build.tex
+++ b/labs/yocto-first-build/yocto-first-build.tex
@@ -124,9 +124,9 @@ of the 48 pins headers. Using your special USB to Serial adapter provided
by your instructor, connect the ground wire (blue) to the pin closest
to the power supply connector (let's call it pin 1), and the \code{TX} (red)
and \code{RX} (green) wires to the pins 4 (board \code{RX}) and
-5 (board \code{TX}). \footnote{See
+5 (board \code{TX})\footnote{See
\url{https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/}
-for details about the USB to Serial adapter that we are using.}
+for details about the USB to Serial adapter that we are using.}.

You always should make sure that you connect the \code{TX} pin of the cable
to the \code{RX} pin of the board, and vice-versa, whatever the board and