Configuration

Configuration
	Chapter 275. Altera Cyclone V SX Board Support

Overview

The Cyclone V SX platform HAL package is loaded automatically when eCos is configured for the cyclone5-sx 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 four 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 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.
SRAM: This startup type can be used for finished applications that are to be loaded into the on-chip SRAM. 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.
SMP: This startup type can be used for finished applications that can be loaded into RAM via RedBoot. The load address is set to the same as for RAM applications, however, the application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization. Once started, this application takes full control of the system and RedBoot will not be called again. This means that debugging via RedBoot will not be possible, only JTAG-based hardware debugging is supported. The intent of this startup type is to allow SMP test programs to be run from RedBoot, most SMP applications should use the ROM startup type. This startup type can also be used for applications loaded directly 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 Cyclone V SX board contains an 128Mbyte Micron N25Q00AA SPI serial NOR flash device attached to the QSPI controller. 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 Cyclone V SX. 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 board uses the HPS's internal GMAC Ethernet device attached to an external Micrel KSZ9021 Gigabit PHY. The CYGPKG_DEVS_ETH_DWC_GMAC package contains all the code necessary to support this device and the CYGPKG_DEVS_ETH_CYCLONE5_SX 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.

Support for PHY events is made available by default when the Kernel (CYGPKG_KERNEL) is available in a configuration.

RTC Driver

The Cyclone V SX board has a Maxim DS1339C I²C based RTC chip installed. For the functionality used by eCos, this device is compatible with the DS1307. Therefore, the CYGPKG_DEVICES_WALLCLOCK_DALLAS_DS1307 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 and I²C support is enabled.

Watchdog Driver

The board uses the HPS's internal watchdog support. The CYGPKG_DEVICES_WATCHDOG_DWWDT package contains all the code necessary to support this device. Within that package the CYGNUM_DEVS_WATCHDOG_DWWDT_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 HPS's internal UART serial support as described in the HPS processor HAL documentation. Only one serial connector is available on the board, which is connected to UART0 via a USB bridge. Only the UART data lines are connected to the bridge, so hardware flow control is not supported.

MMC/SD Driver

As the Cyclone V SX MMC/SD driver is part of the HPS processor 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 (e.g. for FAT also including CYGPKG_LIBC_STRING and CYGPKG_LINUX_COMPAT packages).

Various options can be used to control specifics of the MMC/SD driver. Consult the HPS processor HAL documentation for information on its configuration.

This board does not have a working MMC/SD card detect for MicroSD socket (J3), thus the disk I/O layer's removeable media support is not available.

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. The following flags are specific to this port:

-mcpu=cortex-a9: 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=cortex-a9 is the correct option for the CPU in the HPS.
-mthumb: The arm-eabi-gcc compiler will compile C and C++ files into the Thumb2 instruction set when this option is used. The best way to build eCos in Thumb mode is to enable the configuration option CYGHWR_THUMB.
-mno-unaligned-access: The Cortex-A CPU allows unaligned memory accesses and the default for arm-eabi-gcc is to generate instructions that make unaligned accesses. However, for this port, alignment exceptions are enabled, so unaligned accesses should not be made. This option disables unaligned accesses. Note that there is a performance and code size cost in doing this, since all accesses to unaligned data must now be made using individual byte accesses.


Setup		SMP Development and Debugging Support

Name