Avaota A1 is equipped with the Allwinner T527 platform, which integrates a RISC-V small core CPU and DSP, forming a heterogeneous computing architecture together with the Arm core.
In a heterogeneous multi-processing system, the presence of the main core and auxiliary core aims to collaborate to achieve more efficient task processing. This collaboration requires the system to adopt a series of strategies to ensure that each core can fully leverage its performance advantages and achieve effective communication and cooperation. This forms an architecture known as Asymmetric Multiprocessing (AMP) system.
The communication in heterogeneous systems uses MSGBOX at the hardware level and AMP and RPMsg communication protocols at the software level. The large core is based on the Linux standard RPMsg driver framework, while the small core is based on the OpenAMP heterogeneous communication framework.
AMP and RPMsg
The main core and auxiliary core are two completely different cores. To maximize their performance and collaboratively complete a specific task, the systems running on different cores are also different. These different core architectures and the software running on them combine to form the AMP system (Asymmetric Multiprocessing System).
Since the purpose of the two cores is to collaborate, a Master-Remote structure often forms in heterogeneous multi-processing systems. The main core starts the auxiliary core after it is powered on. Once the systems on both cores are fully started, they communicate through IPC (Inter Processor Communication), where RPMsg is one of the IPC methods.
In the AMP system, the two cores communicate via shared memory. The two cores pass messages through AMP interrupts. Memory management is handled by the main core.
The design of heterogeneous multi-processing systems needs to fully consider the heterogeneous nature of the main and auxiliary cores, as well as their communication and cooperation methods, to achieve efficient task allocation and processing.
The AMP system has two buffers in each communication direction, namely USED and AVAIL. This buffer can be divided into linked segments according to the message format in RPMsg, forming a ring.
When the main core needs to communicate with the auxiliary core, it can be divided into four steps:
-
The main core first retrieves a block of memory from USED.
-
Fill the message according to the message protocol.
-
Link that memory to the AVAIL buffer (Send).
-
Trigger an interrupt to notify the auxiliary core that there is a message to process.
Conversely, when the auxiliary core needs to communicate with the main core, it is similar:
-
The auxiliary core first retrieves a block of memory from AVAIL.
-
Fill the message according to the message protocol.
-
Link that memory to the USED buffer (Send).
-
Trigger an interrupt to notify the main core that there is a message to process.
RPMsg Protocol
Since RPMsg is a protocol for information exchange, similar to TCP/IP, the RPMsg protocol is also layered, mainly divided into three layers: transport layer, MAC layer, and physical layer.
Among them, the MAC layer’s VirtIO is a semi-virtualized I/O solution, a set of general I/O device virtualization programs, which abstract a set of general I/O devices in a semi-virtualized Hypervisor. It provides a communication framework and programming interface between upper-layer applications and various Hypervisor virtualized devices, reducing compatibility issues caused by cross-platform and greatly improving driver development efficiency.
Messages on the RPMsg bus have the following structure, containing a fixed message header and data part. The definition of this message format is located in drivers/rpmsg/virtio_rpmsg_bus.c, specifically defined as follows:
struct rpmsg_hdr { u32 src; u32 dst; u32 reserved; u16 len; u16 flags; u8 data[];} __packed;
Heterogeneous Computing Resource Allocation
Since the cacheable space size of the DSP can only be divided according to your 512MB, and jump instructions cannot exceed 1G space, there exist multiple address mappings for SRAM and DRAM space in the DSP, distinguishing between cacheable and non-cacheable based on different address segments.
The DSP’s local SRAM includes IRAM and DRAM0/1, placed inside the DSP. Other hosts can access this RAM through the DSP’s bus interface, while the DSP can directly access it through a specific address (0x0040_0000 – 0x0044_FFFF) for maximum efficiency.
Avaota A1 T527 development board DSP resource allocation
Avaota A1 T527 development board RV resource allocation
-End-
The content of this article is reprinted from the following link
1,https://docs.avaota.fun/avaota-sbc/avaota-a1/hardware/hardware_info
