Click the blue text aboveTalks Lab
to get more information on automotive network security
With the continuous development of electronic technology and the growing market demand, embedded systems are required not only to perform complex control tasks but also to collect and process data in real-time.
To meet these demands, multi-core heterogeneous processors have become a popular solution. These processors typically combine ARM architecture’s A-series cores (for handling advanced computing tasks) with M-series or R-series cores (focused on real-time operations).
In this architecture, complex control tasks can be handled by the A core running Linux, while real-time data collection and processing can be managed by the M core or R core running an RTOS.
This article discusses the principles of multi-core heterogeneous design and communication, using the Renesas RZ/G2L multi-core processor as an example.
01
Overview of Multi-Core Processors
In traditional designs, two chips need to exchange large amounts of data through external interfaces, which not only occupies valuable pin resources but also results in low data transfer efficiency.
In contrast, multi-core heterogeneous processors that integrate A cores with M or R cores utilize an internal bus structure for fast communication and share internal resources, thus avoiding the use of external pins.
This multi-core heterogeneous system design not only reduces information security risks during communication but also lowers chip procurement and management costs, reduces PCB costs and size, and simplifies the development process.
Overview of the Renesas RZ/G2L Processor
A general-purpose microprocessor equipped with a dual-core Arm® Cortex®-A55 (1.2 GHz) CPU and a single-core Arm® Cortex®-M33 (200 MHz) CPU, along with a 3D graphics acceleration engine and video encoding/decoding engine.
G2L Block Diagram
02
Heterogeneous Communication Mechanism
The heterogeneous communication mechanism (OPENAMP Open Asymmetric Multi-Processing) has matured significantly.
In the RZ/G2L series MPU, we can see a practical application of the multi-core heterogeneous architecture. This MPU features a large core Cortex-A55, with a frequency of up to 1.2GHz, capable of running a Linux operating system, and a small core Cortex-M33, with a frequency of 200MHz, specifically designed to run RTOS or bare-metal programs. The heterogeneous communication between these two cores is achieved through the OpenAMP software framework.
OpenAMP is a lightweight communication protocol that allows different processors to communicate via shared memory or message-passing mechanisms. In a multi-core processing system, each processor may run different software modules, and the OpenAMP framework provides an effective means for data exchange and collaboration between these modules. In this way, OpenAMP not only simplifies communication between processors but also enhances the overall system’s collaborative efficiency and functionality. See Figure 1.
Figure 1
03
Virtio Virtualization Module
Virtio is a virtual device framework for shared memory management. The vring in Virtio refers to a FIFO queue of pointers to data buffers, with two unidirectional vrings: one vring is dedicated to sending messages to the remote processor, and the other vring is for receiving messages from the remote processor. The data is stored in shared memory, specifically in Vring buffers, with half allocated for sending and half for receiving.
04
RPMsg Remote Processor Messaging
The RPMsg framework is located above Virtio and is a message bus based on Virtio. See Figure 2.
Figure 2
05
Remoteproc
The Linux operating system on the main processor can manage the lifecycle of the remote processor and its associated software environment, including starting or shutting down the remote processor. See Figure 3.
Figure 3
06
IPCC Inter-Processor Communication Controller
The MHU (Message Handling Unit) is an IP module within the MPU chip that serves as the IPCC for message communication between Cortex-A55 (CA55) cores or between CA55 and Cortex-M33 (CM33). Data transmission is achieved through shared memory.
A channel consists of a pair of data transfer processing registers and response transfer processing registers, with a total of 12 channels (CA55 Core0/Core1 CM33, secure and non-secure areas). See Figure 4.
Figure 4
The above introduces the communication methods of the RZ/G2L dual-core heterogeneous architecture, and the RZ/G2L products also provide corresponding software support.
07
Multi-OS (CA55 Linux + CM33 RTOS)
Customers can quickly develop applications using flexible software packages (FSP) and create applications that work with Linux using OpenAMP. See Figure 5.
Figure 5
08
Cortex-M33 Development Environment
Figure 6
Corresponding hardware boards and software tools can be obtained from the Renesas official website.
09
JTAG Online Debugging
When connecting JTAG, DIP SW1 must be set as follows. See Figure 7.
Figure 7
CORTEX-M33 Boot Methods
-
CM33 is loaded and booted by CA55
-
There are multiple points in time during the boot process to perform this operation:
● Arm Trusted Firmware
The fastest way to boot CM33
Allows code to be loaded into secure RAM
● u-boot -> Multi OS SW package default method
CM33 firmware is easy to update
The binary file is stored in a file system accessible by u-boot
● Linux (remoteproc)
Most convenient for maintenance, with minimal software upgrade changes
Shared Resources
When sharing resources, please pay attention to the following allocations
-
Pin multiplexing
-
Memory allocation
-
Peripheral allocation
Source: Automotive Software Development
end
Recommended Premium Events
AutoSec China Tour Series Salon
Professional Community
Some experts in the group come from:
New force car companies:
Tesla, Hozon Auto – Nezha, Li Auto, Zeekr, Xiaomi, Binnli Auto, Jiyue, Leap Motor, Avita, Zhiji Auto, Xiaopeng, Lantu Auto, NIO, Geely Auto, Seres……
Foreign traditional mainstream car companies:
Volkswagen China, Volkswagen Cool Wing, Audi, BMW, Ford, Daimler-Benz, General Motors, Porsche, Volvo, Hyundai, Nissan, Jaguar Land Rover, Scania……
Domestic traditional mainstream car companies:
Geely Auto, SAIC Passenger Cars, Great Wall Motors, SAIC Volkswagen, Changan Automobile, Beijing Automotive, Dongfeng Motor, GAC, BYD, FAW Group, FAW Jiefang, Dongfeng Commercial, SAIC Commercial……
Global leading Tier 1 suppliers:
Bosch, Continental Group, United Automotive Electronics, Aptiv, ZF, KOSTAL, Schaeffler, Honeywell, DJI, Hitachi, Harman, Huawei, Baidu, Lenovo, MediaTek, Preh, Desay SV, Honeycomb Steering, Junlian Zhixing, Wuhan Guangting, Xingji Meizu, CRRC Group, Wintech, Weichai Group, Horizon, Unisoc, ByteDance,……
Tier 2 suppliers (over 500):
Upstream, ETAS, Synopsys, NXP, TUV, Shanghai Software Center, Deloitte, Zhongke Shumei Technology, Qihoo 360, etc.
Personnel Proportion
Company Type Proportion
More Articles
Don’t miss out, this could be the largest exclusive community in the automotive network security industry!
About the lawyer’s statement regarding the alleged imitation of the AutoSec conference brand
One article takes you through the intelligent vehicle onboard network communication security architecture
Cybersecurity: TARA methods, tools, and cases
Key analysis of automotive data security compliance
Analysis of automotive chip information security and secure boot
Exploration of automotive onboard communication security solutions in domain-centralized architecture
System security architecture of vehicle network security architecture
Privacy protection issues in the Internet of Vehicles
Research on network security technology for intelligent connected vehicles
AUTOSAR information security framework and key technology analysis
What information security mechanisms does AUTOSAR have?
Underlying mechanisms of information security
Automotive network security
Use of AUTOSAR hardware security module HSM
First release! Lei Jun from Xiaomi suggested at the two sessions regarding automotive data security: Suggestions for building a complete automotive data security management system