Embedded systems generally fall into two broad categories: those that require hard real-time performance; and those that do not require hard real-time performance. In the past, we had to make the choice of choosing the performance of a real-time operating system or the rich features of our favorite Linux system, and then trying to make up for the shortcomings.
A typical AMP configuration is similar in many respects to a PCI-based system where the Linux domain acts as a host, the RTOS domain acts as an adapter, and one or more shared memory domains are used to communicate between the two domains. However, unlike PCI, AMP configurations make it easier and more efficient to allocate resources (standard peripherals and custom logic) to one or another domain. In addition, the Linux/RTOS AMP system dynamically reconfigures programmable logic based on runtime requirements, such as the presence or absence of various external devices.
Flexibility is often related to the complexity and difficulty involved in building an AMP system. However, please be assured that the Linux development community has introduced many features to the core, which greatly simplifies AMP configuration and usage.
Introduction to LINUX MultiprocessingIn terms of multiprocessing, there are two Linux cores: a single processor (UP) core and a symmetric multiprocessor (SMP) core. Regardless of the number of cores, the UP core can only run on a single core. An AMP system can contain instances of two or more single processor cores.
The SMP core can run on one core or multiple cores simultaneously (Figure 1). The optional core command line arguments control the number of cores used by the SMP core after system initialization. At the core runtime, various command line utilities control the number of cores assigned to the core. The ability to dynamically control the number of cores used by the kernel is the main reason why the SMP core is more popular with AMP developers than the UP core.
Figure 1 – Symmetric multiprocessing. The SMP core can run simultaneously on multiple cores.
The remoteprocal (remoteproc) framework is a Linux component that is responsible for starting and stopping individual kernels (remote processors) and for loading kernel software in an AMP system. For example, we can dynamically reconfigure the SMP system shown in Figure 1 to the AMP system shown in Figure 2, and then configure back to SMP using the functionality of remoteproc.
We can fully control reconfiguration through user space applications or system initialization scripts. The reconfiguration control feature allows the user application to stop, reload, and run multiple RTOS applications based on the dynamic needs of the system.
Figure 2 - AMP with Linux SMP Core
The kernel's software (in this case, RTOS and user applications) is loaded from a standard executable and linkable format (ELF) file that contains a special section of the resource table. The resource table is similar to the PCI configuration space and is used to describe the resources required by the RTOS. These resources include the memory required for the RTOS code and data.
Tracking bufferThe trace buffer is a memory area that appears automatically as a file in the Linux file system. As the name suggests, the trace buffer provides basic tracking to remote processors. The remote processor writes trace, debug, and status messages to the buffer for inspection via the Linux command line or custom application.
Being able to dynamically control the number of cores used by the core is the main reason why the SMP core is more popular with AMP developers than the UP core.
Enter an entry in the resource table to request one or more trace buffers. Although plain text is generally included, the trace buffer also contains binary data, such as application status information or alert indications.
Virtual I/O deviceWe can also use resource tables to define virtual input/output devices (VDEVs), which are primarily pairs of shared memory queues that support messaging between Linux cores and remote processors. The VDEV definition includes fields for setting the queue size and interrupts to signal between processors.
The Linux kernel handles the initialization of virtual I/O queues. Software running on a remote processor only needs to include a VDEV description in its resource table and then use the queue at the beginning of execution; the rest is handled by the core.
Remote processor message framework
The Remote Processor Messages (rpmsg) framework is a software message bus for virtual I/O systems based on the Linux kernel. The message bus is similar to a local area subnetwork in which a single processor can create addressable endpoints and exchange information through shared memory.
The core rpmsg framework acts as a switch that passes messages to the appropriate endpoints based on the destination address contained in the message. Since the message header contains the source address, a dedicated connection can be established between different processors.
Naming serviceThe processor can dynamically announce a particular service by sending a message to the naming service of the rpmsg framework. The naming service function itself is not very useful. However, the rpmsg framework allows service names to be associated with device drivers to support automatic loading and initialization of drivers.
For example, if the remote processor announces the dlinx-h323-v1.0 service, the core can search, load, and initialize the driver associated with the name. This greatly simplifies driver management if the services in the system are dynamically installed on the remote processor.
Management interruptionInterrupt management is a bit tricky, especially when starting and stopping the kernel. Ultimately, the system needs to dynamically redirect specific interrupts to the remote processor domain when the remote processor starts, and then retract the interrupt when the remote processor stops. In addition, the system must protect the interrupt from being misallocated by misconfigured drivers. In short, interrupts must be managed at the system level.
This is a regular event for the Linux SMP core and is another reason why the SMP core is more popular in AMP configurations. The remote processor framework makes it easy to manage interrupts with minimal support from device drivers.
Device driverDevice-driven development is a constant concern, as the required skill set may not be available immediately. Fortunately, the Linux core's remoteproc and rpmsg frameworks do most of the heavy lifting; the driver only needs to implement a few standard driver routines. A fully functional driver may only require a few hundred lines of code. The core source tree contains examples of drivers that embedded developers can adjust to their own requirements.
Vendors also offer generic open source device drivers. DesignLinx Hardware Solutions provides a generic rpmsg driver for Linux and FreeRTOS. Because the generic driver does not assume the format of the message being exchanged, embedded developers can use it for multiple AMP applications without any modifications.
New SoC products enable designers to easily migrate a variety of hardware designs from printed circuit boards to on-chip systems (Figure 3). In the past, parts of discrete processors and components on the PCB were fully implemented within the SoC pins.
For example, we can use the Xilinx Zynq-7000 Series SoC to implement the initial PCB hardware architecture in Figure 3, with one of the ARM processors as the control CPU and soft processor in the programmable logic (such as the Xilinx MicroBlazeTM processor). ) to replace discrete processors. We can run the Linux SMP core using the remaining ARM processors (Figure 4).
Adding Linux to the original design provides the ARM core and soft core processor with all of the standard multiprocessing features described above (such as start, stop, reload, trace buffer, and remote messages). Moreover, it also brings a rich set of Linux features that support multiple network interfaces (Ethernet, Wi-Fi, Bluetooth), network services (Web server, FTP, SSH, SNMP), file systems (DOS, NFS, cramfs, Flash memory) and other interfaces (PCIe, SPI, USB, MMC, video). These features make it easy to implement new features without having to make major changes to the proven architecture.
New SoC products enable designers to easily migrate a variety of hardware designs from printed circuit boards to system-on-a-chip.
The kernel continues to emergeOver the past few years, multi-core SoC products for the embedded market have continued to grow and are well suited for AMP configurations.
For example, the Xilinx UltraScale+TM MPSoC architecture includes a 64-bit quad-core ARM Cortex-A53, a 32-bit dual-core ARM Cortex-R5, a graphics processing unit (GPU), and a variety of other peripherals, including useful programmable logic. This provides a fertile ground for designers who know how to harness the performance of real-time operating systems and the rich feature set of the Linux kernel.
Portable power system ,Portable power storage,Portable solar system, Outdoor power station, Portable power station
SHENZHEN CHONDEKUAI TECHNOLOGY CO.LTD , https://www.szsiheyi.com