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 initialization.
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
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.
The IXDP425 is supplied by default with a 16Mbyte Intel StrataFlash 28F128J3 parallel Flash device.
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.
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.
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
-moption should be used to select the specific variant in use, and with current tools
-mcpu=xscaleis 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 earlier.
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
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