MISC-TN-003: Asymmetric multiprocessing on NXP i.MX6SoloX

History

Version	Date	Notes
1.0.0	January 2017	First public release

Introduction

Asymmetric multiprocessing (AMP for short) is getting popular in the embedded world, thanks to the availability of multi-core embedded processors. It is particularly useful tom combine in one single chip two different operating systems (o.s.). One of the most common combination is the use of a general purpose operating system (GPOS) with a real-time o.s. (RTOS), in order to meet both hard real-time constraints and generic connectivity/user interface requirements, with a highly integrated solution.

AMP can be implemented on homogeneous [1] and heterogeneous architectures. Either way, it poses significant challenges when it comes to handle resources that are unavoidably shared across different cores. ARM cores integrates TrustZone technology that can be exploited to face such issues, as described for example in this document.

Other system-on-chips (SOC) implements proprietary solution to handle the access to the shared resources. NXP i.MX6SoloX is an example of such components, as it integrates a so called Resource Domain Controller (RDC), that "provides robust support for the isolation of destination memory mapped locations such as peripherals and memory to a single core, a bus master, or set of cores and bus masters" as stated by the manufacturer [2].

This white paper describes an i.MX6UL-based AMP solution that has been implemented for a custom product.

[1] See for example this page.

[2] See NXP i.MX 6SoloX Applications Processor Reference Manual (IMX6SXRM).

Implementation

The following image shows a simplified block diagram of the implemented solution.

Simplified block diagram of the AMP configuration

Is this case the role of the GPOS is played by Linux, while FreeRTOS has been used as real-time operating system [1].

For this specific application, it is required that the M4 core has exclusive access to the following resources:

• GPT (General Purpose Timer), including associated I/Os
• some additional GPIOs.

It is also required that:

• M4 firmware is booted before the Linux kernel [2]
• The Linux kernel has exclusive control of some other GPIOs.

Satisfying the first requirement has been the trickiest challenge because, by default, U-Boot and Linux kernel make use of GPT timer, as per official BSP released by NXP. This is not a big deal for U-Boot, because it just uses this timer to handle timeouts and to measure time intervals. The things are more complicated with regard to the Linux, because GPT is used as kernel's clock source. As such, it is involved in the scheduling process and it is dynamically reconfigured over the time, depending on power saving policies.

To solve this issue, both U-Boot and Linux kernel have been modified, in order to use EPIT timer instead. In spite of this modification, we have been able to preserve Linux's power saving mechanisms.

In order to protect the peripherals that have to be under the exclusive control of the M4 core, RDC has been configured accordingly. For example, the memory area in which GPT registers are mapped, is accessible by the M4 core only. RDC initialization is performed by M4 itself. It is worth remembering that the its granularity is an important factor that has to be taken in consideration. In this application, for example, it has had to choose different GPIO banks for M4 and A9. In case the same bank was chosen, it would have been impossible to partition GPIOs across the two cores, because some resources are shared among all of the GPIOs belonging to the same bank (for example the clocks feeding the GPIO module). For this reason, two different banks have been chosen.

[1] For more details please refer to the FreeRTOS™ BSP for the i.MX 6SoloX ARM® Cortex®-M4 core.

[2] Following is the complete bootstrap sequence:

1. A9 core
   • comes out of reset
   • executes bootrom
   • performs basic hardware initializations
   • fetches U-Boot bootloader from flash memory and copies it in SDRAM
   • executes U-Boot from SDRAM
2. In turn, U-Boot
   • fetches M4 firmware from flash
   • starts M4 core
   • fetches Linux kernel and DTB from flash and copies them in SDRAM
   • starts Linux kernel on Cortex-A9 core.
3. Once Linux kernel has completed the bootstrap process, a user space application establishes a communication channel with M4 core, through RPMsg.