An Introduction to Embedded Linux Development, Part 4

This is the last part of our four-article series on beginning embedded
Linux development. Our intent was to provide an introduction to the typical embedded Linux
infrastructure so that a programmer familiar with working in a
desktop environment also might become productive in an embedded
environment. It should be stressed that reading this series does not mean
the participant now is an embedded systems programmer; rather, we wanted
to make the embedded environment more familiar. The desktop
programmer should be able to work productively in the embedded
environment, working on projects not much different than before.
To gain deep familiarity with the hardware, which is the
hallmark of the embedded systems programmer, is a much bigger
step. Hopefully, though, this series might encourage some to embark
on that journey.

We continue with the particular SBC that we used in
Part 1,
Part 2
and
Part 3,
the LBox from Engineering Technologies Canada Ltd. (Engtech). Despite
the use of a specific SBC here, much of the material has broader application
and should be useful generally for using the Background Debug Mode (BDM) with
Motorola microcontrollers.

By the end of Part 2 of this series, we had the LBox up and
running, ready to use for application development. In Part 3, we
looked at

• the memory organization and filesystem
  layout
• replacing the kernel and root filesystem
• replacing the JFFS2 filesystem
• replacing the bootloader

Several of the netflash/reboot iterations discussed in Part 3
can leave the LBox in a non-functional state, if the transferred
files are not correct. In particular, if the Linux image is bad,
netflash is not available to access the workstation's tftp
server. If the colilo binary is bad, we can't even start the
boot process. To recover, we need an extra piece of hardware and
some software components. They exploit the Background Debug Mode
(BDM) provided in various Motorola processors, including the
Coldfire family. In this article, we discuss the following
topics:

• BDM hardware
• BDM support installation
• the GDB initialization file (.gdbinit)
• using the BDM device

BDM Hardware
To restore a non-functional LBox, we must purchase another piece of
hardware, the Coldfire Shielded BDM Interface, which has a small
printed circuit board allowing it to connect to the LBox. The BDM
Interface is available for $149 from
P&E Microcomputer Systems,
Inc. It connects by way of a parallel port cable from the workstation
host to the LBox. It comes in a 3.3- and a 5.0-volt version. It also is
available as a pass-through item from Engtech, the LBox vendor. The small
printed circuit board is available from Engtech as well. It is quite
inexpensive, with final prices dependent on quantity ordered. One of
these setups then can be used as needed in support of multiple LBoxes,
so the cost is amortized easily.

The BDM and appropriate support circuitry allows one to access the
CPU, whatever the status of the bootloader. Hence, one can
reconstruct the LBox from any state. The BDM allows you to load
and start a kernel from memory, regardless of the whether the
bootloader or kernel are working or even installed on the LBox
device. The BDM package consists of two software components, a
driver module for the hardware and a modified GDB program. The
modified GDB program uses the BDM hardware driver to connect to
the LBox.
BDM Support Installation
With the LBox, Engtech provides a CD, which we used earlier in this
series. If you haven't copied that CD to your workstation, do so now. We
are going to use it now to install BDM support on the workstation. At the top
level of the CD directory hierarchy we find the BDM directory.
Carefully carry out the instructions in the file BDM_INSTALL
within the BDM directory. We found no glitches in these
instructions; they are quite explicit and trouble-free.

The next step in getting BDM support working is to load the BDM
interface driver on your workstation. The driver is included
among the utilities installed with the LBox toolchain. Because the
interface to the LBox is by way of the parallel port, it is important
to remove competing drivers (using rmmod, such as the driver
modules lp or parport_pc, if they are installed. In order to install
the BDM driver, type modprobe bdm on your
workstation, as root. This loads the modules with a warning that the kernel has been
tainted. This occurs because the module source hasn't specified
the license, for example, MODULE_LICENSE("GPL"). This is not an issue
here, so we continue.

To check that the driver is loaded, run the lsmod
command. You should see the BDM module listed among other
modules in the output. We might, for example, see something like:

bdm                    24680   0  (unused)

The GDB Initialization File (.gdbinit)
Before we start using the modified GDB utility, let's look at
the .gdbinit file. It is located in the copied CD hierarchy, at
uClinux-dist/images/.gdbinit. This directory also holds the image
file transferred from the BDM to the LBox.

When it initializes, the bdm-modified GDB utility uses
the .gdbinit file to configure the underlying hardware.
If you look at the .gdbinit file with a text editor, you can see
that it performs two tasks. First, it sets up address variables
that are associated with device registers on the LBox. Second,
it uses those address variables to set up the LBox so it is
prepared to start the kernel when appropriate.
Using the BDM Device
Ensure that the hardware is configured properly and connected to the
workstation by a parallel port cable. We now can use the
bdm-modified GDB program to load a new image into the LBox
memory. The following command needs to be run from
the workstation's uClinux/images directory in order to use
the resident .gdbinit file.

m68k-bdm-elf-gdb image.elf

Notice that the image.elf file was created in Part 3 of this series,
when the uClinux source was compiled to create a new image.

If you have any problems with GDB/BDM utility, make sure the
BDM driver module is loaded and the BDM device is connected to the
LBox. Also, double check that competing modules, such as the lp
and parport_pc modules, are unloaded.

After you have started the GDB/BDM utility, you are presented
with the standard GDB command prompt. From this command prompt,
you need to load the binary kernel image with
(gdb)load. It takes some time for the BDM
to transfer the binary image to the LBox memory. Once that the binary kernel image is loaded
into memory, we next need to tell the LBox to start running this
kernel binary. This is done in the following scenario.

Set the program counter to the start memory location of the
kernel binary with (gdb)set $pc = _start.
Then, start running the code from there, with
(gdb)c. At this point, you can connect to the
LBox by using the serial port, exactly as you would without the BDM,
but resist the temptation to reboot the LBox. If the workstation already
was connected serially to the LBox, you would have seen the kernel startup
output.

Remember that this running kernel is only a temporary kernel. It was
loaded directly into the LBox memory instead of loading it from flash memory.
This means that if you are trying to update the kernel/root filesystem, you
still have to netflash a new kernel, as described in Part 3 of this
article series.
Resources
"Embedded System a
la Carte"
"Memory Leak
Detection in Embedded Systems"
Ben Anderson is an upper division Computer Science major at
Eastern Washington University. His current interests are hardware and
embedded systems, particularly those that use Linux.

Richard Sevenich is a Professor of Computer Science at Eastern
Washington University in Cheney, WA