The following products are covered in this manual.

Copyright Notice

© 2002, 2003, 2004, 2005 Cadenux, LLC, Inc. All rights reserved.

This document and the software described in it are furnished under license with Cadenux, and as such, may be used or copied only in accordance with the terms of the license. The contents of this document are furnished for informational purposes only and are subject to change without notice. Cadenux, assumes no responsibility or liability for any errors or inaccuracies that may exist in this document. No part of this document may be reproduced, stored in a retrieval system, or transmitted in any form, without the prior written consent of Cadenux.

Trademarks

Cadenux and DSPLinux are trademarks of Cadenux, LLC. ARM is a registered trademark of ARM Limited. Linux is a registered trademark of Linus Torvalds in the United States and other countries and is used by Cadenux under license. uClinux is a registered trademark of Arcturus Networks Inc. Intel and Pentium are registered trademarks of Intel Corporation. Red Hat is a registered trademark of Red Hat, Inc. Texas Instruments and TI are registered trademarks of Texas Instruments Incorporated. All other trademarks are the property of their respective owners.

Revision History

Table of Contents

1 Installing the Cadenux ARM BSP

1.1 Cadenux ARM BSP Target Processors
1.2 Linux Kernel Versions
1.3 Components of the Cadenux ARM BSP
1.4 System Requirements
1.5 Root Password Entry
1.6 Installing the Cadenux ARM BSP Software
1.7 Important Directories
1.8 Uninstalling the Software

2 Using the Target Hardware

2.1 Turning on the DSC25 EVM
2.2 Building the Cadenux BSP Components
2.3 Changing the BSP Configuration
2.4 Changing the Kernel Configuration
2.5 Changing the Target File System
2.6 Putting the New System on the Target Hardware
2.7 Writable File Systems

3 Using the GDB Debugger

3.1 The ARM GDB Debugger
3.2 Using the ARM7 GDB Debugger
3.3 Using the ARM9 GDB Debugger
3.4 Using the gdbinit

4 Networking

4.1 Default Kernel Configuration with Networking Enabled
4.2 Mounting the Target File System
4.3 Optional NFS Root Mount
4.4 10BaseT versus 100BaseT

5 Memory Map

5.1 Types of Memory Spaces
5.2 Hardware Memory Map
5.3 Flash Memory Map
5.4 System Memory Map

6 Serial Port

6.1 Program Access to /dev/ttyS0
6.2 System Console
6.3 Serial Settings
6.4 Changing Serial Port Settings
6.5 Kernel printk() over Serial

APPENDIX A URL Links to Related Web Sites
APPENDIX B Glossary
APPENDIX C Jumpers

APPENDIX C.1 AmRoad DSC25 EVM Jumpers
APPENDIX C.2 TI DM270 EVM Jumpers
APPENDIX C.3 TI DM320/DM342 EVM Jumpers
APPENDIX C.4 Motorola i.MX21 ADS Jumpers
APPENDIX C.5 Spectrum Digital C5471 EVM Jumpers
APPENDIX C.6 Appro DM320 EVM Jumpers

APPENDIX D GIO Usage

APPENDIX D.1 DM320/DM342 GIO proc File System Entry
APPENDIX D.2 TI DM320/DM342 GIO Usage

APPENDIX E Common minicom Problems

1 Installing the Cadenux ARM BSP

1.1 Cadenux ARM BSP Target Processors

There are different "flavors" of the Cadenux ARM BSPs depending on the target processor you plan to use. This manual covers all of Cadenux's Linux ports to target hardware which contain an ARM7 and ARM9 processor. The list of supported target processors include:

ARM7

• TI TMS320DSC21

• TI TMS320DSC24

• TI TMS320DSC25

• TI TMS320DM270

• TI TMS320VC5471

ARM9

• TI TMS320DM310

• TI TMS320DM320/DM342

• TI OMAP1510/5910

• Motorola i.MX21

Most of the information in this manual applies to all target processors. Separate tables or sections are used when there is a difference.

The examples use "<target processor>" when you need to refer to a specific target processor. Substitute "dsc21", "dsc24", "dsc25", "dm270", "c5471", "dm310" "dm320", "omap1510", or "mx2ads" as appropriate.

1.2 Linux Kernel Version

The biggest difference between ARM7 and the ARM9 kernel versions is that the ARM7 processors use a special version of Linux called uClinux; the ARM9 processors, on the other hand, use the standard Linux release. This is difference is a consequence of a fundamental difference between the ARM7 and the ARM9 processor architectures: The ARM9 architecture includes a Memory Management Unit or MMU; the ARM7 architecture does not. uClinux is a special version Linux for processor architectures like the ARM7 family that do not include an MMU. Other some minor programming issues, the uClinux and Linux kernels are functionally equivalent.

The Cadenux ARM7 BSP comes with either the uClinux 2.0.xx kernel or the uClinux 2.4.xx kernel. You can determine the exact kernel version by looking in the <development directory>/build/Make.context file.

At present, the Cadenux ARM9 BSP provides either the Linux 2.4.xx or Linux 2.6.xx kernel version.

Most of the information in this manual applies to all three versions of the Linux kernel. Separate tables or sections are used when there is a difference.

The examples use "<kernel version>" when you need to refer to a specific Linux kernel version. Substitute "uclinux-2.0", "uclinux-2.4", "linux-2.4", or "linux-2.6" as appropriate. In this document, when we refer to Linux, we will mean this to apply to all versions uClinux and Linux unless otherwise stated.

1.3 Components of the Cadenux ARM BSP

The Cadenux ARM BSP includes the Cadenux ARM BSP compact disk (CD-ROM). The CD-ROM contains the tools listed below to help developers get a jump-start on developing applications.

• GNU ARM7 or ARM9® tool chain

• rrload bootloader

• Cadenux uClinux or Linux kernel for the target processor

• File system for the target hardware with basic system utilities

1.4 System Requirements

Listed below are the minimum requirements for installing and using the Cadenux ARM BSP:

• A host computer with an Intel® Pentium® family processor

• 750 MB free hard disk space

• Red Hat® Linux 7.x, 8.0, or 9.0 (complete install) configured on the host computer

• A network card installed and configured on the host computer

• An EVM with power supply

• Serial cable (male-to-female, 9-pin, straight through, or female-to-female, 9-pin, NULL modem cross over, depending on EVM)

1.5 Root Password Entry

During the course of installing the BSP and building the file system, you will be asked for the root password several times. Root privileges are necessary at certain points in the configuration of the target file system image (creation of devices, setting of file ownership, etc.). The Cadenux build process provides an alternative to reduce the number of times you have to enter passwords. If you define the following environment variable in your shell startup script (e.g. .bashrc):

export SU=sudo

Then you will be asked for a password only once and the password that you provide is your personal password, not the root password.

In order for the sudo command to work correctly, you must have an entry for your user ID in /etc/sudoers. You need to edit this file as the root user. Also, you can add a default timestamp entry to disable sudo from periodically asking for your user password. The following two lines can be added to the /etc/sudoers file to reduce the number of times you have to enter passwords.

Defaults:<user ID>  timestamp_timeout=-1
<user ID>     ALL=(ALL) ALL

The relevant portion of the /etc/sudoers I use is:

# Defaults specification
Defaults:tfischer  timestamp_timeout=-1

# User privilege specification
root            ALL=(ALL) ALL
tfischer        ALL=(ALL) ALL

More information about sudo can be found at http://www.courtesan.com/sudo/.

1.6 Installing the Cadenux ARM BSP Software

Follow the steps below when installing Linux and the Cadenux ARM BSP installation software.

1. Install Linux on the host computer

   Install and configure Red Hat Linux on your host computer. When choosing the type of installation, select CUSTOM, then scroll to the bottom of the package list and check the box marked EVERYTHING. Cadenux engineers develop and test using Red Hat Linux 7.3 and 9.0. Any recent distribution of Red Hat Linux should work, but may require minor adjustments.

   You can download or purchase Red Hat Linux from http://www.redhat.com.

   Note: Before proceeding, ensure that you can perform the following tasks on your host computer: i) Boot into Linux. ii) Launch the graphical user interface. iii) Bring up a terminal window. iv) Login as a normal user (not "root")

2. Install the Cadenux ARM BSP on the host computer

   You can install the Cadenux ARM BSP from the CD-ROM or you can download an ISO9660 image from the Cadenux website. If you are working with the ISO9660 image, you need to mount it as follows, adjusting paths and filenames as necessary.

   $ mkdir /tmp/bspmnt
   $ su
   # mount -o ro,loop /tmp/cadenux-<target processor>-<kernel version>-bsp.iso /tmp/bspmnt
   # exit

   After completing the mount command, the installation process is the same whether you have a CD-ROM or a downloaded ISO9660 image.

   1. Go to the installation directory.

      $ cd /tmp/bspmnt

      - or -

      $cd /mnt/cdrom

   2. Run the installation script. Be prepared to enter the root password.

      $./INSTALL <development directory>

1.7 Important Directories

After installing the Cadenux board support package, two directory trees are stored in the Linux workstation file system. One directory tree,

/opt/Cadenux/<target processor>/<kernel version>/crossdev

contains the cross development tool chain. The other directory,

<development directory> 

is the directory you specified when running the INSTALL script. It contains the boot loader, uClinux or Linux kernel, target hardware file system image and examples.

The following two tables describe the main BSP directories:

1.8 Uninstalling the Software

To remove a previously installed version of the Cadenux ARM BSP software (all files in /opt/Cadenux/), perform the actions below as root.

CAUTION: Before removing the tree, be sure to backup any files you want to keep.

$ su -c 'rpm -e <package-name>'
$ rm -rf /opt/Cadenux/<target processor>/<kernel version>

To remove the Cadenux source code, objects, documentation, and makefiles; simply remove the <development directory> tree, using the following command.

$ rm -rf <development directory>

2 Using the Target Hardware

2.1 Turning on the EVM

Follow the steps below to start Linux on the EVM.

1. Observe proper static discharge precautions.

2. Make sure that the EVM is turned off.

3. Configure the EVM jumpers. Refer to the documentation that came with the EVM and also see Jumpers.

4. Connect the serial port to your host using a serial cable appropriate for your EVM. Depending on your EVM, you will need either a male-to-female, 9-pin, straight through serial cable or a female-to-female, 9-pin, NULL modem cross over serial cable.

5. Launch minicom or an equivalent serial port terminal program on the host using the following settings:

   115200 baud, no parity, 1 stop bit, 8 data bits (8N1)

   If you have problems getting minicom to work properly, consult Common minicom Problems.

   NOTE: When downloading files to the rrload bootloader, using HyperTerm or TeraTerm will often result in a bad file transfer.

6. The following steps assume that the rrload bootloader has already been programmed into flash. If this is not the case, refer to the instructions on loading rrload the first time.

7. Apply power to the EVM. If the board does not boot (no messages sent out over the serial port), press RESET to start the board.

8. The Linux kernel will send a welcome message to the terminal display.

9. To log into the EVM, enter the user name "root" and press ENTER.

The EVM is now ready for use.

2.2 Building the Cadenux BSP Components

Cadenux BSP Environment Variables. Before you can do any BSP development, you must first set some environment variables. The script setenv sets the environment variables used. To invoke setenv, do the following:

$ cd <development directory>
$ source setenv

The setenv sets the variables CADENUX_BSP, CADENUX_ARCH, and CADENUX_KERNEL. It also adds the directory to the cross development tools to PATH. You only need to execute setenv once in a terminal window. The examples below include executing setenv, but you can leave out that step if the environment variables are already set.

Cadenux BSP Components. The software downloaded to the target hardware is comprised of various components, listed below:

• Bootloader (rrload)

• Bootloader parameters

• Linux kernel (uClinux 2.0.xx or 2.4.xx or Linux 2.4.xx or Linux 2.6.xx)

• Target file system

The target file system itself consists of various components:

• Linux file system framework including uClibc libraries

• Development applications (Busybox, tinylogin, etc)

• Loadable kernel modules

• Applications

Building All of the Components. All of the Cadenux BSP components (except the examples) can be built using the following commands:

$ cd <development directory>
$ source setenv
$ make

Building All Examples. All of the examples can be built using the following commands:

$ cd <development directory>/examples
$ make all install

The above steps place the executable version of the programs in the target filesystem under the /examples directory.

Building Selected Applications. Or you can use the following commands to build individual applications:

1. To re-build a particular application (in this case, the "Hello, World" example):

   $ cd <development directory>
   $ cd  <development directory>/fs/examples/hello
   $ make all install

2. To get the newly built applications on the target hardware, it is necessary to rebuild the target file system:

   $ cd  <development directory>
   $ make fs

3. If you change the kernel configuration (see Changing the Kernel Configuration) or if you modify a kernel component (such as a built-in device driver), then it will be necessary to re-build the kernel:

   ARM7:

   $ cd <development directory>
   $ make linux

   ARM9:

   $ cd <development directory>
   $ make vmlinux

4. To re-build the rrload bootloader:

   $ cd <development directory>
   $ make rrload

2.3 Changing the BSP Configuration

Cadenux has added a configuration utility that allows settings that apply to more than one component (like rrload, the kernel, and/or applications in the file system) to be changed in one place and the change is distributed to all effected components.

See the Cadenux ARM BSP Configuration Tool manual for details.

2.4 Changing the Kernel Configuration

Configuration Files. The Linux kernel supplied with your BSP is pre-configured and ready for use. If your project requires components that are not contained in the default Cadenux kernel, you may want to change the kernel configuration. The kernel configuration is expressed in two files: (1) the .config working copy and (2) config master backup copy. The working copy is retained at <development directory>/linux/.config; the master backup copy at <development directory>/build/config.<target processor>.

The configuration file is read and modified by xconfig, described below. After running xconfig, another derived file, <development directory>/linux/include/linux/autoconf.h is created. The autoconf.h file is included by most kernel source files to control which features are built.

Changing the Working Configuration. Changing the Cadenux kernel configuration requires changing the .config working copy. It should not be modified directly, but rather it should modified it using the steps below. In this procedure, we use make xconfig to modify .config.

1. Type the commands below to initiate xconfig:

   $ cd <development directory>/linux
   $ make xconfig

2. xconfig will display all of the kernel options and their current settings. xconfig will allow you to change any kernel setting. Be sure to save your changes before you exit from xconfig.

3. With the xconfig session complete, you can build the new Cadenux kernel as follows:

   ARM7:

   $ cd <development directory>/linux
   $ . ../setenv
   $ make clean dep
   $ cd ..
   $ make linux

   ARM9:

   $ cd <development directory>/linux
   $ . ../setenv
   $ make clean dep
   $ cd ..
   $ make vmlinux

   The make clean dep step is always required when making changes to the Linux configuration. However, it is not necessary with each subsequent rebuild which might occur as part of an iterative I/O driver development process, for example.

   The resulting kernel image can be found in two files. The names of these files differ for the ARM7 and ARM9 BSPs:

   ARM7:

   • <development directory>/linux/linux. An ELF object format for use with JTAG based target debug tools.

   • <development directory>/linux/linux.rr An rrbin format for use when downloading to the target hardware using the rrload bootloader.

   ARM9:

   • <development directory>/linux/vmlinux. An ELF object format for use with JTAG based target debug tools.

   • <development directory>/linux/vmlinux.rr An rrbin format for use when downloading to the target hardware using the rrload bootloader.

Resetting the Kernel to the Default Configuration Should you want to return to the Cadenux-supplied default settings, you can accomplish this with the steps below.

ARM7:

$ cd <development directory>/linux
$ . ../setenv
$ make clean
$ cp ../build/config.<target processor> .config
$ cp ../build/autoconf.h.<target processor> include/linux/autoconf.h
$ make dep
$ cd ..
$ make linux

ARM9:

$ cd <development directory>/linux
$ . ../setenv
$ make clean
$ cp ../build/config.<target processor> .config
$ cp ../build/autoconf.h.<target processor> include/linux/autoconf.h
$ make dep
$ cd ..
$ make vmlinux

Customizing the Kernel Configuration. If you find that your particular needs cannot be met using the available kernel configuration options, you may want to modify the 'make xconfig' scripts that control the configuration session. The particular file that controls the xconfig program presented above is at:

<development directory>/linux/arch/armnommu/config.in

2.5 Changing the Target File System

The directory structure under <development directory>/fs/fs/ is the master file system structure used to create the target file system. Files can be installed into the target file system by simply copying them into the appropriate sub-directories under <development directory>/fs/fs/. The target file system is built by default as a "romfs" file system.

Adding Content to the Target File System. You can configure the target file system with additional content not included in the BSP's default target file system. The following steps illustrate two methods that can be used to put new applications into the target file system. In these illustrations, the application is the "Hello, World" example.

1. The following steps compile and install the "Hello, World" example into the target file system image on the Linux development workstation.

   $ cd <development directory>/fs/examples/hello
   $ . ../../../setenv
   $ make all install

   If you examine the "Hello, World" Makefile at <development directory>/fs/examples/hello, you will see that the executable is installed in a directory defined by EXAMPLES_DIRECTORY. This variable has the value: <development directory>/fs/fs/examples.

   The "Hello, World" example could also have been built and installed as follows:

   $ cd <development directory>/fs/examples/hello
   $ . ../../../setenv
   $ make
   $ mkdir -p ../../fs/examples
   $ cp -f hello ../../fs/examples/

2. Then the "romfs" image of the target file system must be re-built. The rebuilt file system image will contain the "Hello, World" example.

   $ cd <development directory>
   $ source setenv
   $ make fs

   The make fs command creates the romfs image as "<development directory>/linux/ romdisk.rr." This romfs image can be downloaded to the target hardware using the rrload bootloader.

2.6 Putting the New System on the Target Hardware

Putting the New System on the Target Hardware. Once you have created a new BSP component (a new kernel image, a new file system image, or both), the rrload bootloader can be used to download the component into the target hardware's RAM, to save the component in flash memory, and/or to boot the new system. The steps below describe the general procedure to accomplish this. See the rrload documentation for more detailed instructions.

1. Power cycle the target hardware while holding down the ENTER key in the minicom terminal window for a few seconds. This intercepts the normal boot process and ensures that the target hardware board's bootloader user interface (UI) is presented to the user over the serial port.

2. From the bootloader's main menu, select OPTION 3 to display the rrload persistent parameters menu. Verify that the settings are appropriate for the operation(s) that you will perform and make any necessary changes.

3. Use the rrload UI to download the new kernel and/or file system.

   NOTE: If you are using a serial connection, the UI will wait for the data after you specify the kernel or file system. With another terminal window in the development directory, use a cat shunt, like: $ cat fs.img.rr > /dev/ttyS0 and it will begin loading.

4. Erase the on-board kernel and/or file system (optional). If you have a system with which you want to replace the currently flashed system, use the optional rrload UI to ERASE the original flashed kernel and/ or file system.

5. Store the on-board kernel and/or file system (optional). To store the new kernel and or file system into flash, use the rrload UI Store command.

6. Issue the boot_auto command. This command is more elaborate than the simple boot command and ensures that both a file system and kernel exist in RAM prior to transferring control to the kernel.

2.7 Writable File Systems

ramdisk File System. The default file system used in the Cadenux BSP is romfs, which is mounted by the Linux kernel as a read-only file system. The Linux kernel system startup scripts also mounts a writable RAM disk file system. The RAM disk is mounted at /mnt/ramdisk. The directories /root, /tmp, and /var are symbolic links into /mnt/ramdisk. These directories are writable, however, anything written to the ramdisk will be lost when the target hardware is powered down.

NFS Mounted Root File System. Another option is to use an NFS mounted file system as discussed below. If the target file system is mounted via NFS, then applications can write and/or modify the file system, which is visible after the next power cycle. In this scenario, the target file system is not hosted in the target hardware but rather on a hard drive of a remote Ethernet connected machine, typically your Linux development workstation.

Writing to On-Board Flash. Some Linux applications will require the ability to store data persistently in flash. Such applications will require extensions to the target hardware to allow hosting of a read/write flash file system. These extensions will include:

• Provision of a writable flash file system that the kernel can mount on boot-up. A writable flash file system are available in the uClinux 2.0.xx package including (JFFS); Additional flash file systems are available under the 2.4.xx and 2.4.xx kernels (JFFS, JFFS2, etc). These flash file systems are well documented and discussed in the Linux Open Source embedded systems community.

• Kernel configuration changes (for example, via make xconfig) to enable the particular file system type used, and

• Addition of an underlying flash media access layer/driver to support the board's flash chip(s).

3 Using the GDB Debugger

There are two common tools used for symbolic debugging software used in Linux based target hardware. The GDB debugger is typically used to debug applications. A JTAG emulator is typically used to debug the Linux kernel and kernel device drivers. Debugging using a JTAG emulator is dependent on the emulator used, and thus is not discussed in this manual.

3.1 The ARM GDB Debugger

GDB Debugger. The purpose of a debugger is to allow the developer to see what is going on inside his/her program while it executes. The debugger provided in the Cadenux BSP is /opt/<development directory>/<kernel version>/crossdev/bin/arm-uclinux-gdb. Use of that debugger is the topic of this section. For detailed information regarding usage of the GDB debugger, please refer to one of the following:

• The standard gdb man pages.

• The info pages included on your Linux workstation.

• The online manual provided by the Free Software Foundation at http://www.gnu.org/software/gdb/documentation.

ARM GDB Debuggers. The ARM7 and ARM9 BSPs use slightly different versions of the GDB debugger. The ARM7 GDB debugger has special modifications to work with the MMU-less ARM. That debugger is called:

arm-uclinux-gdb.

The ARM9 GDB bugger is a standard GNU released and is named:

arm-linux-gdb.

In the following discussion, arm-linux-gdb will refer to both debuggers except where differences in usage are noted.

gdbserver. The arm-linux-gdb debugger executes on the user's Linux workstation. In order to communicate with a program running on the target hardware, an additional program must run on the target hardware. This program is gdbserver. It is included with the Cadenux toolchain and is installed in the target file system as /usr/bin/gdbserver.

gdbserver Communications. There are two methods for communication between the target hardware's gdbserver and the Linux workstation GDB client. One method uses an available serial port while the other uses the Ethernet port.

Some target hardware have multiple serial connectors with one of them dedicated to the system console (typically /dev/ttyS0) and another (/dev/ttyS1) is available for GDB communication with the Linux workstation. In the case where the target hardware has only one serial port, it is probably not available for GDB debugging. In this case, the Ethernet port should be used for GDB communication with the Linux workstation.

If you are going to use the serial port for debugging, see the 6.4 Changing Serial Port Settings section for additional information about the use and configuration of the board's serial port. Use the connection that is appropriate for your target hardware, specifying it at the time you start the debug session.

Graphical Front-Ends. If you would like to use a graphical front end with arm-linux-gdb, there are several compatible front ends available. One popular front end is the ddd utility (http://www.gnu.org/software/ddd). Below is how you would invoke the ARM9 arm-linux-gdb debugger, using the ddd graphical front end:

$ ddd --debugger arm-linux-gdb

Invoking the ARM7 arm-uclinux-gdb debugger, using the ddd graphical front end is similar:

$ ddd --debugger arm-uclinux-gdb

Debug-able Files. You can use the arm-linux-gdb or arm_uclinux-gdb debugger (with the gdbserver) to debug Linux programs on the target hardware. You can use any program invoked from the Linux command line with this debugger, provided that the program was built to be compatible with GDB.

hello Example. There is a <development directory>/fs/examples/hello program included in the BSP installation that shows a Makefile containing details necessary to prepare an application for debugging. The following paragraphs will walk through the steps to prepare and debug this hello program for the ARM7 and for the ARM9 BSPs.

3.2 Using the ARM7 GDB Debugger

ARM7 Executable File Formats. ARM7 executable programs can be built in three binary formats. On the target hardware side, the binary files can be either in the:

• The "flat" binary format file, or

• The "xflat" binary format file.

The "flat" binary format file is a traditional form for uClinux executables. The "xflat" binary format file is an extension to the traditional "flat" format that adds support for shared libraries. The <development directory>/fs/examples/hello example builds an "xflat" binary. On the Linux workstation side, the binary files must be in the:

• The debug "ELF" format file.

Workstation Debug Files. Of course, the debug "ELF" file is never actually executed on the Linux workstation, rather it is provided to arm-uclinux-gdb to supply the debugger with sufficient information to allow symbolic debugging of the program on the target hardware, which is actually executed in either "flat" or "xflat" binary format file.

Preparing the Debug ELF File. The "Hello, World" example at <development directory>/fs/examples/hello normally generates only an "xflat" program, hello. The "Hello, World" Makefile will also generate a debug "ELF" file called hello.debug if it is invoked in the following manner:

cd <development directory>/fs/examples/hello
make clean
make debug
make install

The effect of make debug is to (1) compile the sources including debug information and disabling optimizations, and (2) to provide the option -g to the "xflat" linker, xflat-ld. This tool is discussed with the xflat documentation at <development directory>/toolchain/xflat/Documentation.

Be sure to place the debuggable version of your program into the target file system before attempting to debug it. You may do this by either:

• Building a new file system that you can download via rrload as described above,

• Building a new file system that the target hardware then either mounts via NFS as discussed below,

  or

• Using FTP from the Linux workstation to "put" your program onto the mounted ramdisk file system of the Ethernet connected target hardware (see Writable File Systems above), or

If you have loaded the program into ramdisk via FTP, verify that the file permissions are set to grant execute privileges. If not, you can make the file executable using: chmod +x <file>.

Debugging the program: Once you have placed your executable program in the target hardware's file system, it is ready for debugging using the following steps. On the Linux workstation, you will need the .debug ELF version of your program in the same directory where you will invoke arm-uclinux-gdb.

1. Start the gdbserver. On the target hardware, invoke the gdbserver in the directory where you have the file you are debugging: the "flat" or "xflat" format version of your program. To start the target hardware-side of the GDB session, do one of the following:

   • If you are using a network GDB connection, enter the command below:

     # cd <development directory>/examples
     # gdbserver :5472 hello

     The port number 5472 was selected randomly as a high port number. Any high port number that doesn't conflict with existing active ports will work. The command line also indicates the name of the program you intend to debug, hello in this example. This program is the "xflat" binary Linux program format intended to run on the target hardware.

   • If using a serial GDB connection, enter the commands below. See the 6.4 Changing Serial Port Settings section for instructions on building the stty command into busybox.

     # stty -F /dev/ttyS1 -iexten -echoctl 115200
     # gdbserver /dev/ttyS1 hello

   Example: In either case, gdbserver will respond with something like the following example:

   # cd <development directory>/examples
   # /usr/bin/gdbserver :5472 hello
   Process hello created; pid = 26
   ...
   Program load address = 0x109e5ed0
   ...

   Other useful debug information may be reported between the "Process hello created..." line and the "Program load address..." line. However, it is only the final "Program load address," in this example 0x109e5ed0, that is needed by arm-uclinux-gdb.

2. Connect arm-uclinux-gdb. Start the Linux workstation-side of the GDB session by invoking the arm-uclinux-gdb debugger. This establishes a connection to the GDB server previously started on the target hardware. We invoke arm-uclinux-gdb while in the directory containing the .debug version of our program file, hello.debug. Then issue commands at the GDB command line prompt to establish the connection and load the program's debug symbols.

   • If you are using the "ddd" graphical front end, invoke it using the following command.

     $ ddd --debugger /opt/<target processor>/<kernel version>/crossdev/bin/arm-uclinux-gdb

   • If using a network GDB connection, enter the commands below.

     $ cd <development directory>/fs/examples/hello
     $ arm-uclinux-gdb
     (gdb) set endian little
     (gdb) target remote x.x.x.x:5472
     (gdb) add-symbol-file hello.debug PC-address

     Where:

     • The PC-address is the address reported by the gdbserver that was previously executed on the target hardware.

     • The string x.x.x.x is replaced with the actual IP address of the target hardware. (If you are not sure what the IP is, type "ifconfig" on the target hardware command line to generate a network configuration report).

     • The port 5472 was selected randomly as a high port number. It must match the port number that was provided on the preceding target hardware gdbserver command.

   • If using a serial connection to the gdbserver, enter the commands below.

     $ cd <development directory>/fs/examples/hello
     $ arm-uclinux-gdb
     (gdb) set endian little
     (gdb) set remotebaud 115200
     (gdb) target remote /dev/ttyS1
     (gdb) add-symbol-file hello.debug PC-address

     Where:

     • The PC-address is the address reported by the gdbserver that was previously executed on the target hardware.

     By default, most Linux workstation's serial ports start up at 9600 baud. On the target hardware /dev/ttyS1 starts up at 9600 baud. See the 6.4 Changing Serial Port Settings section for instructions on building the stty command into busybox which will allow you to change the baud rate on /dev/ttyS1.

Example: Continuing with the example from the above, the following dialog might be seen when the arm-uclinux-gdb is connected to the gdbserver:

[gnutt@SpudKayak dsc25]$ cd fs/examples/hello
[gnutt@SpudKayak hello]$ arm-uclinux-gdb
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-linux --target=arm-elf".
(gdb) set endian little
(gdb) target remote 15.2.200.99:5471      
Remote debugging using 15.2.200.99:5471
0x10967390 in ?? ()
(gdb) add-symbol-file hello.debug 0x109e5ed0
add symbol table from file "hello.debug" at text_addr = 0x109e5ed0?
(y or n) y
Reading symbols from hello.debug...done.
(gdb) b main
Breakpoint 1 at 0x109e5eec: file hello.c, line 39.
(gdb) cont
Continuing.

Breakpoint 1, main (argc=276705864, argv=0x0, envp=0x0) at hello.c:39
39        printf("Hello, world!\n");
(gdb) 

3.3 Using the ARM9 GDB Debugger

ARM9 Executable File Formats. For the ARM9 BSPs, all executable formats are "ELF." However it is necessary to build a debug-able version of the "ELF" file for use by the arm-linux-gdb debugger on your workstation.

Workstation Debug Files. Of course, the debug-able "ELF" file is never actually executed on the Linux workstation, rather it is provided to arm-linux-gdb to supply the debugger with sufficient information to allow symbolic debugging of the same "ELF" program on the target hardware.

Preparing the Debug ELF File. The "Hello, World" example at <development directory>/fs/examples/hello normally generates a non-debug-able, optimized "ELF" program, hello. The "Hello, World" Makefile will instead generate a debug-able "ELF" program if it is invoked in the following manner:

cd <development directory>/fs/examples/hello
make clean
make debug
make install

The effect of make debug is to compile the sources including debug information and disabling optimizations.

Be sure to place the debuggable version of your program into the target file system before attempting to debug it. You may do this by either:

• Building a new file system that you can download via rrload as described above,

• Building a new file system that the target hardware then either mounts via NFS as discussed below,

  or

• Using FTP from the Linux workstation to "put" your program onto the mounted ramdisk file system of the Ethernet connected target hardware (see Writable File Systems above), or

If you have loaded the program into ramdisk via FTP, verify that the file permissions are set to grant execute privileges. If not, you can make the file executable using: chmod +x <file>.

Debugging the program: Once you have placed your executable "ELF" program in the target hardware's file system, it is ready for debugging using the following steps. On the Linux workstation, you will need the same, debug-able "ELF" version of the program in the same directory where you will invoke arm-linux-gdb.

1. Start the gdbserver. On the target hardware, invoke the gdbserver in the directory where you have the file you are debugging: the "flat" or "xflat" format version of your program. To start the target hardware-side of the GDB session, do one of the following:

   • If you are using a network GDB connection, enter the command below:

     # cd <development directory>/examples
     # gdbserver :5472 hello

     The port number 5472 was selected randomly as a high port number. Any high port number that doesn't conflict with existing active ports will work. The command line also indicates the name of the program you intend to debug, hello in this example. This program is the debug-able "ELF" program that we built and installed above.

   • If using a serial GDB connection, enter the commands below. See the 6.4 Changing Serial Port Settings section for instructions on building the stty command into busybox.

     # stty -F /dev/ttyS1 -iexten -echoctl 115200
     # gdbserver /dev/ttyS1 hello

   Example: In either case, gdbserver will respond with something like the following example:

   # cd <development directory>/examples
   # /usr/bin/gdbserver :5472 hello
   Process hello created; pid = 26

2. Connect arm-linux-gdb. Start the Linux workstation-side of the GDB session by invoking the arm-linux-gdb debugger. This establishes a connection to the GDB server previously started on the target hardware. We invoke arm-linux-gdb while in the directory containing the debug-able version of our "ELF" program file, hello. Then issue commands at the GDB command line prompt to establish the connection and load the program's debug symbols.

   • If you are using the "ddd" graphical front end, invoke it using the following command.

     $ ddd --debugger /opt/<target processor>/<kernel version>/crossdev/bin/arm-linux-gdb

   • If using a network GDB connection, enter the commands below.

     $ cd <development directory>/fs/examples/hello
     $ arm-linux-gdb
     (gdb) set endian little
     (gdb) target remote x.x.x.x:5472
     (gdb) add-symbol-file hello

     Where:

     • The string x.x.x.x is replaced with the actual IP address of the target hardware. (If you are not sure what the IP is, type "ifconfig" on the target hardware command line to generate a network configuration report).

     • The port 5472 was selected randomly as a high port number. It must match the port number that was provided on the preceding target hardware gdbserver command.

   • If using a serial connection to the gdbserver, enter the commands below.

     $ cd <development directory>/fs/examples/hello
     $ arm-linux-gdb
     (gdb) set endian little
     (gdb) set remotebaud 115200
     (gdb) target remote /dev/ttyS1
     (gdb) add-symbol-file hello

     By default, most Linux workstation's serial ports start up at 9600 baud. On the target hardware /dev/ttyS1 starts up at 9600 baud. See the 6.4 Changing Serial Port Settings section for instructions on building the stty command into busybox which will allow you to change the baud rate on /dev/ttyS1.

3.4 Using the gdbinit

Using ~/.gdbinit. The arm-linux-gdb and arm-uclinux-gdb debuggers will read an optional ~/.gdbinit when they are started. For either gdbserver network or serial connection, the corresponding set of GDB commands can be defined as a macro within your ~/.gdbinit to simplify these steps. Consider the following sample ~/.gdbinit:

define target_remote
  set endian little
  target remote x.x.x.x:5472
end

With this macro defined in your ~/.gdbinit file, GDB can be connected to the remote gdbserver with the single command:

(gdb) target_remote

4 Networking

4.1 Default Kernel Configuration with Networking Enabled

The Cadenux BSP ships with a default kernel configuration that has networking enabled. With the supplied default configuration, you will only need to use the Cadenux ARM BSP Configuration Tool to set networking values appropriate for your network. After connecting the target hardware to a LAN and booting the kernel, you should be able to use the network.

For example, commands like the ones given below should be immediately available to you.

# /sbin/ifconfig
# /sbin/route
# ping 111.222.333.444
# ...etc...

4.2 Mounting the Target File System

By default, Linux running on the target hardware will mount the file system from an image contained within memory (default Linux command line root=/dev/rom0). Use the Cadenux ARM7 BSP Configuration Tool to change the root file system.

The default kernel command line can be changed using the rrload bootloader. Recall that the target hardware bootloader lets you pass a custom kernel command line to the kernel as it boots. By default, no kernel command line is needed to mount /dev/rom0.

4.3 Optional NFS Root Mount

As an alternative to using the romdisk file system, the user may decide to set the system up for NFS mounting of the root file system. The idea here is that the user will have an image of the target hardware file system residing on a Linux workstation that is mounted (via NFS) directly by the target hardware on boot-up. This is typically done only while developing the system. NFS root mount is easier to make changes to the file system contents and test those changes since downloading the modified file system image to the target hardware is not necessary. There are two approaches to using an NFS mounted file system:

Before trying to boot into a NFS Root Filesystem EVM, first boot a normal romfs or initrd Filesystem EVM and test the network. Utilities such as ping and telnet should work before attempting Root NFS.

1. NFS. In this case, we must use the kernel command line to explicitly assign additional network parameters to the target hardware along with the network location of the target file system.

   1. Use make xconfig to turn on the following:

      uClinux 2.0 Kernel		Linux 2.4 Kernel, uClinux 2.4 kernel, or Linux 2.6 Kernel
      make xconfig Label	Parameter	make xconfig Label	Parameter
      		IP: kernel level autoconfiguration	CONFIG_IP_PNP=y
      		IP: RARP support	CONFIG_IP_PNP_RARP=y
      NFS filesystem support	CONFIG_NFS_FS=y	NFS file system support	CONFIG_NFS_FS=y
      Root file system on NFS	CONFIG_ROOT_NFS=y	Root file system on NFS	CONFIG_ROOT_NFS=y

   2. Rebuild the kernel.

      $ cd <development directory>/linux
      $ make clean dep
      $ cd ..
      $ make

   3. Store the newly built kernel in the target flash hardware as described above.

   4. Configure the Linux workstation to allow NFS mounting of the target hardware file system in the <development directory>. To allow the target device to mount the file system hosted on the Linux workstation, you must NFS export the directory.

      • Add lines like the following to the /etc/exports file:

        <development directory>/fs/fs 10.0.0.0/24(rw) *<domain>(rw)

        Such as:

              /home/jmj8/dm270/fs/fs 10.0.0.0/24(rw) *.cadenux.com(rw)

      • Inform the NFS daemon to reread the exports file.

        $ su -
        <enter root password>
        # exportfs -a
        # exit

   5. Configure the rrload bootloader to pass an NFS root mount command to Linux via the kernel command line.

      • Boot the target hardware into rrload and set the "kernel cmdline" (in View/Edit Params...) similar to the commands below. For the example given, 10.0.0.20 is the target hardware IP address, 10.0.0.3 is the NFS server IP address, 255.255.255.0 is the netmask, and evm is the target hardware DNS name.

        uClinux 2.0 Kernel

        root=/dev/nfs nfsroot=10.0.0.3:<development directory>/fs/fs nfsaddrs=10.0.0.20:10.0.0.3

        uClinux 2.4 Kernel, Linux 2.4 Kernel, or Linux 2.6 Kernel

        init=/fsstart root=/dev/nfs nfsroot=10.0.0.3:<development directory>/fs/fs rw ip=10.0.0.20:10.0.0.3::255.255.255.0:evm

      • If desired, save the rrload parameters to flash by first erasing the rrload parameters and then storing them.

2. NFS with BOOTP. In this case, BOOTP is used to acquire some network parameters that are setup by your system administrator. This approach has the advantage of keeping the kernel command line simple at the expense of requiring your system administrator to add a BOOTP entry in the network table that associates a specific IP address with the specific MAC of your target hardware. On boot, the target hardware sends out a network BOOTP broadcast asking for its IP address assignment.

   1. Use make xconfig to turn on the following kernel configuration options:

      uClinux 2.0 Kernel		uClinux 2.4 Kernel. Linux 2.4 Kernel, or Linux 2.6 Kernel
      make xconfig Label	Parameter	make xconfig Label	Parameter
      		IP: kernel level autoconfiguration	CONFIG_IP_PNP=y
      		IP: BOOTP support	CONFIG_IP_PNP_BOOTP=y
      		IP: RARP support	CONFIG_IP_PNP_RARP=y
      NFS filesystem support	CONFIG_NFS_FS=y	NFS file system support	CONFIG_NFS_FS=y
      Root file system on NFS	CONFIG_ROOT_NFS=y	Root file system on NFS	CONFIG_ROOT_NFS=y
      BOOTP support	CONFIG_RNFS_BOOTP=y
      RARP support	CONFIG_RNFS_RARP=y

      These options are all in the "File Systems" xconfig menu.

   2. Rebuild the kernel.

      $ cd <development directory>/linux
      $ make clean dep
      $ cd ..
      $ make

   3. Store the newly build kernel in the target flash hardware as described above.

   4. Configure the Linux workstation to allow target hardware to obtain an IP address using the BOOTP protocol.

      • Add lines similar to the following to the /etc/dhcpd.conf file.

        host evm {
           hardware ethernet 00:E0:81:10:36:DF;
           fixed-address 10.0.0.20;
        }

      • Restart the dhcpd daemon.

        $ su -
        <enter root password>
        # service dhcpd restart
        # exit

   5. Configure the Linux workstation to allow NFS mounting of the target hardware file system in the <development directory>. To allow the target device to mount the file system hosted on the Linux workstation, you must nfs export the directory.

      • Add lines similar to the following to the /etc/exports file.

        <development directory>/fs/fs 10.0.0.0/24(rw) *.cadenux.com(rw)

      • Inform the NFS daemon to reread the exports file.

        $ su -
        <enter root password>
        # exportfs -a
        # exit

   6. Configure the rrload bootloader to pass an NFS root mount command to Linux via the kernel command line.

      • Boot the target hardware into rrload and set the "kernel cmdline" (in View/Edit Params...) similar to the commands below. For the example given, 10.0.0.3 is the NFS server IP address.

        uClinux 2.0 Kernel	uClinux 2.4 Kernel, Linux 2.4 Kernel, or Linux 2.6 Kernel
        root=/dev/nfs nfsroot=10.0.0.3:<development directory>/fs/fs nfsaddrs=both	init=/fsstart root=/dev/nfs nfsroot=10.0.0.3:<development directory>/fs/fs rw ip=bootp

      • If desired, save the rrload parameters to flash by first erasing the rrload parameters and then storing them.

For more information regarding the meaning of the various command line parameters associated with NFS root mounting, please see linux/Documentation/nfsroot.txt.

After establishing a configuration that enables NFS root mounting, you need only:

• Build the linux kernel,

• Build the stock target file system (if you have not already), and then

• Download BOTH of them to the board.

If the network driver is a loadable module, then the downloaded file system is used as an intermediate step during the boot process to load the network driver. During the kernel boot, the file system in flash is mounted to gain access to the network driver. Once loaded, the system will proceed to un-mount the memory-based romfs and re-mount the root FS via NFS. The downloaded romfs needs to contain, as a minimum, /linuxrc and /etc/sysconfig/network.

If NFS root mount is enabled, the kernel boot process first initializes the networking code, then attempts the NFS mount according to the default kernel command line parameters contained in linux/arch/armnommu/kernel/setup.c unless the NFS parameters are overridden by values passed to the kernel via the rrload bootloader.

4.4 10BaseT versus 100BaseT

If the network on the target hardware supports both 10BaseT and 100T, rrload can be used to select the speed of operation. The C5471 EVM supports both networking speeds.

Change the rrload Makefile at <development directory>/rrload/Makefile as shown below and rebuild:

    Set NetRate=BaseT10

    - or -

    Set NetRate=BaseT100

5 Memory Map

5.1 Type of Memory Spaces

The memory addressable by the ARM processor can be divided into various memory spaces based on the use of the memory. The memory addressable by the C54 DSP is not discussed in this document. The memory spaces include:

• Hardware. The hardware memory map controls where other memory regions within the ARM addressable memory space are located.

• SDRAM. All executables and the associated data are stored in SDRAM (unless eXecute-In-Place (XIP) is being used).

• SRAM. The static RAM is not used by Linux or uClinux.

• Flash. The flash memory contains all executables and persistent data. The flash memory is controlled by the bootloader (rrload).

• IRAM. Internal RAM is used by uClinux 2.4.xx for interrupt vectors (c5471 only) and, possibly, for passing of parameters between rrload and the kernel. The uClinux 2.0.xx kernel will also use internal RAM used for the kernel's idle task stack. (Use of IRAM for the idle task stack is a necessary step to support some power management designs).

  The execution of uClinux was instrumented to determine critical routines and data. If CONFIG_DSCXX_USE_IRAM=y, those critical routines and data are stored in IRAM to increase overall uClinux performance. Use of IRAM for critical routines was only tested on the DSC21 processor and is only implemented in the uClinux-2.0.xx BSP.

5.2 Hardware Memory Map

The hardware memory map is controlled by the design of the System-On-a-Chip (SOC) being used and also by how the memory controller on the SOC is programmed.

5.3 Flash Memory Map

The flash memory map is controlled by the rrload bootloader as defined in the file rrload/memconfig.h which is dynamically created by the Cadenux ARM BSP Configuration Tool. The flash space is divided into four regions that hold the contents that the bootloader manages. These areas are:

1. Bootloader,

2. Bootloader parameters,

3. Kernel,

4. File system, and possibly

5. An optional second FLASH file system (as determined by the BSP configuration).

To determine where the components are stored in flash, use either the rrload 7. Print Memory Map option (requires that rrload flash debug be enabled using the Cadenux ARM BSP Configuration Tool), or look at the contents of the file rrload/memconfig.h.

5.4 System Memory Map

For the default system configuration, SDRAM holds the following items:

• RAM copy of the rrload bootloader,

• RAM copy of the Linux kernel image (assuming you are not using XIP),

• RAM copy of the romfs file system image (assuming romfs is being used and you are not using XIP), and

• the remainder of SDRAM that is available to the user at runtime.

The kernel and filesystem images are placed in SDRAM by the rrload, either when the images were downloaded from the Linux workstation or when the images were copied from flash memory where they were previously stored. rrload performs the copy of the kernel and/or file system when they are not configured for XIP.

The location and order of the kernel and the file system stored in flash are independent of the location and order where they are placed in SDRAM. The bootloader manages this by keeping the original load/size information with each image so that it can always be copied back to the same SDRAM location that was being used at the time the component was originally downloaded and flashed. You can change the storage and load order using the Cadenux ARM BSP Configuration Tool.

The Linux kernel has hard-coded values defining where various resources used by the kernel are located. Use make xconfig to modify these hard-coded values. This sections describes the location of resources assuming the target hardware is running applications and the kernel in RAM. If the system is configured for eXecute-In-Place (XIP) a different memory map is used.

6 Serial Port

Serial Devices. In this section we discuss the serial port and the two linux devices listed below.

• /dev/ttyS0

• /dev/ttyS1

• /dev/console

Default Serial Driver Configuration. The Cadenux BSP ships with a default kernel configuration that has the appropriate serial driver enabled, as shown in the table below:

6.1 Program Access to /dev/ttyS0

With serial port support enabled you can use the /dev/ttyS0 Linux device to programmaticly send and receive characters over the serial port. For reference, the make xconfig setting has the effect of enabling the CONFIG_<TARGET PROCESSOR>_SERIAL definition used during the build of the kernel. If you hardware supports /dev/ttyS1, this will enable the second serial port as well.

6.2 System Console

Default Console. The /dev/console is the device underlying system's stdin, stdout, and stderr file descriptors. In the Cadenux BSP, the kernel first tries to open /dev/console when it boots to serve as the console. Failing that, it will try to open /dev/ttyS0.

Login via the Serial Port. If you attach a terminal or a computer running terminal emulation software to the target hardware's serial port, then you can login to the target hardware via the serial port.

Standard IO. Once logged in over the serial port, the system console is automatically mapped to the /dev/ttyS0 device. This means that normal printf() statements in a program will route out the serial port. Or put generically, any reference to the system's stdin, stdout, and stderr device descriptors will map to the /dev/ttyS0, and therefore the serial port.

Restrictions. Because /dev/ttyS0 is the default console, applications should NOT use it for other purposes. In cases where the board has a second serial port, applications can instead use /dev/ttyS1.

6.3 Serial Settings

Default Baud Rate. By default, the target hardware /dev/ttyS0 serial port starts up at 115200 baud and /dev/ttyS1 serial port, if available, starts up at 9600 baud (most Linux workstation's start up at 9600 baud). The /dev/ttyS0 baud rate value of 115200 was chosen to be compatible with the rrload target hardware bootloader, which uses 115200 to maximize serial download speeds. A single terminal session (such as minicom) can communicate with the bootloader and then with the booted kernel without changing any settings. Applications that use a different baud rate can use the standard stty utility or ioctl() calls on /dev/ttyS0 or /dev/ttyS1, as appropriate, for changing serial port speed at runtime.

The default /dev/ttyS0 settings are:

• 115200 baud

• 8 data bits

• no parity

• 1 stop bit

The default /dev/ttyS1 settings are:

• 9600 baud

• 8 data bits

• no parity

• 1 stop bit

6.4 Changing Serial Port Settings

stty. busybox supports the stty program for changing serial port settings. However, by default stty is not enabled when busybox is built. To build stty into busybox, follow these instructions:

$ cd <development directory>/fs/userland/busybox
$ mv Config.h Config.h.orig
$ sed -e 's-//#define BB_STTY-#define BB_STTY-' < Config.h.orig > Config.h
$ make clean
$ cd <development directory>
$ make fs

Once you have built stty into busybox, you can set change the baud rate using the following:

# stty -F /dev/ttyS1 -iexten -echoctl 115200

6.5 Kernel printk() over Serial

Default Configuration. In the make xconfig, you will encounter the option "kernel printks on serial port." This feature is enabled by default. This is what allows the internal kernel messages to appear over the serial line and therefore on your remote connected terminal session (such as minicom). Recall that printk() is NOT the same as printf():

• printk() is only performed within the kernel itself for various diagnostics and OS warning messages.

• printf() is used by applications in user space for general console output.

The setting we use here only applies to the kernel printk() messages. For reference, this setting has the effect of enabling the CONFIG_SERIAL_CADENUX_CONSOLE definition used during the build of the kernel.

APPENDIX A Links to Related Web Sites

Refer to the URLs below for additional information relevant to the Cadenux ARM7 and ARM9 BSPs.

Linux Documentation. For Linux documentation, including Guides and FAQs, go to: http://www.linuxdoc.org.

Linux Newbie.org. For helpful guides to new Linux users (newbies), go to: http://www.linuxnewbie.org.

Linux Kernel. For new versions of the Linux kernel and the Linux kernel archives, go to: http://www.kernel.org.

Memory Technology Device (MTD). For details on the development of the MTD Linux subsystem for memory devices, especially Flash devices, go to: http://www.linux-mtd.infradead.org.

uClinux. For information on uClinux which is a derivative of the Linux 2.0 kernel intended for micro controllers without Memory Management Units (MMUs), go to:http://www.uclinux.org.

uClibc. For information on uClibc which is version of the C libraries included with the Cadenux BSP, go to:http://www.uclibc.org.

APPENDIX B Glossary

ARM Ltd

ARM Ltd is the developer of the ARM embedded RISC microprocessor family.

ARP

Address resolution protocol.

Board Support Package

Tools, drivers, Linux kernel, and documentation necessary to support development on a particular board.

Bootloader

RidgeRun's code used to load code to flash and set boot options. See "rrload."

BOOTP

Network protocol allowing a network device to obtain an IP address and other information from a server.

bpp

Bits per pixel.

BSP

See "Board support package."

Busybox

Open-source code that combines tiny versions of common utilities and a shell into a single small executable.

CLUT

Color look-up table

Cross-build

The process of running a toolchain on your host computer to produce executables for a different target file system, also known as "cross-compile." For example, you may cross-build on the host to produce files for the real target hardware.

Daemon

A process that typically runs in the background, behind the scenes, that is usually invoked as part of the system startup scripts. These processes usually run continuously as helper utilities for various system operations such as networking.

DHCP

Dynamic Host Configuration Protocol server.

Digital Signal Processor

A microprocessor specialized to process data in real-time. Certain operations can be executed in parallel, which results in higher processing capacity for a given clock speed.

DSP

See "Digital Signal Processor."

ELF

ELF (Executable and Linking Format) is a binary format originally developed by USL (UNIX System Laboratories). Because of its increased flexibility over the older a.out format that Linux previously used, the GCC and C library developers decided to move to using ELF as the Linux standard binary format also.

Evaluation Module

The evaluation module (EVM) is the TI circuit board containing the DSC25 chip.

EVM

See "Evaluation module."

File system

The directory structure (beginning with "/") comprising configuration files, applications, libraries, and an operating system.

GDB

Gnu Debugger. Allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.

GIO

General purpose Input / Output hardware lines.

General Purpose Processor

A microprocessor that is not specialized for real-time parallel processing of data.

GNOME

See "GNU Networked Object Model Environment."

GNU Networked Object Module Environment

A user-friendly set of applications and desktop tools used in conjunction with a window manager for the X Window System. GNOME is similar in purpose and scope to CDE and KDE, but GNOME is based completely on Open Source software.

GPP

See "General purpose processor."

GUI

Graphical user interface.

Host Computer

The Linux-based desktop system used for software development.

Host Linux

Refers to the Linux operating system running on the host computer. See also "User-mode Linux."

Host Shell

The Linux terminal shell running on the host computer. The default prompt shell is "$" for normal users and "#" for root.

IP

Internet Protocol.

JFFS

The Journaling Flash File System, developed by Axis Communications in Sweden, is aimed at providing a crash/power-down-safe file system for diskless embedded devices. It is released under the GPL, and the current version works for the Linux 2.0 kernel series and memory-mapped industry-standard flash-memories (aka "NOR-flashes").

JFFS2

A Journaling Flash File System based on the original JFFS and developed by Red Hat. JFFS2 offers improved performance, compression, RAM footprint, concurrency and support for suspending flash erases, and the support for hard links.

JTAG

Joint Test Action Group, specifies test framework for electronic logic components; IEEE Standard 1149.1, also known as IEEE 1149.1 (JTAG) or Boundary Scan.

KDE

See "K Desktop Environment."

K Desktop Environment

A powerful Open Source graphical desktop environment for Unix workstations.

Linux Kernel

The core of the Linux operating system, including networking.

Linux Workstation

The computer running the Linux operating system that is used for developing, compiling, and building the kernel and target file system that is loaded and executed on the EVM.

Minicom

Minicom is a menu-driven, serial communication program, and includes ANSI color, dialing directory, dial-a-list, script language, and so forth. Minicom is a clone of the MS-DOS Telix program.

MMU

The Memory Management Unit (MMU) is a component of a processor architecture. The MMU is responsible for mapping physical addresses defined by the hardware configuration into the virtual addresses the are used by the Linux-based software. All Linux kernels require that the processor support an MMU; uClinux is a special version of Linux for processors that do not support an MMU.

NFS

The Network File System (NFS) allows machines to mount a disk partition on a remote machine as if it were on a local hard drive. This allows for fast, seamless sharing of files across a network.

OSD

On-screen display.

Target Hardware

The hardware running uClinux.

rrload

The RidgeRun rrload bootloader allows users to manage the loading, storing, and invoking of a Linux kernel and root file system. In normal operation, the bootloader resides in flash and is the first program run when powering up. Unless intercepted, rrload will typically transfer control to the stored system.

SDK

Software development kit.

SOC

System-on-a-chip.

Target File System

The file system for a particular target hardware.

TI

Texas Instruments, Inc.

Toolchain

Tools and utilities used to build applications and other code for the target hardware.

UI

User interface.

x86

Any processor compatible with the Intel 386, 486, or Pentium family.

XIP

Execute in place.

APPENDIX C Jumpers

Jumpers settings are dependent on the version of the target hardware you are using. This section lists some jumper settings for EValuation Module (EVM) hardware that is commonly available.

APPENDIX C.1 AmRoad DSC25 EVM Jumpers

APPENDIX C.2 TI DM270 EVM Jumpers

Configure the jumpers as described in section 2-1 Default jumper settings in the TMS320DM270GHK Evaluation Module Installation Guide, as summarized below.. In addition, additional jumpers that may be needed depending on your model, also listed below.

Note: there are jumpers labeled "J" and other jumpers labeled "JP", like J4 and JP4. Double check the jumper label to make sure it matches.

APPENDIX C.3 TI DM320/DM342 EVM Jumpers

Orient the board with the Texas instruments logo upper middle section.

APPENDIX C.3.1 Factory Default Jumper Settings

Processor board version 1.2.

Base board version 1.2.