Cadenux ARM7 BSP Configuration Tool

Manual Version 1.4

Copyright Notice

© 2003 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

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. 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

Revision

Release Date

Changes
1.0 01/06/03 Initial Release
1.1 01/11/03 Added description of the memconfig.tk graphical front-end.
1.2 02/27/03 Added description of the Build System button. Changed the name to "BSP Configuration Tool."
1.3 03/05/03 Added screen shots.
1.4 08/04/04 Updated screen shots. Updated input variable descriptions. Added description of 'make selconfig'

Table of Contents

1 Introduction
2 User Interface

3 Configuration Files

4 Configuration Variables

5 Changing the BSP Configuration

APPENDIX A Glossary
APPENDIX B Configuration Variable Index

1 Introduction

History. Standard Linux kernel configuration is performed using special options built into the Linux Makefile. Make options make config or make xconfig can be used to generate a new kernel configuration.

Cadenux has developed an additional configuration tool, the BSP configuration tool, to supplement the stand Linux configuration tools. The motivations for extending the configuration capability are summarized below:

  • The embedded Linux environment consists of much more than just the Linux kernel, it also includes applications, filesystems, tools, bootloaders, etc. The Board Support Package (BSP) is the integration of all of these components. The Linux configuration tools do not easily extend to provide such a high level of integrated, BSP configuration.

  • Many of the BSP configuration variables are complex in nature and there are also complex interactions between different configuration variables. The Linux configuration tools are based on a simplified, script language (based on a shell script). More powerful language capabilities are needed to meet Cadenux' configuration objectives.

The BSP Configuration Tool: memconfig. The Cadenux BSP configuration tools were developed to address those needs. The basic Cadenux BSP configuration tools is called memconfig At the highest level, the memconfig works much the same way as the Linux configuration tools:

  • It accepts a configuration file (called config.last) as an input. This configuration file contains input variables that determine the behavior of the tools.

  • It generates a Makefile fragment (called Make.defs) that is incorporated into all other makefiles in the system. Thus, the execution of the BSP configuration tool can control how every component of the BSP is built.

  • It generates a C header file (called memconfig.h that is directly included by some C files in the system. This header file contains C preprocessor definitions that can assign values to C variables (such as addresses) and enable, disable or customized conditionally compiled logic. Thus, the execution of the BSP configuration tool can the nature of the BSP components that are built.

Graphics Front-End: memconfig.tk. The basic Cadenux BSP configuration tools, memconfig, contains no user interface other than primitive command line arguments as described A Tcl-based graphical front is also provided. This graphical front end provides a simple what alter configuration settings

Document Overview. This document will cover the following aspects of the BSP configuration tool:

  1. User Interface. The interface for using the Cadenux BSP configuration tool is described in this section. This section addresses all of the options of the memconfig command line interface and of the memconfig.tk graphical interface.

  2. Configuration Files. This section will discussed the files generated by the configuration management tools.

  3. Configuration Variables. All of the configuration variables recognized by the BSP configuration tool are summarized in this section. These variables are also cross-referenced in alphabetical order in APPENDIX B or this document.

  4. Changing the BSP Configuration. The steps required to change the configuration of the BSP are summarized in this section.

2 User Interface

2.1 memconfig Command Line Options

Command Line Format. The BSP configuration tool can be invoked from a Linux shell using a command line as follows:

USAGE:

    config-tools/memconfig [--silent] [--file <file-name>]
                       [--cfgfile <file-name>] [--bsp_dir <directory>] 
                       [--debug] [--help] <variable>=<value>

Command Line Arguments. Where the ./memconfig options are as defined below:

OPTIONS:

<variable>=<value>
The option sets the input configuration <variable> to the specified <value>. Options of this form may be supplied multiple times to set multiple <variable>s. All recognized values for both <variable>s and <value>s are summarized below.
--silent
Use only the settings found in the configuration file, config.last. This option is reserved for future support of a user interface. In this case, this option would suppress the activation of the user interface and would run "silent". At present, this option is ignored.
--file <file-name>
Take command line inputs from <file-name>
--cfgfile <file-name>
Read from the configuration file <file-name> instead of the default configuration file (config.last)
--bsp_dir <directory>
Stores created files in appropriate locations in <directory>.
--debug
Emits program debug information on stdout when the program runs.
--help
The command line options accepted by the BSP configuration can be obtained at any time by providing the --help option to the command line tool.

Other Tool Inputs. In addition to this command line options, the BSP configuration also receives input information via:

  • Configuration File. The program receives variable settings from a configuration file as described below. The possible variable settings in the configuration are identical to the possible settings from the command line option <variable>=<value> described above and enumerated below.

  • Environment Variables. Input variable settings can also be supplied to the BSP configuration tool as shell environment variables. The BSP configuration will examine the execution environment settings to see if any of the input variables summarized below are defined in the environment. If so, these settings will also be used.

Program Default Settings. For most variables, the BSP configuration program will provide reasonable default settings if a value for the input variable not provided through any of these possible sources.

Precedence of Inputs. The same input variables can be set from multiple sources. In the event that the same variable is set multiple times from different input sources, the following take precedence:

  • Highest Priority. Variable settings provided via the command line <variable>=<value> option will take precedence of other settings for the <variable> from any other source.

  • Middle Priority. Variable settings provided via environment variables will override any settings provided in the configuration file.

  • Lowest Priority. The lowest priority settings are those obtained from the configuration file. These can only override program default settings.

2.2 memconfig.tk Graphical Interface

Command Line Format. The BSP configuration graphical front-end is written in Tcl. The Tcl script is contained in a script called memconfig.tk. Like most Tcl scripts, memconfig.tk is invoked though the simple windowing shell, wish as follows:

USAGE:

    wish -f config-tools/memconfig.tk &

For convenience, the BSP configuration graphical front-end can also be invoked from the Cadenux top-level makefile as follows:

USAGE:

    make bspconfig

You will normally want to invoke the BSP configuration graphical front-end using make as shown above.

Command Line Arguments. memconfig.tk is a graphical tool and does not recognize any special command line arguments.

Graphical Interface. The memconfig.tk script leverages highly from the Linux configuration script that is built dynamically when the user configures the Linux kernel via the command make xconfig. Because of this, the memconfig.tk has a very common look and feel with the Linux kernel configuration tool.

When invoked, memconfig.tk will present a window containing nine buttons. On the left hand side of the window, are four buttons that can be used to modify configuration input variables that will be provided to memconfig. These four buttons are:

  1. Platform Identification. This button provides a mechanism to identify the platform for which the configuration is provided. When selected, this button will present a new window. This new window will contain all of the controls necessary to modify the input variables as described below.

  2. Memory Resource Description. This button provides a mechanism to modify the description of the platform's memory resources. When selected, this button will present a new window. This new window will contain all of the controls necessary to modify the input variables as described below.

  3. BSP Component Description. This button provides a mechanism to modify the description of the components that comprise the BSP. When selected, this button will present a new window. This new window will contain addition buttons that can be used to modify any BSP component: Bootloader, kernel, filesytem, or selected device settings below.

    1. Bootloader Description. This button provides a mechanism to modify the description of the bootloader component. When selected, this button will present a new window. This new window will contain all of the controls necessary to modify the bootloader input variables as described below.

    2. Kernel Description. This button provides a mechanism to modify the description of the kernel component. When selected, this button will present a new window. This new window will contain all of the controls necessary to modify the kernel input variables as described below.

    3. FileSystem Description. This button provides a mechanism to modify the description of the filesystem component. When selected, this button will present a new window. This new window will contain all of the controls necessary to modify the filesystem input variables as described below.

    4. Device Description. This button provides a mechanism to modify the description of the selected devices in the BSP. When selected, this button will present a new window. This new window will contain all of the controls necessary to modify the selected device input variables as described below.

  4. Network Settings. This button provides a mechanism to modify the platform's network settings. When selected, this button will present a new window. The new window will contain all of the controls necessary to modify the input variables as described below.

On the right hand side of the window are five more buttons that can be used to control the behavior of memconfig.tk.

  1. Generate Configuration. This button will be activated if memconfig.tk can generate and new BSP configuration. If selected, this button will perform the following actions:

    • Create a file called memconfig.dat in the current directory. This file contains all of the new values of all of the settings that where changed using the memconfig.tk menus.
    • Execute ./memconfig passing it the command line: -f memconfig.dat. As described above, the new settings received via the command will override the settings taken from the config.last file.
    • Copy the result memconfig.h into the correct position under the linux/include/asm-armnommu/arch-<CADENUX_ARCH> and rrload sub-directories.
    • If any critical variables were changed that would require a kernel reconfiguration (such as the root file system type), then the user will be prompted to reconfigure the kernel. And,
    • Terminate the script.

    The Generate Configuration button will not be active if:

    • The memconfig executable does not appear in the current directory, or if
    • A configuration has not been loaded. memconfig.tk will automatically load the config.last configuration file from the current directory when it is started -- provided that config.last exists in the current directory. If not, a new configuration can be loaded later using the Load Configuration as described below. Loading the configuration will activate the button.

    If certain critical BSP parameters, then it is advisable to also reconfigure the kernel. If the BSP configuration tool detects such a situation, it will prompt the user:

    If anything other than Cancel is selected, the BSP configuration tool will start the Linux configuration.

    In any event, at the completion of the BSP configuration, a prompt will be provided to terminate the BSP configuration:

  2. Load Configuration. At any time, a configuration file can be loaded by selecting this button. You will be prompted for the configuration file name, and the configuration will be loaded. If a previous configuration existed in memory, that configuration will be overwritten. If no configuration was previously loaded, then the Generate Configuration button will become active.

    Warning: The Load Configuration will also replace the version of config.last in the current working directory with the specified configuration file

  3. Configure Kernel. As a convenience, memconfig.tk will also support configuration of the Linux kernel. If the Configure Kernel button is selected, a menu will be provided with four selections:

    1. Current. If the Current is selected, the kernel configuration will be performed using the .config kernel configuration file already in place in the linux subdirectory. NOTE: This button will be disabled if the kernel configuration, linux/.config does not exist
    2. Default. If selected, this option will copy the default kernel configuration file for the selected platform, overwriting any existing linux/.config file. The default kernel file selection will be the following file: build/config.$CADENUX_ARCH.$CADENUX_PLATFORM. NOTE: This button will be disabled if this default configuration file does not exist
    3. New. If selected, this option will remove any existing linux/.config kernel configuration file prior to starting the kernel configuration. The is the desired option only when a completely new configuration is being created.
    4. Cancel. This option will terminate the kernel reconfiguration and close the selection window.

    After any selection is made (other than Cancel), the kernel configuration will be initiated as though the following command had been entered: make -C linux xconfig.

    NOTE: This button will be disabled if the linux subdirectory does not exist.

  4. Build System. This button allows you to build any or all of the Cadenux BSP components from the BSP configuration tool's graphical interface. When selected, you will be presented with five self-explanatory options:

    1. RRLOAD: Build the rrload bootloader
    2. LINUX: Build the Linux kernel
    3. FS: Build the file system
    4. ALL: Build everything
    5. Cancel: Do not build anything now

    If the BSP configuration detects that configuration has changed, it will prompt to generate the appropriate configuration files BEFORE the BSP is built. Otherwise, the unsaved configuration will have no effect on the build.

  5. Quit. This button will terminate the configuration tool without generating or modifying any files. You will be prompted to verify that this is really what you intended to do.

Creating a New Configuration. The memconfig.tk is most useful for modifying existing configurations. In order to create a new configuration, the following steps are suggested:

  1. rm config.last. Remove any existing config.last file from the current working directory. This prevents memconfig from picking up any erroneous settings from a previous configuration. Deleting the file should be safe because memconfig leaves backup copies of all configuration files under the build directory.

  2. ./config-tools/memconfig CADENUX_ARCH=xxx CADENUX_PLATFORM=yyy . Running memconfig with these minimum settings will create a new config.last file with good default values. Then follow the instructions below for Modifying an Existing Configuration.

    Or,

  3. Execute make bspconfig to run the graphical front-end. Since no initial config.last is available, most of the field in the BSP configuration tool will be blank. Simply enter the basic information that you need to define the BSP configuration (as a minimum, the platform should be identified).

    Generate the configuration with most of the fields left blank. The BSP configuration tools will automatically fill in the blank or missing information with reasonable default values for the platform the you have selected. These default setting will appear in a new, default config.last file. Then, follow the instructions below for Modifying an Existing Configuration. The next time the BSP configuration tool executed, all of the blank fields will be filled in with default values.

Modifying an Existing Configuration. Execution of memconfig.tk normally modifies the current configuration, that is, the one described by the config.last file in the current working directory. To modify a different configuration, simply start memconfig.tk then use the Load Configuration to load a different configuration. Configuration files are normally retained under the build directory by the memconfig tool. You can remove config.last before starting memconfig.tk if you will to suppress the initial loading of that file.

2.3 selconfig.tk Configuration Manager

The configuration files created by the BSP configuration tools are retained in the BSP ./build directory as described below. selconfig is a quick way to summarize and select from the available configurations in the ./build.

Command Line Format. The selconfig tool is written in Tcl. The Tcl script is contained in a script called selconfig.tk. Like most Tcl scripts, selconfig.tk is invoked though the simple windowing shell, wish as follows:

USAGE:

    wish -f config-tools/selconfig.tk &

For convenience, the selconfig can also be invoked from the Cadenux top-level makefile as follows:

USAGE:

    make selconfig

In either case, you will be presented with a menu of all available configurations in your ./build directory. Selecting one of these options will instantiate that configuration as the current configuration. After changing configurations, it will be necessary to do the following on 2.4 platforms (not necesary on 2.6 platforms):

    cd linux
make dep

3 Configuration Files

File I/O. The primary input and output to the BSP configuration tool is via files. This section will discuss all of the files used by the BSP configuration tool.

Input Files. As described above, the BSP configuration tool receives input configuration information from several sources. One of these sources is through a Configuration File as is described below.

Output Files. As the BSP configuration tool executes, it will generate additional files that contain the result of the BSP configuration algorithms. The files include:

  • An updated Configuration File that reflects all of the input variable settings as well as any programmatic adjustments made to the input settings. This configuration file will be used the next time that the BSP configuration tool is run to assure that the tool starts with the default settings as were used the last time that the program executed.

  • A C header file that is included directly by some C files in the system. This header file contains C preprocessor definitions that can assign values to C variables (such as addresses) and enable, disable or customized conditionally compiled logic.

  • A Makefile fragment that is incorporated into all other makefiles in the system.

  • A setenv environmental settings file. This file contains a very small number of environment variable settings that are necessary to use the Cadenux BSP environment.

These files are discussed in the following paragraphs.

3.1 Configuration File: config.last

File Format. A configuration file is used both as input and output by the BSP configuration tool. The configuration file is in the form of a shell script, but with some restrictions:

  • The configuration file can only contain comments, blank lines, and variable assignments of the form:

      <variable>=<value>

    (in fact, the configuration could even be sourced to provide inputs to the program via environment variables).

  • Only those input variables described below can be supplied in the configuration file.

File Naming. The BSP configuration tool accepts input configuration information from a file named config.last. This file must reside in the same directory in which the configuration tool is executed.

The BSP configuration tool generates two, identical configuration files as output. One is, again, config.last. The output file overwrites the original input file adding the default values for any input variables that were not provided on input and also updating the input values with any adjustments that were made by the BSP configuration tool algorithms.

The second, identical configuration is written to the file build/memconfig.<architecture>.<platform> where:

  • <architecture> is the same as the value for the input variable CADENUX_ARCH as it appears in the configuration file. And,

  • <platform> is the same as the value for the input variable CADENUX_PLATFORM as it appears in the configuration file.

This second configuration file copy is useful if you are maintaining multiple platform configurations: At any time, the file at build/memconfig.<architecture>.<platform> can be copied to config.last to restore a different configuration.

3.2 C Header File: memconfig.h

File Format. This is a standard, C preprocessor header file. It may contain only C comments and simple definitions (or "undefinitions") of C preprocessor macros as enumerated below. Note: Because this file contains only simple C preprocessor macros, it may be included by (preprocessed) assembly language files as well as C source files.

File Naming. A single C header file is generated as build/memconfig.h.<architecture>.<platform> where again:

  • <architecture> is the same as the value for the input variable CADENUX_ARCH as it appears in the configuration file. And,

  • <platform> is the same as the value for the input variable CADENUX_PLATFORM as it appears in the configuration file.

In order to be useful, this header file must be copied into additional locations in the BSP. This may be done be additional support scripts not addressed in this document. The normal locations where this C header file should appear are:

  • rrload/memconfig.h, and

  • linux/asm/arch/memconfig.h.

3.3 Makefile Fragment: Make.defs

File Format. Since this file is included in Makefiles, it must conform to the syntax required of the make utility. This file will contain only variable assignments as enumerated below.

File Naming.

The BSP configuration tool generates two, identical makefile fragments as output. One is Make.defs is generated in the same directory in which the BSP configuration tool executed.

The second, identical makefile fragment is written to the file build/Make.<architecture>.<platform> where (once again):

  • <architecture> is the same as the value for the input variable CADENUX_ARCH as it appears in the configuration file. And,

  • <platform> is the same as the value for the input variable CADENUX_PLATFORM as it appears in the configuration file.

This second makefile fragment copy may be a useful record is a subsequent execution of the BSP configuration over-writes the Make.defs file.

3.4 Environmental Settings: setenv

File Format. This file is a simple shell script. It contains only the settings for a few key environment variables.

File Naming. The BSP configuration tool generates two, identical setenv files as output. One is setenv is generated in the same directory in which the BSP configuration tool executed.

The second, identical setenv file is written to the file build/setenv.<architecture>.<platform> <architecture> and <platform> are as described above for the other output files.

4 Configuration Variables

This section provides definitions for all of the configuration variables used by the BSP configuration tool. These configuration variables are discussed in three groupings:

  1. Input Variables. These are the variables provided in config.last, or in the environment, or in the Command Line Options. These are the variable input values that determine the resulting, output BSP configuration.

  2. Output Variables. These are the variables generated by the BSP configuration tool based on the input variables. These include:

4.1 Input Variables

These are the variables provided in config.last, or in the environment, or in the Command Line Options. These are the variable input values that determine the resulting, output BSP configuration.

In order to specify the BSP configuration, three broad classes of variables must be specified:

  1. Platform Identification
  2. Memory Resource Description Variables
  3. BSP Component Description Variables

If any of these variable settings are omitted from the config.last, the environment, and the Command Line Options. the BSP configuration tool will attempt to provide suitable default values. After the BSP configuration tool executes, it will update the config.last file. This file can be examined to determine what default values were selected by the tool.

4.1.1 Platform Identification

Platform Identification

CADENUX_ARCH
Identifies the target processor family. Recognized options: dsc21, dsc24, dsc25, dm270, c5471, omap1510, dm310, dm320, at91rm9200, iMX1, and iMX2
platform_manufacturer
A string identifying the board manufacturer. Recognized manufacturer names include: TI, AmRoad, Motorola, Cogent, Ittiam, Ingenient, Appro, and Custom. This will be prepended to the platform version string to create the CADENUX_PLATFORM variable
platform version
An arbitrary string identifying the platform configuration. This will be appended to the platform manufacturer string to create the CADENUX_PLATFORM variable.
CADENUX_PLATFORM
A string identifying the platform configuration. It consists of a prefix identifying the board manufacturer followed by an arbitrary number of characters that can be used to identify different software configurations on the same board.
CADENUX_HOST
A string identifying the host development environment. Recognized options: linux and cygwin

4.1.2 Memory Resource Description

These values maybe edited to change the memory configuration the next time Configure is executed.

SDRAM Memory Description

CADENUX_SDRAM_TYPE
The type of SDRAM memory installed (if known). Recognized SDRAM part identifiers include:
  1. SDRAM_TYPE_UNKNOWN
  2. SDRAM_TYPE_D4564163 (8 Mbyte/chip),
  3. SDRAM_TYPE_K4S561632D (32 Mbyte/chip),
  4. SDRAM_TYPE_TC55V16256 (512 Kbytes/chip),
  5. SDRAM_TYPE_K4S281633D (16 Mbyte/chip),
  6. SDRAM_TYPE_K4S643233F (32 Mbyte/chip),
  7. SDRAM_TYPE_K4M563233D (8 Mbyte/chip),
  8. SDRAM_TYPE_HY57V653220 (8 Mbyte/chip), and
  9. SDRAM_TYPE_HY5V52C (32Mbx4/chip).
At present, this setting is only used by the bootloader in order to correctly configure the SDRAM part at boot-up.
CADENUX_SDRAM_BASE
The address of the beginning of installed SDRAM.
CADENUX_SDRAM_SIZE
The size (in bytes) of the installed SDRAM.

FLASH Memory Description

CADENUX_NFLASH_PARTS
The number of flash parts installed on the platform. Only values 1 or 2 are valid.
CADENUX_FLASH_TYPE
The type of FLASH memory installed (if known). Recognized FLASH memory part identifiers include:
  1. Unknown,
  2. SRAMToshiba TC58FB160FT (2Mbyte/chip),
  3. Fujitsu MBM29DL323B (4Mbyte/chip),
  4. Intel 28F128 (2Mbyte/chip),
  5. Intel 28F160 (2Mbyte/chip),
  6. Intel 28F320 (4Mbyte/chip),
  7. Two interleaved Intel 28F320 (4Mbyte/chip),
  8. AMD AM29DL164DT (2Mbyte/chip),
  9. Two AMD AM29L640D (8Mbyte/chip),
  10. AMD AM29DL323DT/B,
  11. Fujitsu 29LV320T (4Mbyte/chip),
  12. Hynix HY29LD320B (4Mbyte/chip),
  13. CFI command set 2 compatible flash chip (usually best choice), and
  14. Macronix MX29LV160BT (2Mbyte/chip).
CADENUX_FLASH_BASE
The address of the beginning of installed FLASH.
CADENUX_FLASH_SIZE
The size (in bytes) of the installed FLASH part.
CADENUX_FLASH_ERASE_SIZE
The size (in bytes) of a (typical) FLASH erase block. Actual flash parts may have variably sized erase blocks, particularly in regions of the flash part intended for bootloader storage. Here, only the size of the "typical" erase block is needed. This value is used to control alignment of large firmware components in the flash memory map. This value must be an power of two.
CADENUX_FLASH_OFFSET
The offset (in bytes) where flash data begins. The beginning of some flash parts may contain other information such interrupt vectors, diagnostic programs, etc. If this value is non-zero, then all of the flash components will be offset by this amount in the flash part. Otherwise, the flash components will be positioned at the beginning of the flash address space.
CADENUX_FLASH2_TYPE
If the board has two FLASH devices, then this variable specifies the types of the second flash part. Options are the same as for CADENUX_FLASH_TYPE.
CADENUX_FLASH2_BASE
The starting address of the second installed FLASH part.
CADENUX_FLASH2_SIZE
The size (in bytes) of the second installed FLASH part.
CADENUX_FLASH2_ERASE_SIZE
The size (in bytes) of a (typical) FLASH erase block in the second FLASH part. This value must be an power of two. It is used to control data alignment in the flash memory map.

IRAM Memory Description

CADENUX_USE_IRAM
Utilize CPU's internal RAM (IRAM) for key text and data This option is not meaningful on all processors.
CADENUX_IRAM_BASE
If CADENUX_USE_IRAM is selected, IRAM base provides the link address for kernel components resident in the processor's internal RAM (IRAM). This is not necessarily that base address of the IRAM memory. CADENUX_IRAM_BASE allows an IRAM memory region to be reserved for use by a program other than the kernel.

4.1.3 BSP Component Description

Bootloader Description

CADENUX_BTLDR
A string identifying the bootloader. Recognized bootloader names include: CADENUX_BTLDR_RRLOAD, CADENUX_BTLDR_UMON, and CADENUX_BTLDR_REDBOOT.
CADENUX_BTLDR_TEXT_SIZE
The size (in bytes) of the "constant" portion of the bootloader (i.e., the "text" section). This amount of memory is reserved in both FLASH and SDRAM. This size may be increased due to FLASH alignment requirements (see above).
CADENUX_BTLDR_PARAMS_SIZE
The size (in bytes) of memory FLASH memory to reserve for bootloader parameters. This size may be increased due to FLASH alignment requirements (see above).
CADENUX_BTLDR_DATA_SIZE
The size (in bytes) of SDRAM memory to reserve for use by the bootloader (i.e., ".bss" sections, stack, etc.).
CADENUX_BTLDR_FAST_BOOT
Enables building the rrload bootloader so that it boots as rapidly as possible.
CADENUX_BTLDR_NO_MENUS
Enables building the rrload bootloader without menus to minimize its size.
CADENUX_BTLDR_IN_HEAP
NO: The bootloader will be positioned at the beginning of SDRAM in a region that may be reused as a framebuffer. YES: The bootloader will be position in the Linux in a memory area with with be reclaimed for reuse by Linux. Framebuffer memory will be disabled.
CADENUX_USB_CONSOLE
YES: Enable support for use of USB as the bootloader console (/dev/ttyUSB0).
CADENUX_ALT_SERIAL_CONSOLE
NO: Use default serial port for rrload and kernel console IO. This associates UART0 with /dev/ttyS0. YES: Use the alternative serial port. This associates UART1 with /dev/ttyS0.
CADENUX_BTLDR_DOC_SUPPORT
YES: Enable rrload logic to support loading a file system image onto an M-Systems DiskOnChip FLASH.
CADENUX_BTLDR_SMARTMEDIA_SUPPORT
YES: Enable rrload logic to support utility functions for Smartmedia cards.

In the following bootloader debug settings, 0:disables the debug feature; 1:enables the debug feature.

Bootloader Debug Options
CADENUX_BTLDR_MEMORY_DEBUG
Enable the memory inspection option in the RRLOAD main menu.
CADENUX_BTLDR_MEMMAP_DEBUG
Enable an option in the RRLOAD main menu that displays the current FLASH memory mapped used by the bootloader.
CADENUX_BTLDR_CS8900_DEBUG
If the processor uses a CS8900 CrystalLan chip to provide the Ethernet interface (that is, only if CADENUX_ETHERNET_TYPE has the value ETHERNET_TYPE_CS8900), this option enables RRLOAD debug output for the ethernet interface.
CADENUX_BTLDR_SMC91111_DEBUG
If the processor uses a SMC91C111 chip to provide the Ethernet interface (that is, only if CADENUX_ETHERNET_TYPE has the value ETHERNET_TYPE_SMC91111), this option enables RRLOAD debug output for the ethernet interface.
CADENUX_BTLDR_DM9000_DEBUG
If the processor uses a DM9000 chip to provide the Ethernet interface (that is, only if CADENUX_ETHERNET_TYPE has the value ETHERNET_TYPE_DM9000), this option enables RRLOAD debug output for the ethernet interface.
CADENUX_BTLDR_FLASH_DEBUG
If set, this selection enables an option in the RRLOAD "Erase" submenu. This option allows erasure of any FLASH sectors.
CADENUX_BTLDR_DEBUG_ALL
The option, if selected, enables all RRLOAD debug options relevant to the currently selected platform.

Kernel Description

CADENUX_USE_MMU
Utilize CPU's Memory Management Unit (MMU) to control memory accesses. This option is not meaningful for processors that do not have an MMU.
CADENUX_KERNEL
A string identifying the Linux kernel version. Recognized kernel version strings include: uclinux-2.0 and uclinux-2.4 for ARM7 platforms and linux-2.4 or linux 2-6 for ARM9 platforms
CADENUX_KERNEL_COMPRESSED
NO: The kernel stored in flash is not compressed. YES: Compress the kernel and store the compressed image in flash.
CADENUX_KERNEL_SDRAM_SIZE
The size (in bytes) of the SDRAM memory reserved to hold the kernel when it executes from SDRAM. This amount of memory is reserved in both FLASH and SDRAM. The FLASH allocation may be increased due to FLASH alignment requirements (see above).
CADENUX_KERNEL_FLASH_SIZE
The size (in bytes) of the memory reserved to hold the kernel when the kernel is stored in FLASH. This size may be increased due FLASH alignment requirements.
CADENUX_KERNEL_STACK
The location of the kernel stack. This can be an IRAM address or SDRAM address or SRAM address. The stack will occupy a 4096 (0x1000) range of memory and this entry is the lower address of that range. This option applies only to the uclinux-2.0 platform. This entry is important only for power management options: The initial kernel stack is used only by the Linux idle process. Putting the idle process stack in IRAM may support other power conservation measures when on the IDLE process is running.
CADENUX_BOOT_FROM_FLASH
0:kernel will run from SDRAM; 1: kernel will run from flash. If boot-from-flash is selected, no SDRAM memory will be reserved for the kernel.
If selected, the kernel will run in place from FLASH. Execution from FLASH may not be desired if the FLASH memory performance is inadequate. If not selected, the kernel will be copied into SDRAM, then executed. If boot-from-flash is selected, no SDRAM memory will be reserved for the kernel. You can not use a compressed kernel and boot from FLASH.

Root Filesystem Description

CADENUX_FLASH_FS
0:FS resides in SDRAM; 1:FS resides in FLASH.
CADENUX_FLASH_FS
NO: The filesystem resides in SDRAM; YES: The filesystem FS resides in FLASH. This option is assumed if a flash filesystem is selected (such as JFFS or JFFS2). The option may, however, also be selected for a ROMFS file system. WARNING: In this case, executables may execute in place in FLASH with a potential performance degradation.
CADENUX_FS_BEFORE_KERNEL
This setting determines the relative positioning of the kernel and the SDRAM file system image. NO: The filesystem will reside after kernel in SDRAM; YES: The filesystem will reside before kernel in SDRAM. This value is meaningful only if CADENUX_FS_SDRAM_SIZE is non-zero and CADENUX_FLASH_FS is NO (meaning that the filesystem resides in SDRAM) and also if CADENUX_BOOT_FROM_FLASH is false (meaning that the kernel also resides in SDRAM).
CADENUX_ROOT_FS
Selects the root file system type. This is the type of file system that Linux uses when booting. This may or may not be the same as CADENUX_RRFLASH_FS. Recognized filesystem options include: romfs, cramfs, jffs, jffs2, ext2fs, ext3, and nfs.
CADENUX_MAXFS_SIZE
If CADENUX_ROOT_FS is ext2 or ext3, then this is the maximum size of the filesystem (in decimal 1024 byte blocks).
CADENUX_JOURNAL_SIZE
If CADENUX_ROOT_FS is ext3, then this is the size (in decimal 1 megabyte blocks) of the journal to be allocated in the filesystem.
CADENUX_RRFLASH_FS
Selects the type of file system residing in FLASH that may require special preparation for RRLOAD. This may or may not be the same as CADENUX_ROOT_FS. Recognized filesystem options include: jffs, jffs2, initrd, and other.
CADENUX_USE_RAMDISKS
Identifies that certain directories should be provided as soft links into a mounted ramdisk. This is a required selected for read-only file system (such as romfs), and optional for performance sensitive file systems (such as jffs). This option should NOT be selected if the root filesystem is a ramdisk! The effected directories include /tmp, /root, /var, and /proc.
CADENUX_FS_COMPRESSED
NO: The file system stored in flash is not compressed. YES: Compress the file system and store the compressed image in flash. Only set to YES if the root file system type is romfs.
CADENUX_FS_FLASH_SIZE
The size (in bytes) of the primary FLASH filesystem image. This value is often the same as the value used for CADENUX_FS_SDRAM_SIZE. Exceptions are if the file system is not copied to SDRAM or if the file system is stored in a compressed format and then decompressed when copied to SDRAM. Note that this value is not selectable; the size of the file system will be caculated from the flash size minus the bootloader image size, minus the bootloader parameter size, minus the kernel size, minus the size of the secondary file system.
CADENUX_FS_SDRAM_SIZE
The size (in bytes) of the primary SDRAM filesystem image. This value must be zero for flash filesystems that do not reside in SDRAM. This value is often the same as the value used for CADENUX_FS_FLASH_SIZE. Exceptions are if the file system is not copied to SDRAM or if the file system is stored in a compressed format and then decompressed when copied to SDRAM.
CADENUX_FS2_FLASH_SIZE
The size (in bytes) of the optional secondary FLASH filesystem image. This value reserves memory for use by the kernel to support a secondary FLASH filesystem (such as JFFS or JFFS2). This value should be an even multiple of the FLASH erase blocksize.
CADENUX_RAMDISK_SIZE
The size (in decimal 1024 byte blocks) of the RAMDISK that must be mounted with the romfs root filesystem type.

Device Description

CADENUX_ETHERNET_TYPE
The type of Ethernet device installed (if known). Recognized ethernet identifiers include:
  1. ETHERNET_TYPE_NONE
  2. ETHERNET_TYPE_UNKNOWN
  3. ETHERNET_TYPE_CS8900
  4. ETHERNET_TYPE_SCM9194
  5. ETHERNET_TYPE_SCM91C111
CADENUX_ETHERNET_PHY
The type of Ethernet transceiver that provides the physical layer (if known). Recognized ethernet transceivers include:
  1. ETHERNET_PHY_UNKNOWN
  2. ETHERNET_PHY_LU3X31T_T64
  3. ETHERNET_PHY_AC101L
Applicable only to the C5471 and AT91RM9200 platforms.
CADENUX_ETHERNET_BASE
The address of the beginning of ethernet device space.
CADENUX_ALT_SERIAL_CONSOLE
NO: Use default serial port for rrload and kernel console IO. This associates UART0 with /dev/ttyS0. YES: Use the alternative serial port. This associates UART1 with /dev/ttyS0.
CADENUX_RESERVED_MEMORY_SIZE
This memory is reserved at the Start of SDRAM and it is not used by the Linux Kernel. This memory can be used for Framebuffer in ARM7 and for CCD in both ARM7 and ARM9. This size (in bytes) assures that a sufficient amount of memory is reserved for the framebuffer or CCD.
If the BSP is configured so that the bootloader lies in SDRAM prior to the kernel, then the memory used by bootloader can be reclaimed after booting for use as device buffers.

The following network settings are used by both rrload for TFTP file transfers and by the /etc/rc.bss file for configuring the target device's network parameters.

Network Description

CADENUX_NETWORK_TARGET_IP
The IP address used by the target hardware in the form XXX.XXX.XXX.XXX, for example 10.0.0.20. Used by rrload for TFTP file transfers and by the kernel as the device's IP address.
CADENUX_NETWORK_TARGET_NAME
The IP network name assigned to the target platform.
CADENUX_NETWORK_TARGET_MAC
The ethernet physical media access (MAC) address in the form XX:XX:XX:XX:XX:XX, for example 00:E0:81:10:36:DF. Used by rrload for TFTP file transfers and by the kernel as the device's ethernet hardware address.
CADENUX_NETWORK_TARGET_MASK
The network mask identifies what part of the IP address represents the network number (or sub-LAN address) and what part represents the host address of the target device. Used to determine if a destination device can be reached directly (true when the destination device is on the same sub-LAN as the target device) or if the packet needs to be sent to the gateway device to be forwarded to the sub-LAN containing the destination device. The network mask, when expressed in binary, is a series of all ones followed by a series of all zeros, totaling 32 bits. The network mask is expressed in the form XXX.XXX.XXX.XXX, for example 255.255.255.0. Used in the /etc/rc.bss file for network configuration via the ifconfig and route commands. All devices on the same sub-LAN use the same network mask, therefore checking the network mask of a configured device (e.g. /sbin/ifconfig eth0 on your Linux workstation) is an easy way to determine the correct network mask value to use on the target device.
CADENUX_NETWORK_TARGET_BCAST
The broadcast address is used as the destination address when the target device is sending a network packet to all devices on the sub-LAN. The broadcast address is created by concatenating the sub-LAN address and a host address with all address bits being one. The broadcast address is expressed in the form XXX.XXX.XXX.XXX, for example 10.0.0.255. Used in the /etc/rc.bss file for network configuration via the ifconfig command. All devices on the same sub-LAN use the same broadcast address, therefore checking the broadcast address of a configured device (e.g. /sbin/ifconfig eth0 on your Linux workstation) is an easy way to determine the correct broadcast address to use on the target device.
CADENUX_NETWORK_TARGET_GW_IP
A network packet being sent to destination devices which reside on a sub-LAN different than the target device's sub-LAN must be forwarded to the correct sub-LAN using a router. The gateway address is the address of the router. The gateway address is expressed in the form XXX.XXX.XXX.XXX, for example 10.0.0.1. Used in the /etc/rc.bss file for network configuration via the route command to set the default route. All devices on the same sub-LAN generally use the same gateway, therefore checking the gateway address of a configured device (e.g. /sbin/route on your Linux workstation) is an easy way to determine the correct gateway to use on the target device.
CADENUX_NETWORK_TARGET_NET_IP
The local network address is used to determine if a destination address exists on the sub-LAN. The local network address is created by concatenating the sub-LAN address and a host address with all address bits being zero. The local network address is expressed in the form XXX.XXX.XXX.XXX, for example 10.0.0.0. Used in the /etc/rc.bss file for network configuration via the route command. All devices on the same sub-LAN use the same local network address, therefore checking the broadcast address of a configured device (e.g. /sbin/route on your Linux workstation) is an easy way to determine the correct local network address to use on the target device.
CADENUX_NETWORK_SOURCE_IP
The TFTP network source address is used by rrload as the host address to use when doing a TFTP file transfer. The TFTP network source address is expressed in the form XXX.XXX.XXX.XXX, for example 10.0.0.3. Not used by the kernel. You can leave this field blank if you do not use the rrload TFTP feature.
CADENUX_NETWORK_SOURCE_NAME
The IP network name of the workstation that will be used as an RRLOAD TFTP client.
CADENUX_NETWORK_SOURCE_MAC
The TFTP ethernet MAC address is used by rrload as the MAC address to use when doing a TFTP file transfer. The TFTP MAC address is expressed in the form XX:XX:XX:XX:XX:XX, for example 00:03:47:7B:28:40. example 10.0.0.3. Not used by the kernel. You can leave this field blank if you do not use the rrload TFTP feature.

4.2 Output Variables

4.2.1 C Preprocessor Definitions

4.2.1.1 Memory Resource Description

FLASH Memory Description

CADENUX_FLASH_BASE
#defined to be the address of the beginning of installed FLASH. See also CADENUX_FLASH_BASE
CADENUX_FLASH_SIZE
#defined to be the size (in bytes) of the installed FLASH part. See also CADENUX_FLASH_SIZE
FLASH_MEM_BASE
#defined to be equivalent to CADENUX_FLASH_BASE.
FLASH_SIZE
#defined to be equivalent to CADENUX_FLASH_SIZE.

FLASH Memory Map

CADENUX_FLASH_OFFSET
#defined to be the offset (in bytes) where flash data begins. The beginning of some flash parts may contain other information such interrupt vectors, diagnostic programs, etc. All of the flash components will be offset by this amount in the flash part. See CADENUX_FLASH_OFFSET.
CADENUX_BTLDR_FLASH_START
#defined to represent the starting address for bootloader in flash as determined by the BSP configuration tool's algorithms. This start address includes CADENUX_FLASH_OFFSET.
CADENUX_BTLDR_FLASH_OFFSET
#defined to be the difference between CADENUX_BTLDR_FLASH_START and CADENUX_FLASH_BASE.
CADENUX_BTLDR_FLASH_SIZE
#defined
CADENUX_PARAMS_FLASH_START
#defined to represent the starting address for bootloader parameters in flash as determined by the BSP configuration tool's algorithms. This start address includes CADENUX_FLASH_OFFSET.
CADENUX_PARAMS_FLASH_OFFSET
#defined to be the difference between CADENUX_PARAMS_FLASH_START and CADENUX_FLASH_BASE.
CADENUX_PARAMS_FLASH_SIZE
#defined
CADENUX_KERNEL_FLASH_START
#defined to represent the starting address for kernel in flash as determined by the BSP configuration tool's algorithms. This start address includes CADENUX_FLASH_OFFSET.
CADENUX_KERNEL_FLASH_OFFSET
#defined to be the difference between CADENUX_KERNEL_FLASH_START and CADENUX_FLASH_BASE.
CADENUX_KERNEL_FLASH_SIZE
#defined
CADENUX_FS_FLASH_START
#defined to represent the starting address for filesystem in flash as determined by the BSP configuration tool's algorithms. This start address includes CADENUX_FLASH_OFFSET.
CADENUX_FS_FLASH_OFFSET
#defined to be the difference between CADENUX_FS_FLASH_START and CADENUX_FLASH_BASE.
CADENUX_FS_FLASH_SIZE
#defined

SDRAM Memory Description

SDRAM_TYPE_UNKNOWN
#defined to be zero.
SDRAM_TYPE_D4564163
#defined to be one.
SDRAM_TYPE_K4S561632D
#defined to be two.
SDRAM_TYPE_TC55V16256
#defined to be three.
SDRAM_TYPE_K4S281633D
#defined to be four.
CADENUX_SDRAM_TYPE
#defined to be one of the above.
CADENUX_SDRAM_BASE
#defined to be the address of the beginning of installed SDRAM. See also CADENUX_SDRAM_BASE
CADENUX_SDRAM_SIZE
#defined to be the size (in bytes) of the installed SDRAM. See also CADENUX_SDRAM_SIZE

SDRAM Memory Map

CADENUX_BTLDR_SDRAM_START
#defined to be the start of the bootloader in SDRAM.
CADENUX_BTLDR_SDRAM_END
#defined to be the address just after the bootloader and its data allocation. This address will be used to position the ForUpdate version of the bootloader.
CADENUX_RESERVED_MEMORY_START
#defined to be the start of the framebuffer in SDRAM only if the input variable CADENUX_RESERVED_MEMORY_SIZE is non-zero. In this version of the BSP configuration tool, CADENUX_RESERVED_MEMORY_START will be the same as CADENUX_BTLDR_SDRAM_START since the framebuffer allocation logic re-uses the memory used by the bootloader.
CADENUX_FS_SDRAM_START
#defined to be the start address of the file system image in SDRAM only if the input variable CADENUX_FS_SDRAM_SIZE is non-zero. This address may be before or after CADENUX_KERNEL_SDRAM_START depending on the value of the input variable CADENUX_FS_BEFORE_KERNEL.
CADENUX_KERNEL_SDRAM_START
#defined to be the start of the kernel SDRAM allocation only if the input variable CADENUX_BOOT_FROM_FLASH is zero. CADENUX_KERNEL_SDRAM_START is probably NOT the entry point to the kernel.

IRAM Memory Map

CADENUX_USE_IRAM
#defined to be one or #undefined depending on the setting of the input variable CADENUX_USE_IRAM. If #defined, the CPU's internal RAM (IRAM) will be used for key text and data.
CADENUX_IRAM_BASE
#defined to be the address that, at link time, is used to position IRAM resident code depending on the input variable CADENUX_IRAM_BASE.

4.2.1.2 BSP Component Description

Bootloader Debug Options

CADENUX_BTLDR_MEMORY_DEBUG
#defined to be one or #undefined depending on the value of the input variables CADENUX_BTLDR_MEMORY_DEBUG and CADENUX_BTLDR_DEBUG_ALL. The definition will enable bootloader memory inspection.
CADENUX_BTLDR_MEMMAP_DEBUG
#defined to be one or #undefined depending on the value of the input variable CADENUX_BTLDR_MEMMAP_DEBUG and CADENUX_BTLDR_DEBUG_ALL. The definition will enable bootloader memory map dump.
CADENUX_BTLDR_CS8900_DEBUG
#defined to be one or #undefined depending on the value of the input variable CADENUX_BTLDR_CS8900_DEBUG and CADENUX_BTLDR_DEBUG_ALL. The definition will enable bootloader cs8900 ethernet debug
CADENUX_BTLDR_FLASH_DEBUG
#defined to be one or #undefined depending on the value of the input variable CADENUX_BTLDR_FLASH_DEBUG and CADENUX_BTLDR_DEBUG_ALL. The definition will enable flash sector erase logic.

Kernel Description

CADENUX_BOOT_FROM_FLASH
#defined to be one or #undefined depending on CADENUX_BOOT_FROM_FLASH. If defined, the kernel will execute in place in flash and no SDRAM memory will be set aside for the kernel.
CADENUX_BOOT_FROM_SDRAM
#defined to be one or #undefined depending on CADENUX_BOOT_FROM_FLASH. If defined, the kernel will will copied at boot time and will execute in an allocated region in SDRAM.
CADENUX_KERNEL_IMAGE_START
#defined to be the starting address of the kernel memory allocation (not necessarily the kernel entry point). This address may like in either flash or SDRAM depending on the setting of CADENUX_BOOT_FROM_FLASH. It will equivalent to either CADENUX_KERNEL_FLASH_START or CADENUX_KERNEL_SDRAM_START.

Root Filesystem Description

CADENUX_FLASH_FS
#defined to be either zero meaning that the root filesystem resides in SDRAM or one meaning that the root filesystem resides in FLASH. See the input variable CADENUX_FLASH_FS
CADENUX_FILESYS_START
#defined to be the start address of the filesystem image. This could be either an address in FLASH or an address in SDRAM depending on the type of file system (see the input variable CADENUX_ROOT_FS) and whether an XIP file system has been specified (see the input variable CADENUX_FLASH_FS
CADENUX_FILESYS_SIZE
#defined to be the size of the root file system.

Linux Memory Pool

CADENUX_DRAM_BASE
#defined to be the start of the Linux SDRAM memory pool. If the kernel resides in SDRAM, this start address will include the kernel and, in fact, should be the same as both CADENUX_KERNEL_IMAGE_START and CADENUX_KERNEL_SDRAM_START. Otherwise, it will be the address of the beginning of free memory before or after the filesystem, depending on the value of the input variable CADENUX_FS_BEFORE_KERNEL.
CADENUX_DRAM_SIZE
#defined to be total size of the SDRAM memory region visible to the kernel. The size will extend to either the end of SDRAM memory (see CADENUX_SDRAM_SIZE), or to the beginning of the SDRAM filesystem image (see CADENUX_FS_SDRAM_START) if the root filesystem resides in SDRAM (see CADENUX_FLASH_FS) and depending upon the setting of CADENUX_FS_BEFORE_KERNEL.

Device Description

CADENUX_ETHERNET_BASE
#defined to be the address of the beginning of ethernet device space. See the input variable CADENUX_ETHERNET_BASE.
CADENUX_ETHERNET_TYPE
#defined to be the type of the ethernet device installed in EVM. See the input variable CADENUX_ETHERNET_TYPE.
CADENUX_ETHERNET_PHY
#defined to be the type of the ethernet transceiver that provides the underlying ethernet physical layer See the input variable CADENUX_ETHERNET_PHY.

The following network settings are used by both rrload for TFTP file transfers and by the /etc/rc.[platform].bss file for configuring the target device's network parameters.

Network Description

CADENUX_NETWORK_TARGET_IP
See the input variable CADENUX_NETWORK_TARGET_IP
CADENUX_NETWORK_TARGET_MAC
See the input variable CADENUX_NETWORK_TARGET_MAC
CADENUX_NETWORK_TARGET_MASK
See the input variable CADENUX_NETWORK_TARGET_MASK
CADENUX_NETWORK_TARGET_BCAST
See the input variable CADENUX_NETWORK_TARGET_BCAST
CADENUX_NETWORK_TARGET_GW_IP
See the input variable CADENUX_NETWORK_TARGET_GW_IP
CADENUX_NETWORK_TARGET_NET_IP
See the input variable CADENUX_NETWORK_TARGET_NET_IP
CADENUX_NETWORK_SOURCE_IP
See the input variable CADENUX_NETWORK_SOURCE_IP
CADENUX_NETWORK_SOURCE_MAC
See the input variable CADENUX_NETWORK_SOURCE_MAC

4.2.2 Make Variables

Platform Identification

CADENUX_HOST
A string identifying the host development environment. Recognized options: Linux and cygwin. See also the input variable CADENUX_HOST.

4.2.2.2 Memory Resource Description

FLASH Memory Description

CADENUX_FLASH_BASE
Set to the address of the beginning of installed FLASH. See also CADENUX_FLASH_BASE
CADENUX_FLASH_SIZE
Set to the size (in bytes) of the installed FLASH part. See also CADENUX_FLASH_SIZE

FLASH Memory Map

CADENUX_FLASH_OFFSET
Set to the offset (in bytes) where flash data begins. The beginning of some flash parts may contain other information such interrupt vectors, diagnostic programs, etc. All of the flash components will be offset by this amount in the flash part. See CADENUX_FLASH_OFFSET.
CADENUX_BTLDR_FLASH_START
Set to the starting address for bootloader in flash as determined by the BSP configuration tool's algorithms. This start address includes CADENUX_FLASH_OFFSET.
CADENUX_PARAMS_FLASH_START
Set to the starting address for bootloader parameters in flash as determined by the BSP configuration tool's algorithms. This start address includes CADENUX_FLASH_OFFSET.
CADENUX_KERNEL_FLASH_START
Set to the starting address for kernel in flash as determined by the BSP configuration tool's algorithms. This start address includes CADENUX_FLASH_OFFSET.
CADENUX_FS_FLASH_START
Set to the starting address for filesystem in flash as determined by the BSP configuration tool's algorithms. This start address includes CADENUX_FLASH_OFFSET.

SDRAM Memory Description

CADENUX_SDRAM_BASE
The address of the beginning of installed SDRAM. See also the input variable l CADENUX_SDRAM_BASE
CADENUX_SDRAM_SIZE
The size (in bytes) of the installed SDRAM. See also the input variable CADENUX_SDRAM_SIZE

SDRAM Memory Map

CADENUX_BTLDR_SDRAM_START
Set to the start of the bootloader in SDRAM.
CADENUX_BTLDR_SDRAM_END
Set to be the address just after the bootloader and its data allocation. This address will be used to position the ForUpdate version of the bootloader.
CADENUX_FS_SDRAM_START
Set to the start address of the file system image in SDRAM only if the input variable CADENUX_FS_SDRAM_SIZE is non-zero. This address may be before or after CADENUX_KERNEL_SDRAM_START depending on the value of the input variable CADENUX_FS_BEFORE_KERNEL.
CADENUX_KERNEL_SDRAM_START
Set to the start of the kernel SDRAM allocation only if the input variable CADENUX_BOOT_FROM_FLASH is zero. CADENUX_KERNEL_SDRAM_START is probably NOT the entry point to the kernel.

IRAM Memory Map

CADENUX_USE_IRAM
Set to be either y or ndepending on the setting of the input variable CADENUX_USE_IRAM. If set to y, the CPU's internal RAM (IRAM) will be used for key text and data.
CADENUX_IRAM_BASE
CADENUX_IRAM_BASE.

4.2.2.3 BSP Component Description

Bootloader Debug Options

CADENUX_BTLDR_MEMORY_DEBUG
Set to be either y or ndepending on the value of the input variables CADENUX_BTLDR_MEMORY_DEBUG and CADENUX_BTLDR_DEBUG_ALL. The y setting will enable bootloader memory inspection.
CADENUX_BTLDR_MEMMAP_DEBUG
Set to be either y or ndepending on the value of the input variable CADENUX_BTLDR_MEMMAP_DEBUG and CADENUX_BTLDR_DEBUG_ALL. The y setting will enable bootloader memory map dump.
CADENUX_BTLDR_CS8900_DEBUG
Set to be either y or ndepending on the value of the input variable CADENUX_BTLDR_CS8900_DEBUG and CADENUX_BTLDR_DEBUG_ALL. The y setting will enable bootloader cs8900 ethernet debug
CADENUX_BTLDR_FLASH_DEBUG
Set to be either y or ndepending on the value of the input variable CADENUX_BTLDR_FLASH_DEBUG and CADENUX_BTLDR_DEBUG_ALL. The y setting will enable flash sector erase logic.

Kernel Description

CADENUX_BOOT_FROM_FLASH
Set to be either y or ndepending on CADENUX_BOOT_FROM_FLASH. If set to y, the kernel will execute in place in flash and no SDRAM memory will be set aside for the kernel.
CADENUX_BOOT_FROM_SDRAM
Set to be either y or ndepending on CADENUX_BOOT_FROM_FLASH. If set to y, the kernel will will copied at boot time and will execute in an allocated region in SDRAM.
CADENUX_KERNEL_IMAGE_START
Set to the starting address of the kernel memory allocation (not necessarily the kernel entry point). This address may like in either flash or SDRAM depending on the setting of CADENUX_BOOT_FROM_FLASH. It will equivalent to either CADENUX_KERNEL_FLASH_START or CADENUX_KERNEL_SDRAM_START.
CADENUX_KERNEL_STACK
The location of the kernel stack. This can be an IRAM address or SDRAM address or SRAM address. The stack will occupy a 4096 (0x1000) range of memory and this entry is the lower address of that range. This option applies only to the uclinux-2.0 platform. See also the input variable CADENUX_KERNEL_STACK.

Root Filesystem Description

CADENUX_FLASH_FS
Set to either y meaning that the root filesystem resides in SDRAM or or n meaning that the root filesystem resides in FLASH. See the input variable CADENUX_FLASH_FS
CADENUX_FILESYS_START
Set to the start address of the filesystem image. This could be either an address in FLASH or an address in SDRAM depending on the type of file system (see the input variable CADENUX_ROOT_FS) and whether an XIP file system has been specified (see the input variable CADENUX_FLASH_FS
CADENUX_ROOT_FS
Selects the root file system type. See the input variable CADENUX_ROOT_FS.
CADENUX_MKFSIMAGE_ARG
CADENUX_FILESYS_SIZE
Set to the size of the root file system.

Linux Memory Pool

CADENUX_DRAM_BASE
Set to the start of the Linux SDRAM memory pool. If the kernel resides in SDRAM, this start address will include the kernel and, in fact, should be the same as both CADENUX_KERNEL_IMAGE_START and CADENUX_KERNEL_SDRAM_START. Otherwise, it will be the address of the beginning of free memory before or after the filesystem, depending on the value of the input variable CADENUX_FS_BEFORE_KERNEL.
CADENUX_DRAM_SIZE
Set to the total size of the SDRAM memory region visible to the kernel. The size will extend to either the end of SDRAM memory (see CADENUX_SDRAM_SIZE), or to the beginning of the SDRAM filesystem image (see CADENUX_FS_SDRAM_START) if the root filesystem resides in SDRAM (see CADENUX_FLASH_FS) and depending upon the setting of CADENUX_FS_BEFORE_KERNEL.

Device Description

CADENUX_ETHERNET_BASE
Set to the address of the beginning of ethernet device space. See the input variable CADENUX_ETHERNET_BASE.

The following network settings are used by both rrload for TFTP file transfers and by the /etc/rc.[platform].bss file for configuring the target device's network parameters.

Network Description

CADENUX_NETWORK_TARGET_IP
See the input variable CADENUX_NETWORK_TARGET_IP
CADENUX_NETWORK_TARGET_MAC
See the input variable CADENUX_NETWORK_TARGET_MAC
CADENUX_NETWORK_TARGET_MASK
See the input variable CADENUX_NETWORK_TARGET_MASK
CADENUX_NETWORK_TARGET_BCAST
See the input variable CADENUX_NETWORK_TARGET_BCAST
CADENUX_NETWORK_TARGET_GW_IP
See the input variable CADENUX_NETWORK_TARGET_GW_IP
CADENUX_NETWORK_TARGET_NET_IP
See the input variable CADENUX_NETWORK_TARGET_NET_IP
CADENUX_NETWORK_SOURCE_IP
See the input variable CADENUX_NETWORK_SOURCE_IP
CADENUX_NETWORK_SOURCE_MAC
See the input variable CADENUX_NETWORK_SOURCE_MAC

5 Changing the BSP Configuration

5.1 Creating a New BSP Configuration

  1. Start with a Clean Environment. Before we run the BSP configuration tools, we want to make sure that we have no traces of any existing configuration in place. To assure that this is not the case:

    • Open a fresh terminal window on your desktop. This will assure you that you have no spurious environment settings that could interfere with the desired execution of the BSP configuration tool. Environment variables settings could have been made, for example, the last last time that the ./setenv script was executed. Such environment settings may not be harmful, but it is usually best to start from a known, clean state.

    • Remove config.last file. A new config.last file will be created when the BSP configuration tool executes based upon: (1) command line inputs, and (2) program defaults.

  2. Execute the BSP Configuration Tool. Execute the BSP configuration tool as described above. You may want to provide some or all of the following command line variable settings:

    Note: All of these variables can also be set (via environment variables) by sourcing the correct setenv script prior to executing the BSP configuration tool.

    And possibly,

    but you can always change these latter network settings by modifying the configuration as described below.

  3. Copy Header Files. Finally, the generated C header files have to be copied to their final destinations as described above.

5.2 Modifying an Existing BSP Configuration

  1. Establish the Correct Environment. Normally, the correct environment is in place. But, if you are managing multiple configurations, then it may be necessary to copy the correct build/memconfig.<architecture>.<platform> configuration file in place as config.last. Recall that:

    • <architecture> is the same as the value for the input variable CADENUX_ARCH as it appears in the configuration file. And,

    • <platform> is the same as the value for the input variable CADENUX_PLATFORM as it appears in the configuration file.

    2. In this case, you should also copy the corresponding build/memconfig.<architecture>.<platform> as setenv and then source that file so that the correct environment variable settings are in place.

  2. Edit the Configuration File. The config.last can be edited with any text editor. Refer to the input variable discussion for reference. However, for most reconfiguration options, the config.last contains sufficient inline comments to explain the various configuration options.

    3. Note: If you are changing only a few settings, then you may skip editing the config.last file and just provide the new settings on the BSP configuration tool command line as described above.

  3. Execute the BSP Configuration Tool. Then execute the BSP configuration tool as described above. This time, no special configuration options need be provided on the command line since all of the options are defined in the edited configuration file.

  4. Copy Header Files. Finally, the generated C header files have to be copied to their final destinations as described above.

APPENDIX A Glossary

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 TMS320xxx 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.
IRAM
Internal Random Access Memory.
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.
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.
Tcl
Tool Command Language. Tcl is a scripting language. Tcl is also the name of the interpreter for the Tcl language. Tcl (and Tk) were designed by Professor John Ousterhout of the University of California, Berkeley.
TI
Texas Instruments, Inc.
Tk
The X windows toolkit associated with Tcl.
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 B Configuration Variable Index

Configuration Variables

CADENUX_ARCH
Input Configuration Setting
CADENUX_BOOT_FROM_FLASH
Input Configuration Setting, Output C Preprocessor Definition, Output Makefile Setting
CADENUX_BOOT_FROM_SDRAM
Output C Preprocessor Definition, Output Makefile Setting
CADENUX_BTLDR_CS8900_DEBUG
Input Configuration Setting, Output C Preprocessor Definition, Output Makefile Setting
CADENUX_BTLDR_DATA_SIZE
Input Configuration Setting
CADENUX_BTLDR_DEBUG_ALL
Input Configuration Setting
CADENUX_BTLDR_FLASH_DEBUG
Input Configuration Setting, Output C Preprocessor Definition, Output Makefile Setting
CADENUX_BTLDR_FLASH_OFFSET
Output C Preprocessor Definition
CADENUX_BTLDR_FLASH_SIZE
Output C Preprocessor Definition
CADENUX_BTLDR_FLASH_START
Output C Preprocessor Definition, Output Makefile Setting
CADENUX_BTLDR_MEMMAP_DEBUG