Configuration

Name

Configuration -- Platform-specific Configuration Options

Overview

The AT91SAM9G20-EK platform HAL package is loaded automatically when eCos is configured for the sam9g20ek 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 DataFlash. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization.

JTAG

This is the startup type which can be used during application development via a JTAG device such as the PEEDI. arm-eabi-gdb is used to load a JTAG startup application into memory and debug it. Hardware setup is divided between the initialization section of the PEEDI configuration file and software in the loaded application.

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 AT91SAM9G20-EK board contains an 8Mbyte Atmel AT45DB DataFlash device. The CYGPKG_DEVS_FLASH_ATMEL_DATAFLASH package contains all the code necessary to support this part and the platform HAL package contains definitions that customize the driver to the AT91SAM9G20-EK board. This driver is not active until the generic Flash support package, CYGPKG_IO_FLASH, is included in the configuration.

Ethernet Driver

The AT91SAM9G20-EK board uses the AT91SAM9G20's internal EMAC ethernet device attached to an external Davicom DM9161A PHY. The CYGPKG_DEVS_ETH_ARM_AT91 package contains all the code necessary to support this device and the platform HAL package contains definitions that customize the driver to the AT91SAM9G20-EK board. This driver is not active until the generic Ethernet support package, CYGPKG_IO_ETH_DRIVERS, is included in the configuration.

RTC Driver

The AT91SAM9G20-EK board uses the AT91SAM9G20's internal RTTC support. The CYGPKG_DEVICES_WALLCLOCK_ARM_AT91RTTC 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 AT91SAM9G20-EK board uses the AT91SAM9G20's internal watchdog support. The CYGPKG_DEVICES_WATCHDOG_ARM_AT91WDTC package contains all the code necessary to support this device. Within that package the CYGNUM_DEVS_WATCHDOG_ARM_AT91WDTC_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.

Warning

The ATSAM926x processor will boot with watchdog support enabled, and the watchdog configuration is write-once. That is, if it is disabled, it cannot be re-enabled. Due to its nature, RedBoot disables the watchdog when it starts so any eCos applications with watchdog support enabled that are run by RedBoot will not function correctly.

USART Serial Driver

The AT91SAM9G20-EK board uses the AT91SAM9G20's internal USART serial support as described in the SAM9 processor HAL documentation. Three 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; USART 0 which is mapped to virtual vector channel 1 and "/dev/ser0"; and USART 1 which is mapped to virtual vector channel 2 and "/dev/ser1". Only USART 0 supports full modem control signals but USART 1 supports RTS/CTS.

MCI Driver

As the SAM9 MCI driver is part of the SAM9 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 specific of the SAM9 MCI driver. Consult the SAM9 HAL documentation for information on its configuration.

On this target, it is not possible to detect from the MMC/SD socket whether cards have been inserted or removed. Thus the disk I/O layer's removeable media support will not detect when cards have been inserted or removed, and therefore the only way to detect if a card has been inserted is to attempt mounts.

The MMC/SD socket also does not permit detection of the write-protect (or "lock") switch present on SD cards. "Locked" cards will therefore not be detected which means that despite the switch position, it is still possible to write to them since the lock switch does not physically enforce write protection.

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 AT91SAM9G20.

-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.

Onboard NAND

The HAL port includes a low-level driver to access the on-board Samsung K9F2G08U08 NAND flash memory chip. To enable the driver, activate the CDL option CYGPKG_HAL_SAM9G20EK_NAND and ensure that the CYGPKG_DEVS_NAND_SAMSUNG_K9 package is present in your eCos configuration.

CYGHWR_HAL_SAM9G20EK_NAND_USE_STATUS_LINE

If set, this option configures the driver to wait for NAND operations to complete by waiting for the chip to deassert its Busy line. This is the default behaviour and is recommended, but may be disabled if you need to use the line (PIO C13) for some other purpose. (If disabled, the memory controller is configured to stall NAND accesses until they complete, which will interfere with multi-threading.)

CYGNUM_HAL_SAM9G20EK_NAND_POLL_INTERVAL

The number of microseconds delay in the polling loops which wait for NAND operations to complete.

Partitioning the NAND chip

The NAND chip must be partitioned before it can become available to applications.

A CDL script which allows the chip to be manually partitioned is provided (see CYGSEM_DEVS_NAND_SAM9G20EK_PARTITION_MANUAL_CONFIG); if you choose to use this, the relevant data structures will automatically be set up for you when the device is initialised. By default, the manual config CDL script sets up a single partition (number 0) encompassing the entire device.

It is possible to configure the partitions in some other way, should it be appropriate for your setup, for example to read a Linux-style partition table from the chip. To do so you will have to add appropriate code to sam9g20ek_nand.c.

2017-02-09
Documentation license for this page: eCosPro License