Multicore heterogeneous systems are computing systems that allow different cores within the same SoC chip to independently run different platforms. By properly allocating processor cores and peripheral resources, a single SoC chip can simultaneously run Linux and real-time operating systems (RTOS), meeting the demands for system functionality, hardware diversity, and real-time performance, while also offering excellent cost-effectiveness and product compactness.

1. Rockchip Multicore Heterogeneous System

Rockchip's multicore heterogeneous system solution includes:

Operating Platforms:

Linux provides the standard Linux Kernel；RTOS offers the open-source RT-Thread；Bare-metal supports a bare-metal development library based on the RK HAL hardware abstraction layer. Users can also adapt other RTOS based on RK HAL.

Processor Cores:

It supports homogeneous ARM Cortex-A cores running independently within the SoC, as well as heterogeneous ARM Cortex-M or RISC-V cores. The system allocates tasks to the most suitable core, enhancing performance and efficiency.

Currently, Rockchip's multicore heterogeneous system uses an unsupervised AMP (Asymmetric Multiprocessing) approach. It does not use virtualization management, which allows for faster interrupt response in real-time systems, meeting stringent real-time requirements in industries such as power and industrial control.

2. RK3562J Processor Cores and AMP Support

Processor Cores:

AMP Support:

3. Interrupt Nesting Mechanism

Interrupt nesting is an effective interrupt handling mechanism that allows the system to respond to and process interrupts based on their priority, ensuring that critical tasks are handled in a timely manner. It features high real-time performance, flexibility, and quick response. However, traditional Linux systems do not support interrupt nesting to simplify design, improve system stability, reduce resource contention and deadlock risks, and enhance compatibility and maintainability. While Linux performs well in many application scenarios, it struggles with high real-time applications.

4. Case Study

Development Board Model: OK3562J-C

Documentation Version: OK3562-C_Linux 5.10.198_User Documentation_R1

Testing Approach:

Use two GPIO, GPIO4B1 set as output and GPIO0B0 set as input with falling edge trigger.

Physically short GPIO4B1 and GPIO0B0.

Use Timer4 to generate a timer interrupt every second, and in the interrupt handler, control GPIO4B1 to create a falling edge and delay. If the print statement in GPIO0B0's interrupt handler appears, it indicates successful interrupt preemption.

Testing Steps:

(1) Write the test program fltest_irq_preempt.c to enable TIMER4 and GPIO0B0 interrupts and configure GPIO0B0 for falling edge trigger. In the timer interrupt handler, toggle GPIO4B1 to trigger GPIO0B0's interrupt and print a message in GPIO0B0's interrupt handler to indicate the interrupt;

(2) Modify the interrupt routing to bind TIMER4 and GPIO0 interrupts to CPU3, and set TIMER4's interrupt priority higher than GPIO0B0;

(3) Recompile the image and flash it to the development board;

(4) Enable AMP in the uboot menu and reboot the OK3562J-C development board. The RTOS debug serial port will display related information:

Press the tab key to print out all the current commands:

Then the command is registered successfully.

Execute the fl_irq_test command, and you will see:

GPIO0B0's interrupt preempts the TIMER4 interrupt.

Swap their priorities, recompile and flash again, and it will be observed that GPIO0B0's interrupt is handled after the TIMER4 interrupt ends, without preemption.