SMP Development and Debugging Support
Prev Chapter 279. Altera Cyclone V SX Board Support Next

Name

SMP Support — Usage

Overview

Support is available for SMP operation of the two CPUs on this platform. However, debugging support is restricted to using an external SMP-aware JTAG debugger like ARM's DS-5 or a Lauterbach Power Debug probe. RedBoot does not have support for multi-core debugging.

A board intended to be used for SMP operation should be initialized in the same way as a single core board by installing the preloader and RedBoot. If RedBoot is not needed then the preloader must still be installed and a ROM startup application, with headers added by flashimg_cv, can be written to flash in place of RedBoot.

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 by the pre-loader 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. Both application types may also be loaded via a JTAG debugger.

Loading an SMP startup application via RedBoot can be done from the RedBoot command line via serial or Ethernet. It may also be loaded via a GDB connection on serial or Ethernet. 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.

JTAG support has been tested using the ARM DS-5 debugger and the Lauterbach Trace32 debugger. Most of our SMP development has been done using Trace32.

ARM DS-5 Support

Support for this board is included in the Altera QuartusII SoC EDS. Select the Cyclone V dual core option in the debug configuration to debug SMP applications. Otherwise follow the EDS, Eclipse and DS-5 documentation to set up and operate the debugger.

A suitable license file will also be needed.

Trace32 Support

Support for SMP debugging using the Lauterbach Trace32 debugger using a Power Debug probe is available. You need suitable licenses for the Cortex-A/R families and multicore debugging in order to do this.

The Trace32 debugger needs a startup script to initialize it for the Cyclone V. Some example scripts are present in the Cyclone V SX platform HAL ( i.e. packages/hal/arm/cortexa/cyclone5_sx/VERSION/misc). The ecospromp.cmm file provides setup for the standard Trace32 application, and ecospromp-qt.cmm is for the QT based variant avaliable on some host operating systems. These files are identical except for the layout file they load to define the window arrangement (layoutmp.cmm or layoutmp-qt.cmm). The expectation in these scripts is that all files are present in the same directory, along with the application being debugged. It is recommended that these files be copied out of the source repository into a working directory to which the application can also be copied and that Trace32 be started from the command line as follows: 

$ cd /path/to/work/directory
$ t32marm-qt -s ecospromp-qt.cmm

The lack of a clean hardware reset on this board means that the safest approach for debugging any application is to power cycle the board, start Trace32 and then load and run the application. To re-run the application, exit Trace32 before power cycling the board.

In addition to attaching to the target, these startup files define an additional eCosPro menu in the Trace32 GUI. It contains the following entries:

MMU Table List
This entry causes a window showing the curent state of the MMU tables for the current CPU to be displayed. In eCos, all CPUs should be using the same shared table.
Load eCos.t32
This loads the Trace32 eCos RTOS specialization extenstion. This file should be copied out of the Trace32 installation into the working directory. Note that the eCos RTOS support is not SMP-aware, so some information it displays in SMP application may be a little misleading. See the Lauterbach documentation on the RTOS debugger for eCos for more details of the functionality available.
Display Threads
Displays a list of current threads. Note that in SMP systems only the thread running on CPU 0 will be marked running. Those on other CPUs will be marked ready.
Display Scheduler
Displays state of scheduler. Only those parts of the scheduler state common between single and multi-core systems will be displayed.
Jump to CPU entrypoint
This entry disables the Caches and MMU and sets PC to zero. This may cause the system to restart once it is started running, however, it may also cause a crash since the hardware will not be in its initial state. In particular, if the second CPU is running, it is likely to cause a problem. Under most circumstances the board should be power cycled.
Load APP.ELF
This entry disables the caches and MMU, loads the file app.elf from the current directory, and loads any breakpoints from breakpoints.cmm. This is the menu entry that should be used to load and run SMP applications for development and testing. The breakpoints.cmm file allows a set of current breakpoints to be saved using the Store button on the breakpoint list window and have them reloaded automatically each time the application is reloaded.
Load APP.ELF Syms+Bkpts
This entry loads just the symbol tables and debug information from the application and also loads breakpoints from breakpoints.cmm. This is useful if the application is already running when Trace32 is attached. For example if it is a ROM startup application that has been loaded from flash, or an SMP startup application that was loaded by RedBoot.
Prev Up Next
Configuration Home The HAL Port