Configuration

Configuration
	Chapter 283. QEMU Virtual Machine Support

Overview

The QEMU platform HAL package is loaded automatically when eCos is configured for a QEMU 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 three 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 QEMU VMs RAM applications are loaded at address 0x40500000, leaving the bottom 5MiB 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 QEMU VMs ROM applications are loaded by QEMU at 0x40010000 in main RAM. The bottom 4MiB are treated as a read-only area. ROM applications will place exception vectors, DATA and BSS starting from 0x40400000.

SMP

This startup type can be used for finished applications that can be loaded into RAM via RedBoot or from the QEMU command line. 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 external debugging via QEMU's debug port is supported.

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 QEMU these serial interfaces may be routed to a variety of host devices including stdio, TCP streams or pseudo-terminals.

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 QEMU virt target contains a Cortex-A15 CPU emulation.


Setup		SMP Development and Debugging Support

Name