Configuration — Platform-specific Configuration Options
The Virtual Machine platform HAL package is loaded automatically when eCos is configured for any virtual 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 two 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 is also used to for applications that are loaded from the RedBoot command line with the load command.
In Xvisor VMs RAM applications are loaded at address 0x40200000, leaving the bottom 2MB free for RedBoot's use.
In QEMU VMs RAM applications are loaded at address 0x40500000, leaving the bottom 5Mb free for RedBoot.
This startup type can be used for finished applications which will be booted direct into the VM from the hypervisor. The application will be self-contained with no dependencies on services provided by other software. eCos startup code will perform all necessary hardware initialization.
In Xvisor VMs ROM application are loaded by the hypervisor at address 0x00000000 in the emulated flash memory. RedBoot used RAM starting from 0x40000020. Interrupt and exception vectors are placed at 0x40000000 with the virtual vectors following.
In QEMU VMs ROM applications are loaded by QEMU at 0x40010000 in main RAM. The bottom 4MB are treated as a read-only area. ROM applications will place exception vectors, DATA and BSS starting from 0x40400000.
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
There are two serial devices supported for the VM. The ARM PL011 macrocell is supported by a serial driver and as a command line input for RedBoot. The VirtIO console driver is similarly supported by a driver and as a RedBoot input; it is dependent on the VIRTIO driver and can only be configured if VIRTIO driver is also present. In Xvisor both of these will typically be routed by the hypervisor to either a real external device or a serial interface of another VM. In QEMU these serial interfaces may be routed to a variety of host devices including stdio, TCP streams or pseudo-terminals.
SPI1 is supported by the
CYGPKG_DEVS_SPI_ARM_ROCKCHIP package. By default
the MISO, MOSI and SCLK signals use the default pins for the
device. The chip select signals are connected to GPIO lines
vial the virtual GPIO controller. 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. This device is only available to virtual machines
running under Xvisor on a Rockchip based host since it
accesses the hardware directly using device passthrough.
Support for the VirtIO NET device is provided by
CYGPKG_DEVS_ETH_VIRTUAL driver. This
driver is dependent on the VIRTIO driver and can only be
configured if the VIRTIO driver is also present. This driver is
also not active until the generic Ethernet support package,
CYGPKG_IO_ETH_DRIVERS, is included in the
Support for a VirtIO RPMSG interface is present in package
driver is dependent on the VIRTIO driver and can only be
configured if the VIRTIO driver is also present.
The RPMSG driver is accessed via the RPMSG API library, details of which may be found here.
Support for generic VirtIO devices is provided by the VIRTIO
provides the generic initialization and management of queues
common to all VirtIO devices.
The VirtIO driver is not normally access directly from application, but only from client device drivers. For reference, details of the VirtIO driver may be found here.
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:
- In most hypervisors eCos runs under a generic Aarch32 Version 7 architecture implementation. This option selects a suitable Cortex-A CPU variant that will support the execution of Aarch32 code under many different hypervisors.
ptSwitch Parameter Structure
Runtime configuration of applications is handled through a
ptsw_param structure. This is placed at
VM physical address 0x38000000 and occupies up to 4KB. This
structure contains fields to allocate timers, RPMSG node
addresses and IPv4 addresses. The layout and usage of this
structure is described in the
cyg/hal/ptsw_param.h header. At system
startup this structure is copied into
hal_ptsw_param, where it can be accessed
by system and application code. Timer mappings are set up by
the HAL, and applications may fetch the RPMSG node address
for a given device by calling
|2020-06-15||eCosPro Non-Commercial Public License|