Multi-core processor chip function security implementation method

Abstract

The invention discloses a multi-core processor chip function security implementation method. The method comprises the following steps that S20, a multi-core processor continues to occupy one or more CPU cores and a part of memory in Bootloader to take over quick start or security related tasks; and S30, the operating system kernel only takes over part of the CPU core and the memory, and one CPU core and part of the memory are left for the bootloader to be continuously used. S22, the Bootloader is responsible for displaying one image layer; and S31, the kernel of the operating system is responsible for displaying the layers except the Bootloader and is responsible for synthesizing all the layers, including the layers displayed by the Bootloader. The method has the technical effects that the fault-tolerant time interval FTTI is short, and the performance of the method is usually more than 10 times higher than that of an MCU (Microprogrammed Control Unit) of an external cortex-M core; hard isolation or redundancy is cancelled, cost reduction is achieved, an OSD chip and a Flash in an instrument screen are omitted, and the MCU specification of the instrument screen is reduced. The system performance is improved by canceling virtualization, and the general virtualization can cause obvious loss of the computing power of the CPU and the GPU; the method does not conflict with other existing methods, and can be used in a superposed manner when needed.

Description

Technical Field

[0001] The present invention relates to the field of automobile functional safety, and in particular to a method for implementing functional safety of a multi-core processor chip. Background Art

[0002] In recent years, the popularity of automotive functional safety has been increasing. On the one hand, it reflects our increasing attention to automotive safety issues. On the other hand, due to the increasing complexity of the software and hardware of automotive processor chips (typically multi-core SOC and MPU), functional safety has become an issue that cannot be ignored.

[0003] Functional safety is defined as the absence of unreasonable risk of hazards caused by malfunctioning behaviour of electrical and electronic systems.

[0004] The purpose of functional safety is to reduce risks to an acceptable level.

[0005] In order to achieve the goal of functional safety, we need to measure and evaluate risks, which are divided into five risk levels: QM, ASIL A, ASIL B, ASIL C, and ASIL D. ASIL (Automotive Safety Integration Level) is the automotive safety integrity level. The higher the level, the more risk reduction measures are needed.

[0006] For a certain function, the risk is assessed by comprehensively evaluating the degree of damage and the possibility of damage, and then the automotive safety integrity level (ASIL level) that the function needs to meet is determined. The degree of damage is represented by the parameter S (Severity), and the possibility is represented by the parameters E (Exposure) and C (controllability).

[0007] After assessing the ASIL level, certain safety measures need to be taken to reduce the risk to an acceptable range, which is the safety target.

[0008] The safety goal can be simply summarized as follows: when a fault occurs, as long as the system enters a safe state (system degradation or alarm) within the fault tolerant time interval (FTTI), the occurrence of harm can be avoided.

[0009] Multi-core processor chips are widely used in key vehicle products such as cockpit domain controllers, intelligent driving domain controllers, and body domain controllers.

[0010] Taking the cockpit domain controller as an example, a cockpit domain controller often includes an instrument system and an entertainment system. The instrument system is often displayed on the instrument screen, while the entertainment system is often connected to the central control screen, the co-pilot screen, and the rear screen. These two systems often have different automotive safety integrity level (ASIL level) requirements. For example, some functions of the instrument are ASIL B, such as the warning indicator light, while the entertainment system generally only requires QM. In order to achieve a relatively higher ASIL level for the instrument system, it is necessary to avoid failures of the instrument system due to entertainment system failures (such as Android application failures). The existing methods are mainly divided into two categories: 1. Isolation of the two systems. 2. Redundancy.

[0011] Existing methods for isolating two systems are: 1. Virtualization technology: Virtualization technology achieves functional safety by isolating different functional modules in independent virtual machines. In this way, different components of the system are isolated from each other, and other modules can be kept running normally when a single fault occurs. In addition, the instrument system is independent of the entertainment system, and its failure rate is reduced. Once a fault occurs, the instrument can be restarted quickly and can be restarted and recovered within 3 seconds, which basically meets the requirements of general car companies for instrument fault tolerance time interval FTTI.

[0012] This technology will significantly reduce the performance of the processor CPU, GPU, and NPU, and there are many difficulties and limitations in the development of various hardware resource allocations. In addition, the development cost, development time, and licensing fees to virtualization technology development companies for mass production are very high.

[0013] 2. Container Technology Container technology (Linux Container, Docker) can use cgroup and namespace technology to isolate the two systems, which can improve the reliability of the instrument system and reduce the impact of entertainment system failures on the instrument system. It rarely reduces processor performance and has a lower development cost than virtualization technology.

[0014] However, the instrument system and entertainment system still share the same Linux kernel. Although the failure rate of the instrument system is lower than that of the entertainment system, it is still higher than that of the instrument system using virtualization technology. More importantly, once a fault is detected, the instrument function cannot be restored within the fault tolerance time interval FTTI. Restarting the entire system often takes more than 10 seconds, and the FTTI of a general instrument failure often needs to be less than 3 seconds (the requirements of each car company vary, and some require less than 1 second).

[0015] 3. Single processor hard isolation technology: Hard isolation technology physically separates different functional modules to prevent them from interfering with each other. This method can be achieved by isolating independent processor cores to ensure that the entertainment system cannot interfere with the instrument system during operation. Hard isolation technology can make the instrument system and entertainment system have a higher degree of isolation than virtualization technology.

[0016] However, hard isolation technology will lead to the full allocation of hardware resources, and the overall performance utilization of the hardware is very low, which often leads to the processor performance of the instrument system and entertainment system being stretched to the limit. Moreover, this method requires the processor itself to be designed with hard isolation capabilities, which many processors do not have.

[0017] 4. External processor hard isolation technology: External processor hard isolation technology uses an external separate graphics MCU and / or FPGA hardware unit to implement the instrument system separately, ensuring that the entertainment system cannot interfere with the instrument system during operation. External processor hard isolation technology can make the instrument system and entertainment system have a higher degree of isolation than virtualization technology.

[0018] However, using an external graphics MCU and / or FPGA to run the instrument system will result in poor performance and experience of the instrument system and significantly increase costs.

[0019] The main redundancy methods are: 1. Full backup system redundancy Add a processor system with the same performance for redundant backup. When a system fails, the backup system can take over immediately. This can improve system reliability and shorten FTTI time.

[0020] However, this method increases the cost exponentially and is very expensive. It is generally limited to systems that meet ASIL D requirements.

[0021] 2. Functional safety island redundancy Redundancy is achieved through an internal functional safety island, which is often a processor core that can handle the instrument system independently. Once a problem occurs in the instrument system, it can be quickly switched to the functional safety island to display the most basic instrument functions. In this way, the instrument and entertainment system can share the same system.

[0022] This method requires the processor itself to be designed with a functional safety island, which many processors currently do not have. The processing cost is also relatively high.

[0023] 3. External processor redundancy Add an external MCU and graphic overlay chip (such as OSD chip) for redundancy. Once the instrument fails and causes the system to restart, the external MCU and graphic overlay chip can display the key information of the instrument in a very short FTTI time.

[0024] However, this method adds a graphics overlay chip, and the graphics overlay chip often needs to adapt to the video format chip, which generally requires the addition of an FPGA for adaptation, resulting in a significant increase in cost. In addition, the graphics display effect and frame rate are not ideal. Summary of the invention

[0025] The present invention provides a functional safety implementation method based on the mechanism of a multi-core processor without the need for virtualization or hard isolation. The method has the following advantages: a short fault tolerance time interval FTTI; good performance in a safe state; the ability to eliminate hard isolation or redundancy to reduce costs; the ability to eliminate virtualization to improve system performance, and does not conflict with other existing methods, and can be used in combination when necessary.

[0026] To achieve the above object, the present invention provides a method for implementing functional safety of a multi-core processor chip ( Figure 4 ), characterized in that it comprises the following steps: S10, Bootloader starts loading the operating system kernel; S20: The multi-core processor continues to occupy one or more CPU cores and a portion of memory in the Bootloader to take over fast startup or security-related tasks (compared to processing security-related tasks after the operating system is loaded, it will be faster and reduce security risks); S30, the operating system kernel only takes over some CPU cores and memory, leaving one CPU core and some memory for the bootloader to continue using. (The traditional method is to exit the bootloader and let the operating system kernel take over all CPU cores and memory); Furthermore, the method further comprises the following steps: S21, load necessary drivers in the Bootloader including any one or more of display driver, audio driver, UART, I2C, I2S or SPI.

[0027] Furthermore, the method further comprises the following steps: S22, Bootloader is responsible for displaying one layer (the other layers are displayed by the operating system kernel); S31, the operating system kernel is responsible for displaying layers other than the bootloader, and is responsible for the synthesis of all layers (including the layers displayed by the bootloader). (The traditional solution is that the operating system kernel is responsible for the display and synthesis of all layers, which makes it impossible to display quickly in the bootloader, and to switch the display to the operating system after the subsequent operating system is running normally.) Furthermore, the method further comprises the following steps: S23, determine whether to enter a safe state, S231, if it is a safe state, running functions related to the safe state in the Bootloader; S232: If it is not in a safe state, it is determined to be in a fast startup mode, and functions related to the fast startup are executed.

[0028] Furthermore, the method further comprises the following steps: S23, whether or not to enter a safe state, S233, S234, the operating system is initialized. S24, return the drivers to the operating system, such as display-related drivers, audio-related drivers, UART, SPI, and I2C (if the drivers are not returned, the operating system will be unable to load and use these drivers.) Furthermore, the method further comprises the following steps: S23, whether or not to enter a safe state, S233, S234, determining whether the operating system has been initialized. S24, after the operating system is initialized, the driver is returned to the operating system; S25, exit Bootloader state; S26, return the CPU core and memory running the Bootloader to the operating system kernel for use. (CPU and memory resources are not wasted. If they are not recovered, the operating system will lose the computing power of a CPU core and part of the available memory.) Furthermore, S22 and S31 also include the following steps: S22 and S31 use the characteristics of the display processor (generally called DPU or DCU) in the multi-core processor to selectively stitch multiple layers together and output them to the display ( Figure 8 ); S22, Bootloader is responsible for displaying the content of one of the layers; S31, the operating system kernel is responsible for the display of other layers, and stitches and synthesizes each layer (including the layer responsible for the Bootloader).

[0029] Furthermore, the method further includes the following fault detection steps: S40, the multi-core processor calculates the CRC value of each graphic in the graphic alarm area, and transmits the CRC value to the MCU through a communication mechanism (such as UART or SPI) with the MCU; S41, MCU reads the vehicle body CAN bus message and looks up the table to obtain the correct CRC value of the corresponding graphic; S42, the MCU determines whether the CRC value of each graphic in the graphic alarm area conforms to the current state of the vehicle body CAN bus; if it conforms to the current state of the vehicle body CAN bus, it returns to step S40; if it does not conform to the current state of the vehicle body CAN bus, it determines whether it exceeds the limit (such as 200 milliseconds), if it does not exceed, it returns to step S40, if it exceeds, it triggers S60, the MCU controls the multi-core processor to restart, the system is reloaded, and it returns to step S10.

[0030] Furthermore, the method further includes the following fault detection steps: S50, the serializer detects whether the CRC of the entire image between each link of the image transmission is consistent, and detects whether there is a frozen frame, wherein the image transmission link includes: Transmission between multi-core processors and serializers; Transmission between the serializer and the deserializer; S51, if the serializer does not detect CRC inconsistency or frozen frame, return to step S50; if the serializer detects CRC inconsistency or frozen frame, it triggers S52, the serializer triggers the multi-core processor to generate an interrupt through GPIO, and then triggers S53, the multi-core processor notifies the MCU of the fault through the communication mechanism between the MCU and the MCU (such as UART or SPI), and then triggers S60, the MCU controls the multi-core processor to restart, the system is reloaded, and return to step S10.

[0031] Further, according to Figure 1 The software architecture also includes the following methods to isolate systems with different functional safety levels: The namespace method in Linux technology is used to isolate systems with higher functional levels (such as C++ applications at the native layer) and systems with lower functional safety levels (such as systems related to Android Java applications). In this way, even if the system with lower functional safety level crashes and restarts, it will not affect the continued reliable operation of the system with higher functional safety level.

[0032] Furthermore, the invention also includes the following method for allocating CPU resources to systems with different functional safety levels: The Cgroup method in Linux technology is used to dynamically allocate CPU resources for systems with higher functional levels and systems with lower functional safety levels. This allows sufficient CPU resources to be allocated to systems with higher functional levels, and even allows a certain CPU core to be designated for use only by systems with higher functional levels. This ensures that systems with higher functional levels run reliably, smoothly, and with low latency.

[0033] The beneficial technical effects of the present invention are: The fault tolerance time interval FTTI is short, and it only takes about 1 second to enter the safe state. The instrument display can also be quickly turned on in the same short time, which is about one-fifth of the time under the virtualization solution; the performance in the safe state is good. Generally, when a single cortex-A core runs the function in the safe state, its performance is often more than 10 times stronger than the MCU of the external cortex-M core; hard isolation or redundancy can be cancelled to achieve cost reduction, eliminating the OSD chip and Flash in the instrument screen, and reducing the MCU specifications of the instrument screen; virtualization can be cancelled, which reduces costs and improves system performance. Generally, virtualization will cause a significant loss of CPU and GPU computing power; and this method does not conflict with other existing methods and can be used in combination when necessary. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is a hardware structure diagram of the present invention; Figure 2 is a schematic diagram of a 2D instrument of the present invention; Figure 3 is a prior art hardware block diagram of the present invention; Figure 4 is a flow chart of the method of the present invention; Figure 5 It is a flow chart of a traditional multi-core processor (left) and a flow chart of a part of the method of the present invention (right); Figure 6 It is another part of the method flow chart of the present invention; Figure 7 is a hardware block diagram of the present invention; Figure 8 It is a schematic block diagram of the splicing synthesis principle of the display processor DPU or DCU of the present invention. Specific implementation methods The existing technologies all have their own advantages and disadvantages. The present invention is an innovative method for how multi-core processors can achieve safety goals. The outstanding advantages are low cost, short fault tolerance time interval FTTI, and good performance in a safe state. It does not conflict with other existing methods and can be used in a superimposed manner. Considering the short FTTI and good performance in a safe state, in some occasions, such as the cockpit domain controller field, virtualization and hard isolation can be eliminated to further achieve cost reduction and efficiency improvement.

[0036] The following describes the preferred embodiments of the present invention with reference to the drawings in the specification, so that the technical content is clearer and easier to understand. The present invention can be embodied in many different forms of embodiments, and the protection scope of the present invention is not limited to the embodiments mentioned in the text.

[0037] In the drawings, components with the same structure are indicated by the same numerical numerals, and components with similar structures or functions are indicated by similar numerical numerals. In order to make the illustration clearer, the features of the components are appropriately simplified, exaggerated or emphasized in some places in the drawings.

[0038] Figure 1 It is a hardware structure diagram of the present invention; Figure 2 is a schematic diagram of an instrument of the present invention; Figure 4 It is the method flow of the present invention; Figure 5 The method flow of the present invention is Figure 1 Partially and in combination with traditional methods for comparison; Figure 6 The method flow of the present invention is Figure 1 part; Figure 7 is a hardware block diagram of the present invention; Figure 8 It is a schematic block diagram of the splicing synthesis principle of the display processor.

[0039] Figure 3 It is a prior art hardware block diagram of the present invention.

[0040] like Figure 5 , 6 , 7, the present invention provides to achieve the above purpose, the present invention provides 1. A method for implementing functional safety of a multi-core processor chip, characterized in that it includes the following steps: S10, Bootloader starts loading the operating system kernel; S20: The multi-core processor continues to occupy one or more CPU cores and a portion of memory in the Bootloader to take over fast startup or security-related tasks (compared to processing security-related tasks after the operating system is loaded, it will be faster and reduce security risks); S30, the operating system kernel only takes over some CPU cores and memory, leaving one CPU core and some memory for the bootloader to continue using. (The traditional method is to exit the bootloader and let the operating system kernel take over all CPU cores and memory); A preferred embodiment further comprises the following steps: S21, load necessary drivers in the Bootloader including any one or more of display driver, audio driver, UART, I2C, I2S or SPI.

[0041] A preferred embodiment further comprises the following steps: S22, Bootloader is responsible for displaying one layer (the other layers are displayed by the operating system kernel); S31, the operating system kernel is responsible for displaying layers other than the bootloader, and is responsible for the synthesis of all layers (including the layers displayed by the bootloader). (The traditional solution is that the operating system kernel is responsible for the display and synthesis of all layers, which makes it impossible to display quickly in the bootloader, and to switch the display to the operating system after the subsequent operating system is running normally.) A preferred embodiment further comprises the following steps: S23, determine whether to enter a safe state, S231, if it is a safe state, running functions related to the safe state in the Bootloader; S232: If it is not in a safe state, it is determined to be in a fast startup mode, and functions related to the fast startup are executed.

[0042] A preferred embodiment further comprises the following steps: S23, whether or not to enter a safe state, S233, S234, once the operating system is initialized, S24, return the drivers to the operating system, such as display-related drivers, audio-related drivers, UART, SPI, and I2C (if the drivers are not returned, the operating system will be unable to load and use these drivers.) A preferred embodiment further comprises the following steps: S23, whether or not to enter a safe state, S233, S234, determining whether the operating system has been initialized. S24, once the operating system is initialized, the driver is returned to the operating system; S25, exit Bootloader state; S26, return the CPU core and memory running the Bootloader to the operating system kernel for use. (CPU and memory resources are not wasted. If they are not recovered, the operating system will lose the computing power of a CPU core and part of the available memory.) In a preferred embodiment, S22 and S31 further include the following steps: S22 and S31 use the characteristics of the display processor (generally called DPU or DCU) in the multi-core processor to selectively stitch multiple layers together and output them to the display ( Figure 8 ); S22, Bootloader is responsible for displaying the content of one of the layers; S31, the operating system kernel is responsible for the display of other layers, and stitches and synthesizes each layer (including the layer responsible for the Bootloader).

[0043] Furthermore, regarding how to switch from the display in the bootloader (such as a 2D instrument interface) to the interface after the operating system is running (such as a 3D instrument interface) in steps S24, S24 and S26, the following example is given: refer to Figure 8 Generally, there is a display processor (generally called DPU or DCU) in a multi-core processor SOC. The display processor will selectively merge and splice multiple layers and output them to the display. Among them, the bootloader is responsible for the content display of one layer (S22), and the operating system kernel is responsible for the display of other layers (S31). The splicing and synthesis of all layers is the responsibility of the operating system kernel.

[0044] The specific method of display switching can be as follows: when displaying the 2D instrument in the Bootloader, layer0 (Bootloader instrument) and Layer2 (Android system) can be merged together for output and display (controlled by the operating system kernel). Once it is necessary to switch to the 3D instrument display running on the operating system, the display processor can be controlled (controlled by the operating system kernel) to merge Layer1 (3D instrument) and Layer2 (Android system) together for output and display, thus completing the switch from the Bootloader display to the operating system display. Therefore, this method is to achieve the switch from the content displayed in the Bootloader to the interface running the operating system by selectively adapting different layers in the display processor. The 2D instrument interface and the 3D instrument interface can be seamless, without frame loss, and smoothly gradient.

[0045] The preferred embodiment further includes the following fault detection steps: S40, the multi-core processor calculates the CRC value of each graphic in the graphic alarm area, and transmits the CRC value to the MCU through a communication mechanism (such as UART or SPI) with the MCU; S41, MCU reads the vehicle body CAN bus message and looks up the table to obtain the correct CRC value of the corresponding graphic; S42, the MCU determines whether the CRC value of each graphic in the graphic alarm area conforms to the current state of the vehicle body CAN bus; if it conforms to the current state of the vehicle body CAN bus, it returns to step S40; if it does not conform to the current state of the vehicle body CAN bus, it determines whether it exceeds the limit (such as 200 milliseconds), if it does not exceed, it returns to step S40, if it exceeds, it triggers S60, the MCU controls the multi-core processor to restart, the system is reloaded, and it returns to step S10.

[0046] The preferred embodiment further includes the following fault detection steps: S50, the serializer detects whether the CRC of the entire image between each link of the image transmission is consistent, and detects whether there is a frozen frame, wherein the image transmission link includes: Transmission between multi-core processors and serializers; Transmission between the serializer and the deserializer; S51, if the serializer does not detect CRC inconsistency or frozen frame, return to step S50; if the serializer detects CRC inconsistency or frozen frame, it triggers S52, the serializer triggers the multi-core processor to generate an interrupt through GPIO, and then triggers S53, the multi-core processor notifies the MCU of the fault through the communication mechanism between the MCU and the MCU (such as UART or SPI), and then triggers S60, the MCU controls the multi-core processor to restart, the system is reloaded, and return to step S10.

[0047] A preferred embodiment, according to Figure 1 The software architecture also includes the following methods to isolate systems with different functional safety levels: The namespace method in Linux technology is used to isolate systems with higher functional levels (such as C++ applications at the native layer) and systems with lower functional safety levels (such as systems related to Android Java applications). In this way, even if the system with lower functional safety level crashes and restarts, it will not affect the continued reliable operation of the system with higher functional safety level.

[0048] The following example illustrates how to isolate the resources of a 3D instrument system with a higher functional level and an Android JAVA system with a lower functional safety level, and how to ensure that the 3D instrument is not affected by the crash of an Android JAVA application.

[0049] This solution uses the namespace method in Linux technology to isolate the native layer C++ instrument and Android Java application, so that even if the Java virtual machine crashes or the core Android system resources crash and restart the Android thread, the C++ instrument application will not be affected.

[0050] A preferred embodiment, according to Figure 1 The software architecture also includes the following method for allocating CPU resources to systems with different functional safety levels: The Cgroup method in Linux technology is used to dynamically allocate CPU resources for systems with higher functional levels and systems with lower functional safety levels. This allows sufficient CPU resources to be allocated to systems with higher functional levels, and even allows a certain CPU core to be designated for use only by systems with higher functional levels. This ensures that systems with higher functional levels run reliably, smoothly, and with low latency.

[0051] The following example illustrates how to ensure that the 3D instrument cluster application is not affected by the CPU resource usage of the Android JAVA application, which causes the cluster to freeze and drop frames.

[0052] This solution uses the Cgroup method in Linux technology to dynamically allocate CPU resources to the native layer C++ instrument and Android Java application. In this way, sufficient CPU resources can be allocated to the C++ instrument application alone, and even a certain CPU core can be designated for use only by the C++ instrument application. This ensures that the instrument application runs reliably, smoothly and with low latency.

[0053] The beneficial technical effects of the present invention are: The fault tolerance time interval FTTI is short, and it only takes about 1 second to enter the safe state. The same short time can also be used to quickly start the instrument display, which is about one-fifth of the time under the virtualization solution; the performance in the safe state is good. Generally, when a single cortex-A core runs the function of the safe state, its performance is often more than 10 times stronger than the MCU of the external cortex-M core; the cancellation of hard isolation or redundancy has achieved cost reduction, eliminating the OSD chip and Flash in the instrument screen, and reducing the MCU specifications of the instrument screen; canceling virtualization improves system performance. Generally, virtualization will cause a significant loss of CPU and GPU computing power; and this method does not conflict with other existing methods and can be used in combination when needed. In addition, this method also uses the Namespace method to isolate the instrument and Android Java application to improve the reliability of the instrument. In addition, this method also uses the Cgroup method to allocate sufficient CPU resources to the instrument, ensuring that the instrument application runs reliably, smoothly and with low latency.

[0054] By using the method of the present invention and eliminating the methods of increasing costs by virtualization and hard isolation, the advantages and disadvantages of various methods are compared below. It can be seen that the present method has significant advantages in the field of cockpit domain controllers.

[0055]

[0056] The preferred specific embodiments of the present invention are described in detail above. It should be understood that a person skilled in the art can make many modifications and changes based on the concept of the present invention without creative work. Therefore, any technical solution that can be obtained by a person skilled in the art through logical analysis, reasoning or limited experiments based on the concept of the present invention on the basis of the prior art should be within the scope of protection determined by the claims.

Claims

1. A method for implementing functional safety of a multi-core processor chip, characterized in that: The steps include: S10, Bootloader starts loading the operating system kernel; S20, the multi-core processor continues to occupy one or more CPU cores and a portion of memory in the Bootloader to take over fast startup or security-related tasks; S30: The operating system kernel only takes over part of the CPU cores and memory, leaving one CPU core and part of the memory for the bootloader to continue using.

2. The method according to claim 1, characterized in that The following steps are also included: S22, Bootloader is responsible for displaying a layer; S31, the operating system kernel is responsible for displaying layers other than the Bootloader, and is responsible for the synthesis of all layers, including the layers that the Bootloader is responsible for displaying.

3. The method according to claim 1, characterized in that The following steps are also included: S21, load necessary drivers in the Bootloader including any one or more of display driver, audio driver, UART, I2C, I2S or SPI.

4. The method according to claim 1, characterized in that The following steps are also included: S23, determining whether to enter a safe state; S233, the operating system is initialized; S234, the operating system is initialized; S24, returning the driver to the operating system, wherein the driver includes any one or more of a display driver, an audio driver, UART, I2C, I2S or SPI.

5. The method according to claim 1, characterized in that The following steps are also included: S23, determining whether to enter a safe state; S233, determining whether the operating system has been initialized; S234, determining whether the operating system has been initialized; S24, once the operating system is initialized, the driver is returned to the operating system; S25, exit Bootloader state; S26, returns the CPU core and memory running the Bootloader to the operating system kernel for use.

6. The method according to claim 1, characterized in that The following steps are also included: S23, determining whether to enter a safe state; S231, if it is a safe state, running functions related to the safe state in the Bootloader; S232: If it is not in a safe state, it is determined to be in a fast startup mode, and functions related to the fast startup are executed.

7. The method according to claim 2, characterized in that By utilizing the characteristics of the display processor in the multi-core processor, multiple layers are selectively stitched together and then output to the display. S22 also includes the following steps: Bootloader is responsible for displaying the content of one of the layers; S31 also includes the following steps: the operating system kernel is responsible for displaying other layers and splicing and synthesizing the various layers, including the layers that the Bootloader is responsible for.

8. The method according to claim 1, characterized in that The following fault detection steps are also included: S40, the multi-core processor calculates the CRC value of each graphic in the graphic alarm area, and transmits the CRC value to the MCU through the communication mechanism between the MCU and the processor; S41, MCU reads the vehicle body CAN bus message and looks up the table to obtain the correct CRC value of the corresponding graphic; S42, MCU determines whether the CRC value of each graphic in the graphic alarm area conforms to the current state of the vehicle body CAN bus; If it is in accordance with the current state of the vehicle body CAN bus, then return to step S40; if it is not in accordance with the current state of the vehicle body CAN bus, then determine whether it exceeds the limit value, if not, then return to step S40, if it exceeds, then proceed to the next step; S60, the MCU controls the multi-core processor to restart, the system is reloaded, and the process returns to step S10.

9. The method according to claim 1, characterized in that The following fault detection steps are also included: S50, the serializer detects whether the CRC of the entire image between each link of the image transmission is consistent, and detects whether there is a frozen frame, wherein the image transmission link includes: Transmission between multi-core processors and serializers; Transmission between the serializer and the deserializer; S51, if the serializer does not detect CRC inconsistency or frozen frame, return to step S50; S52, if the serializer detects that the CRC is inconsistent or the frame is frozen, the serializer triggers the multi-core processor to generate an interrupt through the GPIO; S53, the multi-core processor notifies the MCU of the fault through the communication mechanism between the multi-core processor and the MCU; S60, the MCU controls the multi-core processor to restart, the system is reloaded, and the process returns to step S10.

10. The method according to claim 1, characterized in that It also includes the following resource isolation methods for systems with different functional safety levels: The namespace method in Linux technology is used to isolate systems with higher functional levels and systems with lower functional safety levels.

11. The method according to claim 1, characterized in that It also includes the following method for allocating CPU resources to systems with different functional safety levels: The Cgroup method in Linux technology is used to dynamically allocate CPU resources for systems with higher functional levels and systems with lower functional safety levels. Sufficient CPU resources are allocated to systems with higher functional levels, and a certain CPU core is designated for use only by systems with higher functional levels, so that systems with higher functional levels can run reliably, smoothly and with low latency.

Images