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.

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.

SMP Support

SMP support is limited to a maximum of eight CPUs by the design of the ARM GIC. The exact number of CPUs that eCos supports is defined by the CYGNUM_HAL_ARM_CORTEXA_VIRTUAL_CPU_COUNT configuration option. The default value for this option is four, but each hypervisor package may set this to a value that corresponds to the number of CPUs configured by the hypervisor. It may also be changed by the user within certain constraints.

eCos does not handle dynamic configuration of CPUs and cannot detect the number of CPUs present at startup. So the value specified for CYGNUM_HAL_ARM_CORTEXA_VIRTUAL_CPU_COUNT should never exceed the number of CPUs configured by the hypervisor. It should be possible to run eCos with fewer CPUs than the hypervisor configures, since any extra CPUs will not be started. However, this is hypervisor dependent, see the documentation on each hypervisor for details.

UART Serial Driver

There are two common 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.

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 applications, but only from client device drivers. For reference, details of the VirtIO driver may be found here.