[bootlin/training-materials updates] master: labs/buildroot-*: use bashinput/fileinput macros where appropriate (9db9bc34)
Thomas Petazzoni
thomas.petazzoni at bootlin.com
Sat May 29 21:07:05 CEST 2021
Repository : https://github.com/bootlin/training-materials
On branch : master
Link : https://github.com/bootlin/training-materials/commit/9db9bc34b7eb37008ef884670f25916c35d025ea
>---------------------------------------------------------------
commit 9db9bc34b7eb37008ef884670f25916c35d025ea
Author: Thomas Petazzoni <thomas.petazzoni at bootlin.com>
Date: Sat May 29 21:07:05 2021 +0200
labs/buildroot-*: use bashinput/fileinput macros where appropriate
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at bootlin.com>
>---------------------------------------------------------------
9db9bc34b7eb37008ef884670f25916c35d025ea
.../buildroot-advanced-packages.tex | 32 ++++-----
labs/buildroot-advanced/buildroot-advanced.tex | 32 ++++-----
labs/buildroot-appdev/buildroot-appdev.tex | 64 ++++++++---------
labs/buildroot-basic/buildroot-basic.tex | 46 ++++++------
.../buildroot-new-packages.tex | 14 ++--
labs/buildroot-rootfs/buildroot-rootfs.tex | 82 +++++++++++-----------
6 files changed, 135 insertions(+), 135 deletions(-)
diff --git a/labs/buildroot-advanced-packages/buildroot-advanced-packages.tex b/labs/buildroot-advanced-packages/buildroot-advanced-packages.tex
index f229518a..90d619dc 100644
--- a/labs/buildroot-advanced-packages/buildroot-advanced-packages.tex
+++ b/labs/buildroot-advanced-packages/buildroot-advanced-packages.tex
@@ -149,38 +149,38 @@ is available on GitHub at \code{https://github.com/tpetazzoni/bar}.
Start by cloning the Git repository:
-\begin{verbatim}
+\begin{bashinput}
git clone https://github.com/tpetazzoni/bar.git
-\end{verbatim}
+\end{bashinput}
Once the cloning is done, go inside the \code{bar} directory, and
create a new branch named \code{buildroot}, which starts the
\code{v1.0} tag (which matches the \code{bar-1.0.tar.xz} tarball we're
using):
-\begin{verbatim}
+\begin{bashinput}
git branch buildroot v1.0
-\end{verbatim}
+\end{bashinput}
Move to this newly created branch\footnote{Yes, we can use \code{git
checkout -b} to create the branch and move to it in one command}:
-\begin{verbatim}
+\begin{bashinput}
git checkout buildroot
-\end{verbatim}
+\end{bashinput}
Do the \code{#include <libconfig.h>} change to \code{src/main.c}, and
commit the result:
-\begin{verbatim}
+\begin{bashinput}
git commit -a -m "Fix missing <libconfig.h> include"
-\end{verbatim}
+\end{bashinput}
Generate the patch for the last commit (i.e the one you just created):
-\begin{verbatim}
+\begin{bashinput}
git format-patch HEAD^
-\end{verbatim}
+\end{bashinput}
and copy the generated \code{0001-*.patch} file to \code{package/bar/}
in the Buildroot sources.
@@ -191,16 +191,16 @@ built fully successfully!
You can even check that \code{bar} is linked against
\code{libconfig.so} by doing:
-\begin{verbatim}
+\begin{bashinput}
./output/host/usr/bin/arm-none-linux-gnueabihf-readelf -d output/target/usr/bin/bar
-\end{verbatim}
+\end{bashinput}
On the target, test \code{bar}. Then, create a file called
\code{bar.cfg} in the current directory, with the following contents:
-\begin{verbatim}
+\begin{fileinput}
verbose = "yes"
-\end{verbatim}
+\end{fileinput}
And run \code{bar} again, and see what difference it makes.
@@ -212,6 +212,6 @@ in the world!
In preparation for the next lab, we need to do a clean full rebuild,
so simply issue:
-\begin{verbatim}
+\begin{bashinput}
make clean all 2>&1 | tee build.log
-\end{verbatim}
+\end{bashinput}
diff --git a/labs/buildroot-advanced/buildroot-advanced.tex b/labs/buildroot-advanced/buildroot-advanced.tex
index 4d4a7a1b..6ef89d1c 100644
--- a/labs/buildroot-advanced/buildroot-advanced.tex
+++ b/labs/buildroot-advanced/buildroot-advanced.tex
@@ -23,9 +23,9 @@ since Epoch).
Now, let's get a better visualization of this raw data:
-\begin{verbatim}
+\begin{bashinput}
make graph-build
-\end{verbatim}
+\end{bashinput}
Note: you may need to install \code{python-matplotlib} on your machine.
@@ -60,9 +60,9 @@ package may have different dependencies.
To generate the full dependency graph, do:
-\begin{verbatim}
+\begin{bashinput}
make graph-depends
-\end{verbatim}
+\end{bashinput}
The graph is also generated in \code{output/graphs}, under the name
\code{graph-depends.pdf}. On the graph, identify the \code{bar} and
@@ -72,15 +72,15 @@ dependencies to see if they match your expectations.
Now, let's draw a graph for a much bigger system. To do this, create a
completely separate Buildroot output directory:
-\begin{verbatim}
+\begin{bashinput}
mkdir $HOME/__SESSION_NAME__-labs/buildroot-output-test-graph/
cd $HOME/__SESSION_NAME__-labs/buildroot-output-test-graph/
-\end{verbatim}
+\end{bashinput}
We're going to create a Buildroot configuration, so create a file
named \code{.config} and put the following contents:
-\begin{verbatim}
+\begin{fileinput}
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_MESA3D=y
@@ -91,7 +91,7 @@ BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
BR2_PACKAGE_LIBGTK3=y
BR2_PACKAGE_WEBKITGTK=y
-\end{verbatim}
+\end{fileinput}
It represents a configuration that builds an internal toolchain, with
a X.org graphic server, the Mesa3D OpenGL implementation, the Gtk3
@@ -102,24 +102,24 @@ generate the dependency graph for it.
First, let's run \code{make menuconfig} to expand this minimal
configuration into a full configuration:
-\begin{verbatim}
+\begin{bashinput}
make -C $HOME/__SESSION_NAME__-labs/buildroot/ O=$(pwd) menuconfig
-\end{verbatim}
+\end{bashinput}
Feel free to explore the configuration at this stage. Now, let's
generate the dependency graph:
-\begin{verbatim}
+\begin{bashinput}
make graph-depends
-\end{verbatim}
+\end{bashinput}
Look at \code{graphs/graph-depends.pdf} and how complex it is. Now,
let's look at the dependencies of one specific package, let's say
\code{libgtk3}:
-\begin{verbatim}
+\begin{bashinput}
make libgtk3-graph-depends
-\end{verbatim}
+\end{bashinput}
Now, open the graph generated at
\code{graphs/libgtk3-graph-depends.pdf}. As you can see, it is a lot
@@ -146,9 +146,9 @@ the generated embedded Linux system, and their corresponding licenses.
Let's generate this report for our system:
-\begin{verbatim}
+\begin{bashinput}
make legal-info
-\end{verbatim}
+\end{bashinput}
In the output, you can see some interesting messages:
diff --git a/labs/buildroot-appdev/buildroot-appdev.tex b/labs/buildroot-appdev/buildroot-appdev.tex
index 11bbc5ec..133af6c3 100644
--- a/labs/buildroot-appdev/buildroot-appdev.tex
+++ b/labs/buildroot-appdev/buildroot-appdev.tex
@@ -15,34 +15,34 @@ demonstration in this lab. Create a folder \code{$HOME/__SESSION_NAME__-labs/mya
and inside this folder a single C file called \code{myapp.c} with the
following contents:
-\begin{verbatim}
+\begin{fileinput}
#include <stdio.h>
int main(void) {
printf("Hello World\n");
return 0;
}
-\end{verbatim}
+\end{fileinput}
To build this application, we'll use the cross-compiler generated by
Buildroot. To make this easy, let's add the Buildroot host directory
into our PATH:
-\begin{verbatim}
+\begin{bashinput}
export PATH=$HOME/__SESSION_NAME__-labs/buildroot/output/host/bin:$PATH
-\end{verbatim}
+\end{bashinput}
Now you can build your application easily:
-\begin{verbatim}
+\begin{bashinput}
arm-none-linux-gnueabihf-gcc -o myapp myapp.c
-\end{verbatim}
+\end{bashinput}
Copy the myapp binary to your target using scp:
-\begin{verbatim}
+\begin{bashinput}
scp myapp root at 192.168.0.2:
-\end{verbatim}
+\end{bashinput}
And run the \code{myapp} application on your target.
@@ -53,16 +53,16 @@ this lab data directory, \code{myapp.c}.
If you try to build this application with just:
-\begin{verbatim}
+\begin{bashinput}
arm-none-linux-gnueabihf-gcc -o myapp myapp.c
-\end{verbatim}
+\end{bashinput}
It fails to build because it does not link with \code{libconfig}. So
you can manually do:
-\begin{verbatim}
+\begin{bashinput}
arm-none-linux-gnueabihf-gcc -o myapp myapp.c -lconfig
-\end{verbatim}
+\end{bashinput}
Since \code{libconfig.so} is in \code{output/staging/usr/lib} and the
compiler is configured to automatically look in \code{output/staging}
@@ -73,22 +73,22 @@ has installed a special version of \code{pkg-config} in
\code{output/host/bin}, which you can query for libraries
available for the target. Run:
-\begin{verbatim}
+\begin{bashinput}
pkg-config --list-all
-\end{verbatim}
+\end{bashinput}
And check you have \code{libconfig} mentionned. You can query the
compiler and linker flags for \code{libconfig}:
-\begin{verbatim}
+\begin{bashinput}
pkg-config --cflags --libs libconfig
-\end{verbatim}
+\end{bashinput}
And use that to build your application:
-\begin{verbatim}
+\begin{bashinput}
arm-none-linux-gnueabihf-gcc -o myapp myapp.c $(pkg-config --cflags --libs libconfig)
-\end{verbatim}
+\end{bashinput}
In the case of \code{libconfig}, it doesn't simplify a lot because the
compiler and linker flags are simple, but for some other libraries,
@@ -108,9 +108,9 @@ The {\em ARM} toolchain is provided with a pre-compiled {\em
\code{BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY}, and then force the
re-installation of the toolchain using:
-\begin{verbatim}
+\begin{bashinput}
make toolchain-external-arm-arm-reinstall
-\end{verbatim}
+\end{bashinput}
Reflash your system, or alternatively, just copy
\code{output/target/usr/bin/gdbserver} to the target \code{/usr/bin/}
@@ -138,42 +138,42 @@ available. So we need to do two things:
Now, on your target, start {\em gdbserver} in multi-process mode,
listening on TCP port 2345:
-\begin{verbatim}
+\begin{bashinput}
gdbserver --multi localhost:2345
-\end{verbatim}
+\end{bashinput}
Back on the host, run the cross-gdb with the \code{myapp} application
as argument:
-\begin{verbatim}
+\begin{bashinput}
arm-none-linux-gnueabihf-gdb myapp
-\end{verbatim}
+\end{bashinput}
We need to tell \code{gdb} where the libraries can be found:
-\begin{verbatim}
+\begin{bashinput}
(gdb) set sysroot output/staging
-\end{verbatim}
+\end{bashinput}
And then connect to the target:
-\begin{verbatim}
+\begin{bashinput}
(gdb) target extended-remote 192.168.0.2:2345
-\end{verbatim}
+\end{bashinput}
Define which program we want to run on the target:
-\begin{verbatim}
+\begin{bashinput}
(gdb) set remote exec-file myapp
-\end{verbatim}
+\end{bashinput}
Let's put a breakpoint on the \code{main} function, and start the
program:
-\begin{verbatim}
+\begin{bashinput}
(gdb) break main
(gdb) run
-\end{verbatim}
+\end{bashinput}
It stops on the first line of the \code{main} function, which is the
call to \code{config_init}, implemented by the \code{libconfig}
diff --git a/labs/buildroot-basic/buildroot-basic.tex b/labs/buildroot-basic/buildroot-basic.tex
index f444d352..592c4dd9 100644
--- a/labs/buildroot-basic/buildroot-basic.tex
+++ b/labs/buildroot-basic/buildroot-basic.tex
@@ -20,26 +20,26 @@ manual\footnote{\url{https://buildroot.org/downloads/manual/manual.html\#require
Buildroot requires a few packages to be installed on your
machine. Let's install them using Ubuntu's package manager:
-\begin{verbatim}
+\begin{bashinput}
sudo apt install sed make binutils gcc g++ bash patch \
gzip bzip2 perl tar cpio python unzip rsync wget libncurses-dev
-\end{verbatim}
+\end{bashinput}
\section{Download Buildroot}
Since we're going to do Buildroot development, let's clone the
Buildroot source code from its Git repository:
-\begin{verbatim}
+\begin{bashinput}
git clone git://git.buildroot.net/buildroot
-\end{verbatim}
+\end{bashinput}
If your company blocks the {\em Git} protocol (they should not!), then
you can try to clone over HTTP:
-\begin{verbatim}
+\begin{bashinput}
git clone https://git.buildroot.net/git/buildroot.git
-\end{verbatim}
+\end{bashinput}
In the worst case, if neither work, you can download the Buildroot
tarball \code{buildroot-2021.02.tar.bz2} from
@@ -52,9 +52,9 @@ Go into the newly created \code{buildroot} directory.
We're going to start a branch from the {\em 2021.02} Buildroot
release, with which this training has been tested.
-\begin{verbatim}
+\begin{bashinput}
git checkout -b felabs 2021.02
-\end{verbatim}
+\end{bashinput}
\section{Configuring Buildroot}
@@ -66,9 +66,9 @@ our own configuration from scratch!
Start the Buildroot configuration utility:
-\begin{verbatim}
+\begin{bashinput}
make menuconfig
-\end{verbatim}
+\end{bashinput}
Of course, you're free to try out the other configuration utilities
\code{nconfig}, \code{xconfig} or \code{gconfig}.
@@ -259,9 +259,9 @@ You could simply run \code{make}, but since we would like to keep a
log of the build, we'll redirect both the standard and error outputs
to a file, as well as the terminal by using the \code{tee} command:
-\begin{verbatim}
+\begin{bashinput}
make 2>&1 | tee build.log
-\end{verbatim}
+\end{bashinput}
While the build is on-going, please go through the following sections
to prepare what will be needed to test the build results.
@@ -296,18 +296,18 @@ appear by looking at the output of \code{dmesg}.
To communicate with the board through the serial port, install a
serial communication program, such as \code{picocom}:
-\begin{verbatim}
+\begin{bashinput}
sudo apt install picocom
-\end{verbatim}
+\end{bashinput}
If you run \code{ls -l /dev/ttyUSB0}, you can also see that only
\code{root} and users belonging to the \code{dialout} group have read
and write access to this file. Therefore, you need to add your user to
the \code{dialout} group:
-\begin{verbatim}
+\begin{bashinput}
sudo adduser $USER dialout
-\end{verbatim}
+\end{bashinput}
{\bf Important}: for the group change to be effective, in Ubuntu 18.04, you have to
{\em completely reboot} the system \footnote{As explained on
@@ -341,18 +341,18 @@ on the SD card:
\item Extract the \code{rootfs.tar} file to the \code{rootfs}
partition of the SD card, using:\\
- \code{sudo tar -C /media/$USER/rootfs/ -xf output/images/rootfs.tar}.
+ \inlinebash{sudo tar -C /media/$USER/rootfs/ -xf output/images/rootfs.tar}.
\item Create a file named \code{extlinux/extlinux.conf} in the
\code{boot} partition. This file should contain the following lines:
{\small
-\begin{verbatim}
+\begin{fileinput}
label buildroot
kernel /zImage
devicetree /am335x-boneblack-wireless.dtb
append console=ttyO0,115200 root=/dev/mmcblk1p2 rootwait
-\end{verbatim}
+\end{fileinput}
}
These lines teach the U-Boot bootloader how to load the Linux kernel
@@ -384,10 +384,10 @@ and \code{/etc}.
Note: if your system doesn't boot as expected, make sure to reset the
U-Boot environment by running the following U-Boot commands:
-\begin{verbatim}
+\begin{bashinput}
env default -f -a
saveenv
-\end{verbatim}
+\end{bashinput}
and reset. This is needed because the U-Boot loaded from the SD card
still loads the U-Boot environment from the eMMC. Ask your instructor
@@ -401,9 +401,9 @@ happened. Since the Buildroot build is quite verbose, Buildroot prints
before each important step a message prefixed by the \code{>>>}
sign. So to get an overall idea of what the build did, you can run:
-\begin{verbatim}
+\begin{bashinput}
grep ">>>" build.log
-\end{verbatim}
+\end{bashinput}
You see the different packages between downloaded, extracted, patched,
configured, built and installed.
diff --git a/labs/buildroot-new-packages/buildroot-new-packages.tex b/labs/buildroot-new-packages/buildroot-new-packages.tex
index e13e3c98..2036733e 100644
--- a/labs/buildroot-new-packages/buildroot-new-packages.tex
+++ b/labs/buildroot-new-packages/buildroot-new-packages.tex
@@ -23,7 +23,7 @@ option to enable this package, and a minimal \code{ninvaders.mk} file
that specifies what is needed just to {\em download} the package.
For reference, the download URL of the {\em nInvaders} tarball is
-\code{https://sourceforge.net/projects/ninvaders/files/ninvaders/0.1.1/}.
+\url{https://sourceforge.net/projects/ninvaders/files/ninvaders/0.1.1/}.
Note: to achieve this, only two variables need to be defined in
\code{.mk} file, plus the call to the appropriate package
@@ -73,15 +73,15 @@ has already been built.
So, let's force Buildroot to rebuild the package by removing its
source directory completely:
-\begin{verbatim}
+\begin{bashinput}
make ninvaders-dirclean
-\end{verbatim}
+\end{bashinput}
And then starting the build:
-\begin{verbatim}
+\begin{bashinput}
make
-\end{verbatim}
+\end{bashinput}
This time, you should see the \code{ninvaders 0.1.1 Building} step
actually doing something, but quickly failing with a message saying
@@ -230,9 +230,9 @@ installed? If so, why?
If you want to verify if your package matches the coding style rules
of Buildroot, you can run:
-\begin{verbatim}
+\begin{bashinput}
make check-package
-\end{verbatim}
+\end{bashinput}
While a successful result doesn't mean your package is perfect, it at
least verifies a number of basic requirements.
diff --git a/labs/buildroot-rootfs/buildroot-rootfs.tex b/labs/buildroot-rootfs/buildroot-rootfs.tex
index 696253ce..2163ca14 100644
--- a/labs/buildroot-rootfs/buildroot-rootfs.tex
+++ b/labs/buildroot-rootfs/buildroot-rootfs.tex
@@ -4,9 +4,9 @@
\begin{itemize}
\item Explore the build output
\item Customize the root filesystem using a {\em rootfs overlay}
+ \item Customize the Linux kernel configuration
\item Use a post-build script
- \item Customize the kernel with patches and additional configuration
- options
+ \item Customize the kernel with patches and
\item Add more packages
\item Use {\em defconfig} files and {\em out of tree} build
\end{itemize}
@@ -89,7 +89,7 @@ interfaces. So, in \code{board/felabs/beagleboneblack/rootfs-overlay},
create a file named \code{etc/network/interfaces} with the following
contents:
-\begin{verbatim}
+\begin{fileinput}
auto lo
iface lo inet loopback
@@ -97,7 +97,7 @@ auto usb0
iface usb0 inet static
address 192.168.0.2
netmask 255.255.255.0
-\end{verbatim}
+\end{fileinput}
Then, rebuild your system by running \code{make}. Here as well, we
don't need to do a full rebuild, since the {\em rootfs overlays} are
@@ -126,9 +126,9 @@ hardcoded in the \code{S30usbgadget} script to
To configure an IP address for this interface on your host machine,
we'll use NetworkManager and its command line interface:
-\begin{verbatim}
+\begin{bashinput}
nmcli con add type ethernet ifname enxf8dc7a000001 ip4 192.168.0.1/24
-\end{verbatim}
+\end{bashinput}
{\em Note: using \code{ip} in the command line is not
recommended, because Network Manager will unconfigure and
@@ -161,10 +161,10 @@ built, and will therefore trigger the build process.
Re-extract the root filesystem tarball in the \code{rootfs} partition
of the SD card. Don't forget to replace the entire root filesystem:
-\begin{verbatim}
+\begin{bashinput}
rm -rf /media/$USER/rootfs/*
sudo tar -C /media/$USER/rootfs/ -xf output/images/rootfs.tar
-\end{verbatim}
+\end{bashinput}
Now, boot the new system on the BeagleBone Black. You should see a
message:
@@ -175,9 +175,9 @@ Starting dropbear sshd: OK
Now, from your PC, if you try to SSH to the board by doing:
-\begin{verbatim}
+\begin{bashinput}
ssh root at 192.168.0.2
-\end{verbatim}
+\end{bashinput}
You'll notice that it is very slow to open the connection: this is due
to the lack of hardware random number generator support. In the next
@@ -190,9 +190,9 @@ Until now, our Linux kernel was configured using the
\code{omap2plus_defconfig} configuration provided in the Linux kernel
source code. Let's customize our kernel configuration by running:
-\begin{verbatim}
+\begin{bashinput}
make linux-menuconfig
-\end{verbatim}
+\end{bashinput}
In the kernel configuration, enable the following kernel options (use
the \code{/} search engine to easily find those options):
@@ -226,7 +226,7 @@ changes persistently. To do so:
\item Exit \code{menuconfig}
-\item Run \code{make linux-update-defconfig}. This will generate the
+\item Run \inlinebash{make linux-update-defconfig}. This will generate the
configuration file in
\code{board/felabs/beagleboneblack/linux.config}. It will be a {\em
minimal} configuration file (i.e a {\em defconfig}). In this file,
@@ -265,17 +265,17 @@ We will first create a new directory to store our kernel patches. It
will sit next to our {\em rootfs overlay} in our project-specific
directory:
-\begin{verbatim}
+\begin{bashinput}
mkdir board/felabs/beagleboneblack/patches/linux/
-\end{verbatim}
+\end{bashinput}
Copy in this directory the two patches that we provided with the data
of this lab, in \code{$HOME/buildroot-labs/buildroot-rootfs/linux/}:
-\begin{verbatim}
+\begin{bashinput}
cp $HOME/buildroot-labs/buildroot-rootfs/linux/*.patch \
board/felabs/beagleboneblack/patches/linux/
-\end{verbatim}
+\end{bashinput}
The first patch adds the driver, the second patch adjusts the Device
Tree. Feel free to look at them. If you're interested, you can look at
@@ -291,9 +291,9 @@ Let's now clean up completely the \code{linux} package so that its
sources will be re-extracted and our patches applied the next time we
do a build:
-\begin{verbatim}
+\begin{bashinput}
make linux-dirclean
-\end{verbatim}
+\end{bashinput}
If you check in \code{output/build/}, the \code{linux-5.10.27}
directory will have disappeared.
@@ -301,9 +301,9 @@ directory will have disappeared.
Now, we need to adjust our kernel configuration to enable the {\em Wii
Nunchuk} driver. To start the Linux kernel configuration tool, run:
-\begin{verbatim}
+\begin{bashinput}
make linux-menuconfig
-\end{verbatim}
+\end{bashinput}
This will:
@@ -324,18 +324,18 @@ options are set, leave the kernel \code{menuconfig}.
Let's save persistently our kernel configuration change:
-\begin{verbatim}
+\begin{bashinput}
make linux-update-defconfig
-\end{verbatim}
+\end{bashinput}
You can check \code{board/felabs/beagleboneblack/linux.config} and
verify that \kconfig{CONFIG_JOYSTICK_WIICHUCK} is set to \code{y}.
You can now restart the build of the kernel:
-\begin{verbatim}
+\begin{bashinput}
make
-\end{verbatim}
+\end{bashinput}
It should hopefully end successfully, and if you look closely at the
build log, you should see the file \code{wiichuck.c} being compiled.
@@ -379,21 +379,21 @@ input: Wiichuck expansion connector as /devices/platform/ocp/4802a000.i2c/i2c-1/
You can also explore {\em sysfs}, and see that your Nunchuk device is
handled by the system:
-\begin{verbatim}
+\begin{bashinput}
cat /sys/bus/i2c/devices/1-0052/name
-\end{verbatim}
+\end{bashinput}
Now, to get the raw events coming from the Nunchuk, you can do:
-\begin{verbatim}
+\begin{bashinput}
cat /dev/input/event0
-\end{verbatim}
+\end{bashinput}
or, if you prefer to see hexadecimal values instead of raw binary:
-\begin{verbatim}
+\begin{bashinput}
cat /dev/input/event0 | hexdump -C
-\end{verbatim}
+\end{bashinput}
You should see events when moving the Nunchuk (it has an
accelerometer), when moving the joystick and pushing the buttons.
@@ -407,9 +407,9 @@ and display them in a more human readable format: \code{evtest}.
Enable this package in Buildroot, restart the build, reflash the root
filesystem and reboot the system. Now you can use \code{evtest}:
-\begin{verbatim}
+\begin{bashinput}
evtest /dev/input/event0
-\end{verbatim}
+\end{bashinput}
\section{Generate a {\em defconfig}}
@@ -423,9 +423,9 @@ where Buildroot will save the {\em defconfig} file generated by
Then, exit \code{menuconfig}, and run:
-\begin{verbatim}
+\begin{bashinput}
make savedefconfig
-\end{verbatim}
+\end{bashinput}
Read the file \code{configs/felabs_defconfig} generated in the
Buildroot sources. You will see the values for all the options for
@@ -452,16 +452,16 @@ start a build from scratch. And to learn something new, we'll use {\em
To do so, create a build directory anywhere you want, and move inside
this directory:
-\begin{verbatim}
+\begin{bashinput}
mkdir ~/felabs/buildroot-build/
cd ~/felabs/buildroot-build/
-\end{verbatim}
+\end{bashinput}
Now, we will load the \code{felabs_defconfig}:
-\begin{verbatim}
+\begin{bashinput}
make -C ~/felabs/buildroot/ O=$(pwd) felabs_defconfig
-\end{verbatim}
+\end{bashinput}
Let's explain a little bit what happens here. By using
\code{-C ~/felabs/buildroot/}, we in fact tell \code{make} that the
@@ -489,6 +489,6 @@ This command will have two main effects:
Now that this is done, start the build. You can again save the build
log:
-\begin{verbatim}
+\begin{bashinput}
make 2>&1 | tee build.log
-\end{verbatim}
+\end{bashinput}
More information about the training-materials-updates
mailing list