Configuration -- Platform-specific Configuration Options
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.
The platform HAL package supports three separate startup types:
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.
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
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
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.
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
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.
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:
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.
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
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
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