Overview

Support is available for SMP operation. However, debugging support is restricted to using diag_printf() and related functions. RedBoot does not have support for multi-core debugging and Xvisor has no support for connecting a debugger to a virtual machine.

A board intended to be used for SMP development should be initialized in the same way as a single core board. RedBoot only uses a single CPU. The device tree for the VM should be defined with four CPUs. The example device tree files described in the Setup section show how this is done.

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

By default eCos is configured to use four CPUs. Xvisor can support up to eight CPUs. The example device tree currently only defines four CPUs. Extra CPUs may be added by editing this file. The number of CPUs supported by eCos may be changed by setting CYGNUM_HAL_ARM_CORTEXA_VIRTUAL_CPU_COUNT. The number of CPUs supported by eCos should never exceed the number configured in the device tree.

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