Configuration

Configuration
	Chapter 274. Intel XScale IXDP425 Network Processor Evaluation Board Support

Overview

The IXDP425 platform HAL package is loaded automatically when eCos is configured for the ixdp425 target. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.

Configuring for the ixdp425 target also causes the IXP4xx processor HAL to be included. Many configuration options in relation to the peripheral IXP425 devices including serial UARTs, clocks, etc. are described in the IXP4xx processor HAL documentation, which should be referred to.

Startup

The platform HAL package supports three separate startup types:

RAM: This is the startup type which is normally used during application development. The board has RedBoot programmed into flash and boots into that initially. arm-eabi-gdb is then used to load a RAM startup application into memory and debug it. It is assumed that the hardware has already been initialized by RedBoot. By default a standalone application will use the eCos virtual vectors mechanism to obtain certain services from RedBoot, including diagnostic output.
ROM: This startup type can be used for finished applications which will be programmed into flash at physical address 0x50000000. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization.
ROMRAM: This startup type can be used for finished applications which will be programmed into flash at physical location 0x50000000. However, when it starts up, the application will first copy itself to RAM at virtual address 0x00000000 and then run from there. RAM is generally faster than flash memory, so the program will run more quickly than a ROM-startup application. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization.

RedBoot and Virtual Vectors

If the application is intended to act as a ROM monitor, providing services for other applications, then the configuration option CYGSEM_HAL_ROM_MONITOR should be set. Typically this option is set only when building RedBoot.

If the application is supposed to make use of services provided by a ROM monitor, via the eCos virtual vector mechanism, then the configuration option CYGSEM_HAL_USE_ROM_MONITOR should be set. By default this option is enabled when building for a RAM startup, disabled otherwise. It can be manually disabled for a RAM startup, making the application self-contained, as a testing step before switching to ROM startup.

If the application does not rely on a ROM monitor for diagnostic services then the serial port will be claimed for HAL diagnostics.

Flash Driver

The IXDP425 is supplied by default with a 16Mbyte Intel StrataFlash 28F128J3 parallel Flash device.

The CYGPKG_DEVS_FLASH_STRATA_V2 package contains all the code necessary to support this part and the platform HAL package contains definitions that customize the driver to the IXDP425 board. This driver is not active until the generic Flash support package, CYGPKG_IO_FLASH, is included in the configuration.

The device is located in a socket on a board labelled both U22 and "BOOT ROM", and can be replaced with compatible Intel StrataFlash 28FxxxJ3 parts. RedBoot will use the Common Flash Interface (CFI) to determine the Flash device geometry.

Ethernet Driver

The IXDP425 development kit includes an Intel i82559-based PCI Ethernet NIC. The CYGPKG_DEVS_ETH_INTEL_I82559 package contains all the code necessary to support this device and the CYGPKG_DEVS_ETH_ARM_IXDP425_I82559 package contains definitions that customize the driver to the IXDP425 board. This driver is not active until the generic Ethernet support package, CYGPKG_IO_ETH_DRIVERS, is included in the configuration.

The IXDP425 is also supplied with Network Processing Engine (NPE) modules, however these are not supported in this release.

CompactFlash True IDE Driver

The IXP425 variant HAL includes support for CompactFlash IDE devices accessed in True IDE mode directly on the IXP425 expansion bus. This is described further in the IXP4xx processor HAL documentation.

However note that the use of CS2 conflicts with use of the hex display, which also operates from the CS2 chip select, and so the use of the hex display by eCos/RedBoot will be disabled if CF IDE support is enabled. In addition it is expected that the hex display will show random unpredictable values during CF IDE accesses.

Other IXP425 peripherals

Details in relation to on-chip IXP425 peripherals such as PCI IDE driver, watchdog support, serial support, clocks, interrupts and so forth are described further in the IXP4xx processor HAL documentation.

Compiler Flags

The platform HAL defines the default compiler and linker flags for all packages, although it is possible to override these on a per-package basis. Most of the flags used are the same as for other architectures supported by eCos. There are just two flags specific to this port:

-mcpu=xscale

The arm-eabi-gcc compiler supports many variants of the ARM architecture. A -m option should be used to select the specific variant in use, and with current tools -mcpu=xscale is the correct option for the XScale IXP425 CPU.

-mbig-endian

The arm-eabi-gcc compiler will compile all code into big endian (most significant byte first) format. This is the default endianness for this port. Without this flag, arm-eabi-gcc generates little endian code. You must ensure your application is built for the same endianness as RedBoot.

Although RedBoot endianness can be controlled by enabling or disabling the configuration option CYGHWR_HAL_ARM_BIGENDIAN, it is more convenient to use the minimal configuration files (.ecm files) as described earlier.

-mthumb

The arm-eabi-gcc compiler will compile C and C++ files into the Thumb instruction set when this option is used. The best way to build eCos in Thumb mode is to enable the configuration option CYGHWR_THUMB.

-mthumb-interwork

This option allows programs to be created that mix ARM and Thumb instruction sets. Without this option, some memory can be saved. This option should be used if -mthumb is used. The best way to build eCos with Thumb interworking is to enable the configuration option CYGBLD_ARM_ENABLE_THUMB_INTERWORK.


Setup		JTAG debugging support

Name