Configuration — Platform-specific Configuration Options
The BCM56150 Reference platform HAL package is loaded automatically when
eCos is configured for the
bcm56150-ref 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.
The platform HAL package supports four separate startup types:
- 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 via the serial line 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.
- 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. The application starts execution from flash, but relocates itself to RAM during initialization.
- 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. The application executes from flash. However, since the SPI flash is very slow, it is not recommended for production applications. It is mainly useful for debugging application startup code via a JTAG debugger.
- This startup type can be used for finished applications that are to be loaded into RAM via a JTAG debugger. Since DRAM needs to be initialized before loading a JTAG application, it is necessary to allow RedBoot to start and run from flash. After this the JTAG probe may be connected and the application loaded. Once running the application will be self-contained with no dependencies on services provided by other software.
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
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.
The BCM56150 Reference board contains an 32Mbyte Micron N25Q256
SPI serial NOR flash device attached to the QSPI controller. The
CYGPKG_DEVS_FLASH_QSPI_IPROC packages contains
all the code necessary to support this part and the platform HAL
package contains definitions that customize the driver to the
BCM56150 Reference board. This driver is not active until the
generic Flash support package,
CYGPKG_IO_FLASH, is included in the
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
CYGPKG_LINUX_COMPAT) together with the flash
UART Serial Driver
The board uses the IProc's internal UART serial support as described in the IProc processor HAL documentation. Only one serial connector is available on the board, which is connected to UART1 via the J1801 connector. An adaptor cable is needed to connect to a standard 9-pin serial connector.
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:
The arm-eabi-gcc compiler supports
many variants of the ARM architecture. A
-moption should be used to select the specific variant in use, and with current tools
-mcpu=cortex-a9is the correct option for the CPU in the IProc.
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
- 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.
- For ROMRAM startup, some code is executed from flash before code is relocated to RAM. As a result, any code or constant data references will use the wrong address. To prevent switch statements using tables at the wrong location, this option is enabled for ROMRAM startup builds.
|2019-03-19||eCosPro Non-Commercial Public License|