Configuration — Platform-specific configuration options
The SAMA5D3 Xplained platform HAL package is loaded automatically when
eCos is configured for a suitable target,
atsama5d3xpld. 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 SAMA5D3-XPLD board platform HAL package supports three separate
startup types, as documented in the
ROM startup type
is not supported on this platform since the BMS
signal configuration does not allow for
memory-mapped execution support.
Normally the board has BootUp or AT91Bootstrap programmed into
internal NAND flash within the first two non-factory-bad blocks. When
using RedBoot as the loaded application then
If the application is intended to act as a ROM monitor, providing
services for other applications, then the configuration
CYGSEM_HAL_ROM_MONITOR should be
set. Typically this option is set only when building the GDB stub ROM
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 diagnostic output.
UART Serial Driver
The SAMA5D3-XPLD board provides a two-pin UART within the on-chip debug unit. This UART is configured as virtual vector communications channel 0 and is typically claimed by RedBoot for use as a console and/or GDB communication.
If this UART is needed by the application, either directly or via the serial driver, then it cannot also be used for GDB communication using the HAL I/O support.
The UART manifests on the board as the TTL-level TXD and RXD pins on J23. Hardware flow control (RTS/CTS) is not supported.
An SPI bus driver is available for the SAMA5D3 in the package "Atmel
AT91 SPI device driver"
There are no on-board SPI devices, so no SPI devices are instantiated by default.
Consult the generic SPI driver API documentation in the eCosPro Reference Manual for further details on SPI support in eCosPro, along with the configuration options in the AT91 SPI device driver.
Support for SAM I²C (TWI) busses is provided by the "Atmel
TWI (I2C) device driver" package
CYGPKG_DEVS_I2C_ATMEL_TWI). The SAM variant
HAL causes the two buses to be instantiated. These have been
tested using external I²C devices.
The HAL port includes a low-level driver to access the on-board Micron MT29F2G08 NAND flash memory chip. To enable the driver, add the CYGPKG_IO_NAND package to your eCos configuration.
If using the NAND library direct, see also the NAND port implementation details.
The onboard NAND chip is usually the boot device on this board.
Before writing to the NAND device from an application, be sure you understand the partition scheme in use and how it relates to the system bootstrap code. Failure to do so risks overwriting the second stage boot loader and/or RedBoot, leaving your board unbootable until you reprogram it.
There are several ways to partition the NAND chip.
The eCos configuration setting
specifies which one to use.
The default NAND configuration, which eCosCentric recommend for development,
Config_store" which uses the eCos on-NAND partition
eCos on-NAND partition table
The eCos native partition scheme ("
Config_store") for this
board has the following contents:
The first 6 non-factory-bad blocks (384k) are reserved for the system bootstrap,
and normally contain AT91Bootstrap or BootUp, followed by RedBoot (or an application
running in place of it). This number appears in the eCos configuration as
NAND partition 0 comprises the next 10 blocks.
This is used for the NAND configuration store which records the geometry of
the remaining NAND partitions and hosts the RedBoot flash config area.
The size of the configuration store may be reconfigured as
The remainder of the chip, and the remainder of the partition slots, are
available for arbitrary partitioning and use by applications, with their
geometry stored dynamically in the configuration store (see below). It is
automatically set up as a single partition, numbered 1; up to three partitions
are available in a default configuration, but moremay be provisioned if
required by reconfiguring
If you change
The geometry of the remaining partitions is stored as
integer entries in the config store, with config store keys named
and so on.
These may be changed from within RedBoot using the
nand infoNAND device `onboard': 2048 bytes/page, 64 pages/block, capacity 2048 blocks x 128 kB = 256 MB Partition Start Blocks 0 6 10 1 16 2036 RedBoot>
nconfig put nand.partition1.size uint 200Written OK RedBoot>
nconfig put nand.partition2.base uint 216Written OK RedBoot>
nconfig put nand.partition2.size uint 1836Written OK RedBoot>
reset... Resetting. RomBOOT . . . full boot-up messages omitted for brevity . . . +NAND: onboard: 1 partition configured NAND: Read partition geometry from config store NAND: onboard: 3 partitions configured . . . full boot-up messages omitted for brevity . . . NAND: onboard RedBoot>
nand infoNAND device `onboard': 2048 bytes/page, 64 pages/block, capacity 2048 blocks x 128 kB = 256 MB Partition Start Blocks 0 6 10 1 16 200 2 216 1836 RedBoot>
Applications may change these via the config store call
cyg_configstore_write_int; refer to
the configuration store documentation for details.
After changing the partition geometry in the config store, it is necessary to reset the board for the changes to take effect - hence the reset command above.
When changing partition geometry, eCos makes no attempt to preserve
any data on the affected partition(s); it is up to you to arrange this
if it is important to you.
If you do not need to keep the data, consider erasing the affected
partition(s) before editing them. RedBoot provides a
A CDL script which allows the chip to be manually partitioned is provided (see
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 does not set up any partitions.
The configuration store always uses partition 0 on this board. If you wish to use the configuration store (such as in RedBoot) you must leave a suitable space for it. Do not write any other data to partition 0; it is automatically managed by the config store and will likely be erased.
The manual partitioning scheme does NOT take account of the space required for system bootstrap. If you choose this option, be sure to allow sufficient space for these in your partition layout.
Other partitioning schemes
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
sama5d3xpld_nand.c, and a
new option to
The SAMA5D3-XPLD board uses the SAMA5D3's internal EMAC and GMAC Ethernet
devices attached to external Micrel KSZ8081RNB and KSZ9031RN PHYs
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
board. This driver is not active until the generic Ethernet
included in the configuration.
Both the standard and direct (lwIP only) device drivers are
supported. The standard driver is enabled by default; the direct
driver can be enabled by setting
option. At the time of writing, the direct driver only supports
the EMAC (ETH1), and not the GMAC (ETH0).
|2019-09-17||eCosPro Non-Commercial Public License|