Name

Configuration — Platform-specific Configuration Options

Overview

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.

Startup

The platform HAL package supports two separate startup types:

RAM

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.

ROM

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 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.

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.

SPI Driver

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.

Ethernet Driver

Support for the VirtIO NET device is provided by the 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 configuration.

RPMSG Driver

Support for a VirtIO RPMSG interface is present in package CYGPKG_DEVS_RPMSG_VIRTUAL. This 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.

VirtIO Driver

Support for generic VirtIO devices is provided by the VIRTIO driver (CYGPKG_DEVS_VIRTIO). This 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.

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-a15
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 ptsw_rpmsg_ept(dev).