SMP Support — Usage
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
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
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.
|2022-10-12||eCosPro Non-Commercial Public License|