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

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:

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.

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)

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.

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.

"Embedded System a la Carte"

"Memory Leak Detection in Embedded Systems"