[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
Link       : http://git.free-electrons.com/training-materials/commit/?id=4ac68a91d98883666d2ec4253bf37c1c266c39e2

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

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
index 856d4c8..0515adc 100644
--- 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}
 
-Add \code{bootchartd} to your \code{BusyBox} configuration
-\footnote{Hint: to find where \code{bootchartd} support can be
+Add \code{bootchartd} to your \code{BusyBox} configuration\footnote{
+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
 \url{http://prdownloads.sourceforge.net/bootchart/bootchart-0.9.tar.bz2}.}
 \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.}
 and boot your system:
 \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
index 5bee81a..b2e8cad 100644
--- 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
 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
+(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> }
         for reading and \code{<i2c_address> <register> <value>} for
         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
 reading registers fails, you can use a \code{return;} statement instead
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.
 
 Compile your module and load it on your target. Check the kernel log
 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
 pkg-config} database about the location of the header files and the
 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
index 17adad8..cec1ea9 100644
--- 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}.
 
-We first need to download this tool, from Atmel's website
-\footnote{In case this website is down, you can also find this
+We first need to download this tool, from Atmel's website\footnote{
+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}
 
-Now reset your board \footnote{Resetting your board is needed to
+Now reset your board\footnote{Resetting your board is needed to
 make your \code{ethaddr} permanent, for obscure reasons. If you
 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{tftp} command should have downloaded
-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
+The \code{tftp} command should have downloaded 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
 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



More information about the training-materials-updates mailing list