Configuration — Platform-specific Configuration Options
The Raspberry Pi platform HAL package is loaded automatically when eCos is configured for any RPi 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 startup type is normally used during application development when using the RedBoot ROM monitor. arm-eabi-gdb is used to load the 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.
- This startup type can be used for finished applications which will be booted direct from the SD card. 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 for testing prior to committing to an SD card.
- This startup type can be used for finished applications that are to be loaded by a JTAG debugger. 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.
- This startup type can be used for finished applications that can be loaded into RAM via RedBoot or via a JTAG debugger. 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.
The main difference between ROM, JTAG and SMP startup types is the address at which they are loaded. ROM applications load at 0x00008000, which is the default address used by the GPU boot loader. JTAG applications load at 0x00100000, leaving the lower 1MiB free for a ROM RedBoot. This is necessary because in multi-core systems, the secondary cores will be looping in code in the RedBoot executable, and we don't want to overwrite that, since it may cause these cores to run wild. SMP applications load at 0x00200000, leaving the lower 2MiB free. This allows either a ROM or JTAG RedBoot to be used to load it without affecting the secondary cores. For the same reasons, RAM applications also load at the 0x00200000 boundary.
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.
UART Serial Driver
The auxiliary mini UART is 16550 compatible and is supported
generic driver package which is modified by the
CYGPKG_IO_SERIAL_ARM_BCM283X driver package
for the Raspberry Pi family. By default the UART used only
the TXD0 and RXD0 pins connected to GPIO14 and GPIO15 on the
GPIO header. While RTS and CTS could be made available on
GPIO16 and GPIO17, this is not currently supported since
these pins are better left for other purposes. The mini UART
is also lacking some 16550 functionality, it is only capable
of 7 or 8 bit characters, and only supports one stop bit and
no parity; attempts to select other settings will be
accepted, but will have no effect. Since the TXD0 and RXD0
pins are not at RS232 levels it is necessary to either
connect an RS232 transceiver to them or, more usually, an
FTDI USB serial convertor module.
SPI0 is supported by the
CYGPKG_DEVS_SPI_ARM_BCM283X. The auxiliary SPI1
and SPI2 devices are not currently supported. By default the
MISO, MOSI and SCLK signals are connected to GPIO9, GPIO10
and GPIO11 respectively. The chip select signals are
connected to GPIO7 and GPIO8. These pins are managed in GPIO
mode, so it is possible to add extra SPI devices by
assigning additional GPIO pins to act as chip select lines.
I2C1 is supported by the
CYGPKG_DEVS_I2C_BSC driver. The SDA1 and
SCL1 signals are connected to GPIO2 and GPIO3 pins. I2C0 is
used by the GPU to operate the ID_SD and ID_SC pins as well
as the GPIO extender in the Compute Modules; I2C2 is
dedicated to the HDMI interface; so neither of these is
available for use.
PWM is supported by the
CYGPKG_DEVS_PWM_BCM driver. The PWM
device supports two channels connected to four pins
available on the GPIO header. Channel 0 is connected to
GPIO12 and GPIO18, pins 12 and 32 on the GPIO
header. Channel 1 is connected to GPIO13 and GPIO19, pins 33
and 35 on the GPIO header. Note that some of these may clash
with other uses of the same pins, particularly GPIO19 which
is also SPI MISO.
USB is supported by the
package USB protocol stack
together with the
controller driver. The stack will recognize and support the USB hub
component of the LAN951X/LAN7515 when it is available on the board,
together with any hubs that might be plugged in to that. The
stack currently only supports CONTROL and BULK transfer
types, INTERRUPT and ISOCHRONOUS transfers are not
supported. The host controller driver currently supports
High, Fast and Low speed devices. USB support is currently
oriented towards supporting USB mass
serial devices including
and FTDI serial adaptors,
and the LAN951X/LAN7515 Ethernet component.
Support for the LAN951X/LAN7515 Ethernet component is provided by
CYGPKG_DEVS_ETH_LAN951X driver. This
driver is dependent on the USB stack and can only be
configured if the USB stack is also present. This driver is
also not active until the generic Ethernet support package,
CYGPKG_IO_ETH_DRIVERS, is included in the
controls whether the Ethernet driver uses the Raspberry Pi
board type to decide whether the board contains an Ethernet
device. If it does not, then initialization of the driver
and the entire network stack is prevented, saving startup
time. This option can be misled if, for example, a Compute
Module is plugged in to a carrier board that has a
LAN951X/LAN7515 installed. So by default the option is only
enabled for RedBoot builds, and not for eCos builds, where
the user is expected to know what they are doing. If the
default is not as reqired, it can be changed in the ConfigTool.
Support for the SD/MMC socket is provided by the
CYGPKG_DEVS_MMCSD_SDHOST driver. This
uses the Broadcom SDHOST controller; the Arasan SDHCI
controller is not currently supported, although in future it
will be used for the CYW43438 WiFi device on the Pi3 and
CM3. On the compute modules, this same driver provides
access to the eMMC device.
The MMC/SD bus driver layer
CYGPKG_DEVS_DISK_MMC) is automatically
included as part of the hardware-specific configuration for
these targets. All that is required to enable MMC/SD 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
CYGPKG_LINUX_COMPAT for FAT).
While earlier variants of the Raspberry Pi had a card detect signal from the SD card socket attached to a GPIO line, this has been dropped in later variants. It also makes no sense for the permanently connected eMMC devices on the compute modules. Therefore, card detection is not currently supported on any RPi boards, so the disk IO layer's removable media support cannot detect card insertion or removal, and the FILEIO layer's automounter cannot currently be used.
GPIO support is provided by the BCM283X variant HAL , and is documented there. The GPIO API is built around descriptors that encode a GPIO pin number together with its function (IN, OUT or device function) and mode into a single 32 bit value. The mode includes edge and level interrupt recognition and pull up and down settings. The eCosPro subsystem also decoded all GPIO interrupts into separate vectors.
eCos does not contain any support for dynamic frequency
management in the same way that Linux does. The CPUs run at
a single frequency throughout. Normally this is the maximum
frequency permitted without overclocking. A different
frequency may be selected in the configuration, or it may be
set at runtime by calling
hal_bcm283x_set_freqencies(). See the BCM283X HAL for
defines the frequency in MHz at which the ARM CPU will
run. For RAM startup types, the default value of zero will
cause the application to continue using the frequency set up
by RedBoot. For other startup types, a value of zero will
cause the HAL to select a default frequency based on the
board type. A non zero value will force the CPU frequency to
the given value.
defines the frequency in MHz at which the GPU will run. For
RAM startup types, the default value of zero will cause the
application to continue using the frequency set up by
RedBoot. For other startup types, a value of zero will cause
the HAL to select a default frequency based on the board
type. A non zero value will force the CPU frequency to the
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. For the BCM2835 variants that contain a single ARM11 CPU, (Pi0, Pi1, CM1), this option should be selected.
- For the BCM2836, containing 4 Cortex-A7 CPUs and the BCM2837, containing four Cortex-A53 CPUs, this option should be selected. While the Cortex-A53 is strictly a ARM64 CPU, we can only use it in ARM32 mode, where it supports the same instruction set as the Cortex-A7. So, for simplicity we use the same option for both.
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
|2019-09-17||eCosPro Non-Commercial Public License|