The AT91RM9200-EK/DK platform HAL package is loaded automatically when eCos is configured for at91rm9200ek or at91rm9200dk targets. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.
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 the 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 0x10000000. 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 0x10000000. 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 AT91RM9200-EK board contains an 8Mbyte Atmel AT49BV6416 parallel Flash
CYGPKG_DEVS_FLASH_AMD_AM29XXXXX_V2 package contains all the
code necessary to support this part and the platform HAL package contains
definitions that customize the driver to the AT91RM9200-EK board. This driver is
not active until the generic Flash support package,
CYGPKG_IO_FLASH, is included in the configuration.
The AT91RM9200-EK/DK boards use the AT91RM9200's internal EMAC ethernet device
attached to an external Davicom DM9161A PHY. The
CYGPKG_DEVS_ETH_ARM_AT91RM9200 package contains all the
code necessary to support this device and the platform HAL package contains
definitions that customize the driver to the AT91RM9200-EK/DK boards.
This driver is not active until the generic Ethernet support package,
CYGPKG_IO_ETH_DRIVERS, is included in the configuration.
The AT91RM9200-EK/DK boards use the AT91RM9200's internal RTC support. The
CYGPKG_DEVICES_WALLCLOCK_ARM_AT91 package contains all the
code necessary to support this device. This driver is not active until the
generic wallclock device support package,
CYGPKG_IO_WALLCLOCK, is included in the configuration.
The AT91RM9200-EK/DK boards use the AT91RM9200's internal watchdog support. The
CYGPKG_DEVICES_WATCHDOG_ARM_AT91RM9200 package contains all the
code necessary to support this device. Within that package the
configuration option controls the watchdog timeout, and by default will
force a reset of the board upon timeout. This driver is not active until the
generic watchdog device support package,
CYGPKG_IO_WATCHDOG, is included in the configuration.
USART Serial Driver
The AT91RM9200-EK/DK boards use the AT91RM9200's internal USART serial support as described in the AT91RM9200 processor HAL documentation. Two serial ports are available: the serial debug port which is mapped to virtual vector channel 0 in the HAL diagnostic driver or "/dev/dbg" in the interrupt-driven driver; and USART 1 which is mapped to virtual vector channel 1 and "/dev/ser1". Only USART 1 supports modem control signals such as those used for hardware flow control.
As the AT91RM9200 MCI driver is part of the AT91RM9200 HAL, nothing is
required to load it. Similarly the MMC/SD bus driver layer
CYGPKG_DEVS_DISK_MMC) is automatically included as part
of the hardware-specific configuration for this target. All that is required
to enable the support is to include the generic disk I/O infrastructure
CYGPKG_IO_DISK), along with the intended
filesystem, typically, the FAT filesystem (
and any of its package dependencies (including
CYGPKG_LINUX_COMPAT for FAT).
Various options can be used to control specific of the AT91RM9200 MCI driver. Consult the AT91RM9200 HAL documentation for information on its configuration.
On this target, the MMC/SD socket allows detection of when cards are
inserted and removed. This may be used with the removeable media support and
disk insertion/removal event notification system in the disk I/O package so
that the application or other eCos subsystems are informed when cards are
inserted and removed. This in turn allows use of the automounter contained
within the File I/O package (
CYGPKG_FILEIO) to mount and
unmount cards automatically.
Remember that the ability to unmount cards after removal does not prevent
those cards containing corrupt filesystems - instead cards should be
preferably unmounted before removal, or at least have the filesystem's
in-memory buffers flushed to the media using the
The MMC/SD socket also allows detection of the write-protect (or "lock") switch present on SD cards. "Locked" cards will be detected and mounted read-only, and attempts to write to them will fail.
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 three 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=arm9is the correct option for the ARM920T CPU in the AT91RM9200.
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