Name
Configuration — Platform-specific Configuration Options
Overview
The Zoom L138 platform HAL package is loaded automatically when
eCos is configured for the zoom-l138
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.
Startup
The platform HAL package supports two 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 the 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. 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 also be used for applications loaded via JTAG.
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 Zoom board contains an 8Mbyte Numonyx M25P64 SPI serial
NOR flash device. The
CYGPKG_DEVS_FLASH_SPI_M25PXX
package contains
all the code necessary to support this part and the platform HAL
package contains definitions that customize the driver to the
Zoom L138 board. This driver is not active until the generic
Flash support package, CYGPKG_IO_FLASH
, is
included in the configuration.
This driver is capable of supporting the JFFS2
filesystem. However, note that the SPI interface means that this
file system has reduced bandwidth and increased latency compared
with other implementations. All that is required to enable the
support is to include the filesystem
(CYGPKG_FS_JFFS2
) and any of its package
dependencies (including CYGPKG_IO_FILEIO
and
CYGPKG_LINUX_COMPAT
) together with the flash
infrastructure (CYGPKG_IO_FLASH
).
Ethernet Driver
The Zoom L138 board uses the OMAP L138's internal EMAC ethernet
device attached to an external SMSC LAN8710A PHY. The
CYGPKG_DEVS_ETH_ARM_OMAP
package contains all the
code necessary to support this device and the platform HAL package
contains definitions that customize the driver to the ZOOM L138
board. This driver is not active until the generic Ethernet support
package, CYGPKG_IO_ETH_DRIVERS
, is included in
the configuration.
RTC Driver
The ZOOM L138 board uses the OMAP L138's internal RTC support. The
CYGPKG_DEVICES_WALLCLOCK_ARM_OMAP_L1XX
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.
Watchdog Driver
The Zoom L138 board uses the OMAP L138's internal watchdog
support. The
CYGPKG_DEVICES_WATCHDOG_ARM_OMAP_L1XX
package
contains all the code necessary to support this device. Within
that package the
CYGNUM_DEVS_WATCHDOG_ARM_OMAP_L1XX_DESIRED_TIMEOUT_MS
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.
UART Serial Driver
The Zoom L138 board uses the OMAP L138's internal UART serial support as described in the OMAP L1xx processor HAL documentation. Only one serial connector is available on the board, which is connected to UART2. This connector has the RTS/CTS hardware flow control lines connected in addition to the data lines.
MMC/SD Driver
As the OMAP L1xx MMC/SD driver is part of the OMAP L1xx 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 package
(CYGPKG_IO_DISK
), along with the intended
filesystem, typically, the FAT filesystem
(CYGPKG_FS_FAT
) and any of its package
dependencies (including CYGPKG_LIBC_STRING
and
CYGPKG_LINUX_COMPAT
for FAT).
Various options can be used to control specifics of the MMC/SD driver. Consult the OMAP L1xx HAL documentation for information on its configuration.
This board has the MMC/SD socket's card detect and write protect lines connected to GPIO lines. The card detect line is additionally monitored by an interrupt handler. Thus the disk I/O layer's removeable media support will detect when cards have been inserted or removed, and the FILEIO layer's automounter can be used.
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 three flags specific to this port:
-
-mcpu=arm926ej-s
-
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=arm926ej-s
is the correct option for the ARM926EJ-S CPU in the OMAP L1xx. -
-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
.
2024-03-18 | eCosPro Non-Commercial Public License |