eCos® and eCosPro® Reference Manual
Prev		Next

Configuration

Name

Configuration -- Platform-specific Configuration Options

Overview

The SD-L137 platform HAL package is loaded automatically when eCos is configured for the sd_l137 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 applications which will be programmed into flash, or which will be loaded and debugged via JTAG. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization.

Application binaries cannot just be programmed into flash. Instead it is necessary to incorporate them into a larger image file containing the AIS boot script for the primary bootloader as well as the secondary and tertiary bootloaders. The platform HAL's misc subdirectory contains a script gensdl137aisimg.tcl which can be used. Given an ELF executable test produced by the linker, the steps required are:

$ arm-eabi-objcopy -O binary test test.bin
$ tclsh <path>/misc/gensdl137aisimg.tcl test.bin test.img

The resulting image file can be programmed into flash instead of RedBoot. The build process for RedBoot will invoke these commands automatically to generate the redboot.img file.

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 board contains a 4 Mbyte 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 board. This driver is not active until the generic Flash support package, CYGPKG_IO_FLASH, is included in the configuration. The driver only supports 64K block erase operations, not the smaller 4K sector erase operations.

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 board uses the OMAP L137's internal EMAC ethernet device attached to an external Micrel KSZ8893 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 board. This driver is not active until the generic Ethernet support package, CYGPKG_IO_ETH_DRIVERS, is included in the configuration. The ethernet MAC address is held in the last 256-byte page of the serial EEPROM attached to the I2C0 bus.

RTC Driver

The board uses the OMAP L137'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 board uses the OMAP L137'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 board uses the OMAP L137's internal UART serial support as described in the OMAP L1xx processor HAL documentation. Only uart2 has a connector and only the tx and rx lines are connected, so hardware flow control and modem support signals are not available. The uart is normally used by RedBoot for communication with the host. If the device is needed by the application, either directly or via the serial driver, then it cannot be used for RedBoot communication and another channel such as ethernet should be used instead.

Device driver support is through the CYGPKG_IO_SERIAL_GENERIC_16X5X generic driver package which is modified by the CYGPKG_IO_SERIAL_ARM_OMAP_L1XX driver package for the OMAP L1xx. The packages are loaded automatically when configuring for the sd-l137 target but the option CYGPKG_IO_SERIAL_DEVICES has to be enabled to instantiate the device. The default device name is /dev/ser2.

I2C Bus Driver

The OMAP L1XX processor HAL contains a driver for the I2C two wire interface. This driver is loaded automatically when configuring for this target. The platform HAL enables bus 0 by default but leaves bus 1 disabled since there are no attached devices. This can be changed in the configuration if devices are attached via an expansion socket using option CYGHWR_HAL_ARM_SD_L137_I2C1. The bus names are hal_omap_l1xx_i2c_bus0 and hal_omap_l1xx_i2c_bus1.

The platform HAL also instantiates three I2C device objects: hal_i2c_eeprom for the serial EEPROM; hal_i2c_codec for the audio codec; and hal_i2c_eth_switch for the ethernet switch/phy. These devices can be accessed via the generic I2C API. The last 256-byte page of the eeprom is used to hold the ethernet MAC address but the remaining pages are available for use by the application. The ethernet switch is accessed only during ethernet driver initialization. The codec is not used by any eCos code.

The bus and device objects do not have to be enabled explicitly. If they are not used by the application, directly or indirectly, then they will be removed by link-time garbage collection.

SPI Bus Driver

The SPI buses are supported via the OMAP SPI driver CYGPKG_DEVS_SPI_ARM_OMAP. On this board only bus 0 is enabled by default since bus 1 does not ordinarily have any attached devices, but this can be changed via the configuration option CYGHWR_HAL_ARM_SD_L137_SPI1. Additionally, if CYGHWR_HAL_ARM_SD_L137_SPI_MMCSD is set, that will ensure the appropriate bus it is configured to use is enabled (see below). The bus names are cyg_spi_omap_bus0 and cyg_spi_omap_bus1 respectively. The platform HAL also provides an SPI device object cyg_m25pxx_spi_device for the serial flash. Normally this device is used only the flash device driver, not directly by the application.

The bus and device objects do not have to be enabled explicitly. If they are not used by the application, directly or indirectly, then they will be removed by link-time garbage collection.

MMC/SD cards over SPI

The HAL can be configured to support an MMC/SD card socket connected by SPI. Ensure CYGHWR_HAL_ARM_SD_L137_SPI_MMCSD is enabled to include this support, which it is by default if the disk driver package (CYGPKG_IO_DISK) is added to the eCos configuration.

An MMC/SD socket via SPI is not a standard feature of the Spectrum Digital OMAP-L137 platform, however it is possible to add one using a daughterboard connected via an expansion bus. As a result of this there are a number of associated configuration options as it could be connected in a variety of ways:

CYGHWR_HAL_ARM_SD_L137_SPI_MMCSD_BUS: This option selects which SPI bus number is connected to the socket. It has been observed that some MMC/SD cards do not behave correctly if a second SPI device is present on the same SPI bus, so it is not recommended to share the MMC/SD socket's SPI bus with any other device. Given the dataflash on the SPI0 bus, that would only leave SPI1, which is the default.
CYGHWR_HAL_ARM_SD_L137_SPI_MMCSD_CS: This component allows configuration of the chip select line used for communicating with the SPI-connected card. With this component enabled, this chip select line will be managed using GPIO. Alternatively, with this component disabled, the default chip select 0 will be used.
CYGHWR_HAL_ARM_SD_L137_SPI_MMCSD_CS_PINMUX_REG: This option configures the PINMUX register used for the chip select line used to communicate with the card. The SPI1 chip select 0 is multiplexed with a UART2 line, and since that is the UART used for HAL diagnostic output the default is instead to use GPIO3[10] (shared with the unused UART1_TXD). Its PINMUX function is set within PINMUX register 11, which is the default for this option. Consult the OMAP-L137 documentation for values for alternative pins.
CYGHWR_HAL_ARM_SD_L137_SPI_MMCSD_CS_PINMUX_FIELD: This option configures the field within the PINMUX register used for the chip select line used to communicate with the card. The value of this field is the amount of left bitshifting required in the register to correspond to the correct pin. SPI1 chip select 0 is multiplexed with a UART2 line, and since that is the UART used for HAL diagnostic output the default is instead to use GPIO3[10] (shared with the unused UART1_TXD). Its PINMUX function is set within PINMUX register 11 at bit position 12, which is the default for this option. Consult the OMAP-L137 documentation for values for alternative pins.
CYGHWR_HAL_ARM_SD_L137_SPI_MMCSD_CS_GPIO_BANK: This option configures the GPIO bank used for the chip select line used to communicate with the card. The SPI1 chip select 0 is multiplexed with a UART2 line, and since that is the UART used for HAL diagnostic output the default is instead to use GPIO3[10] (shared with the unused UART1_TXD), so bank 3 is the default for this option. Consult the OMAP-L137 documentation for values for alternative pins.
CYGHWR_HAL_ARM_SD_L137_SPI_MMCSD_CS_GPIO_BIT: This option configures the GPIO bit used for the chip select line used to communicate with the card. The SPI1 chip select 0 is multiplexed with a UART2 line, and since that is the UART used for HAL diagnostic output the default is instead to use GPIO3[10] (shared with the unused UART1_TXD), so bit 10 is the default for this option. Consult the OMAP-L137 documentation for values for alternative pins.

If using the default chip select via GPIO3[10], then you must ensure the SEL_EXP2_UART1 pin is set high. If you are using the Spectrum Digital prototype daughterboard, you can do this on SW2 by setting switch 4 to the ON position.

Similarly, if using the SPI1 bus, and expansion connector 2, then you must ensure the SEL_SPI1_EXP2_B pin is set high. If you are using the Spectrum Digital prototype daughterboard and have connected your card socket to J4, you can set SEL_SPI1_EXP2_B high by setting switch 3 of SW2 to the ON position.

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=arm9: 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=arm9 is the correct option for the ARM926EJ 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.

Prev	Home	Next
Setup	Up	JTAG debugging support

Documentation license for this page: eCosPro License

Privacy & Legal Statements