Overview

Support is available for SMP operation. However, debugging support is restricted to using an external SMP-aware debugger connected to QEMU's GDB stub port. RedBoot does not have support for multi-core debugging.

SMP support is enabled by setting CYGPKG_KERNEL_SMP_SUPPORT to true. SMP applications should only be built using either ROM or SMP startup types. ROM applications can be loaded from the QEMU command line in place of RedBoot. The SMP startup is identical to a ROM startup except that the load address is set to allow the application to be loaded into a higher location in RAM from RedBoot. SMP startup applications can also be loaded from the command line if the ELF file is used, a binary file will not work.

By default eCos is configured to use four CPUs. However, QEMU can support up to eight CPUs and the ecos_qemu script instantiates all eight. CPUs are only enabled when eCos starts, so unused CPUs will not consume host cycles. The number of CPUs may be changed by setting CYGNUM_HAL_ARM_CORTEXA_VIRTUAL_CPU_COUNT.

Loading an SMP startup application via RedBoot can be done from the RedBoot command line via serial. It may also be loaded via a GDB connection on serial. However, once started running the SMP application will take full control of the system, including redirecting all interrupt sources, exception vectors and virtual vector table entries. This means that RedBoot will no longer be active. Any breakpoints planted by GDB will result in an exception to the application, Ctrl-C will not work, any Ethernet connections will be lost and serial output will come from the application in plain ASCII. Any GDB connection will be lost and GDB may start reporting packet errors.

It is possible to load an SMP startup program via GDB and have its output displayed on the GDB console. To do this set CYGSEM_HAL_DIAG_MANGLER to "GDB", and CYGDBG_HAL_DIAG_TO_DEBUG_CHAN to 1. The application will still not be controllable from GDB, but this does simplify the running of test code; avoiding the need to disconnect GDB and connect a terminal emulator to capture or view the output.

SMP applications may be debugged via the QEMU GDB debug port using a standard GDB. In this case the different CPUs are presented to GDB as separate threads. The command info threads can be used to list the CPUs and the thread command can be used to switch between them. eCos threads are not visible in this mode.

QEMU runs each virtual CPU in a separate thread. These in turn can be scheduled onto separate CPUs of the host system. As a result the virtual machine CPUs are subject to the scheduling decisions of the host. If the host is a typically-idle development workstation then this should not pose a problem. However, if the host is busy, a server or shared system, then the other workloads may affect the relative progress of the various virtual CPUs. If the eCos application makes strict use of synchronization primitives then there should be no problem. However, if it assumes that the CPUs all progress a the same rate, then it may see some issues. These issues can partly be alleviated by running QEMU at a higher priority, or on reserved CPUs.