Configuration

Configuration
	Chapter 288. Xvisor Virtual Machine Support

Overview

The xvisor platform HAL package is loaded automatically when eCos is configured for the xvisor 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 2MiB free for RedBoot's use.

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 uses RAM starting from 0x40000020. Interrupt and exception vectors are placed at 0x40000000 with the virtual vectors following.

SMP

This startup type can be used for finished applications that can be loaded into RAM via RedBoot. 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. The intent of this startup type is to allow SMP test programs to be run from RedBoot.

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. Both of these will typically be routed by the hypervisor to either a real external device or a serial interface of another VM.

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 accessed 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: The Xvisor virtual machine configures a generic ARMv7a CPU. This option selects a suitable Cortex-A CPU variant that will support the execution of Aarch32 code.


Setup		SMP Development and Debugging Support

Name