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

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)