Double-trigger independent restarting method, device and equipment for SoC (System on Chip) chip domain of in-vehicle infotainment system
By introducing a dual-path restart triggering mechanism in the vehicle infotainment SoC chip domain, the adaptability and flexibility issues of the restart control method in the existing technology are solved, and the system can achieve stable recovery and efficient restart in the event of a fault, thereby improving the reliability and security of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SIENGINE TECH CO LTD
- Filing Date
- 2026-04-14
- Publication Date
- 2026-05-15
AI Technical Summary
Existing vehicle infotainment SoC chip domain restart control methods have shortcomings in system adaptability, resource management, exception handling, and multi-core communication synchronization efficiency. They are difficult to extend to different operating system scenarios, and the restart mechanism is not flexible enough to cope with complex fault scenarios.
A dual-path restart triggering mechanism is adopted, including an active notification triggering mechanism and a heartbeat fallback triggering mechanism. Through the collaborative work of the SCP domain and AP domain, the AP domain can be restarted independently, ensuring stable system recovery in the event of a failure.
It improves the reliability of restart triggering and the stability of the system, ensures stable operation of the system in complex environments, reduces restart time, avoids resource conflicts, and improves the flexibility and controllability of the system.
Smart Images
Figure CN122044951A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of automotive infotainment chips, specifically to a dual-trigger independent restart method, apparatus, and device for automotive infotainment SoC chip domains. Background Technology
[0002] Currently, in the restart control related to the System-on-Chip (SoC) chip domain of automotive infotainment systems, the vehicle control device adopts a Hypervisor architecture, on which a first operating system (monolithic kernel, such as Linux) and a second operating system (microkernel, such as RTOS) run. Restart conditions are determined by acquiring first and second test information, enabling independent restart of the first operating system. When the first test information is met, the first operating system restarts autonomously; when the second test information is met, the second operating system triggers the restart of the first operating system. If autonomous restart fails, a forced restart is performed. However, this restart control method has limited system adaptability, mainly targeting the specific architecture and operating system combination of the vehicle control device. It is difficult to extend to other types of devices or scenarios with different operating system combinations. Furthermore, resource management is not granular enough, failing to deeply consider the release and reallocation of system resources (such as memory and network connections) during the restart process, which may affect subsequent system operation. Additionally, exception handling is not comprehensive enough, only focusing on abnormal operating status of the first operating system, with inadequate mechanisms for handling other abnormal situations such as hardware failures and resource conflicts.
[0003] Another restart control method involves building a general system comprising an ARCH layer (architectural support layer) and a BSP layer (board support package). The main CPU runs Linux, while other CPUs run SylixOS. Hardware resource configurations are modified using automated configuration tools, CPU running status is detected via heartbeat packets, cache is partitioned, and registers are configured to eliminate inter-core broadcasts, enabling independent restarts between multiple cores. However, this restart control method is highly dependent on a specific operating system. The system is designed with Linux running on the main core and SylixOS running on the slave cores. Changing the operating system requires redesign and adaptation. Furthermore, the restart mechanism is not flexible enough, relying solely on whether it's an abnormal restart and the CPU's resource usage to determine whether to initialize hardware resources, which cannot handle complex fault scenarios. Additionally, it lacks optimization for inter-core communication and synchronization, only addressing inter-core broadcast issues; communication and synchronization efficiency needs improvement in multi-core data sharing and collaborative work scenarios.
[0004] Therefore, how to effectively control the restart of the vehicle's SoC chip domain has become an urgent problem to be solved. Summary of the Invention
[0005] This application provides a dual-trigger independent restart method, apparatus, and device for the vehicle infotainment SoC chip domain, which can greatly improve the reliability of restart triggering, effectively cope with various situations that may cause system abnormalities, and promptly initiate the restart process to restore normal system operation.
[0006] In a first aspect, embodiments of this application provide a dual-trigger independent restart method for a vehicle infotainment SoC chip domain, implemented based on a multi-domain architecture of the vehicle infotainment SoC. The dual-trigger independent restart method for the vehicle infotainment SoC chip domain includes: A dual-path restart triggering mechanism is created, which includes an active notification triggering mechanism and a heartbeat fallback triggering mechanism. This causes the active notification triggering mechanism and the heartbeat fallback triggering mechanism to run simultaneously; The active notification triggering mechanism is as follows: when the AP domain detects a predictable fault, it notifies the SCP domain, and the SCP domain performs resource reset and mirror copying operations before controlling the AP domain to restart. The heartbeat fallback trigger mechanism involves the AP domain periodically sending heartbeat packets to the SCP domain, and the SCP domain controlling the AP domain to restart based on the heartbeat packet reception status.
[0007] In conjunction with the first aspect, in one implementation method, The multi-Domain architecture of the vehicle infotainment SoC includes the AP domain, SCP domain, and functional domain; The functional domains include the RP domain, DSP domain, and CP domain; The AP domain is the object being restarted, running an operating system, while the SCP domain is the restart control entity, running an RTOS.
[0008] In conjunction with the first aspect, in one implementation method, the proactive notification triggering mechanism specifically includes: When the Kernel in the AP domain detects a predictable fault, it sends a fault notification to the RTOS MPrunning in the SCP domain via an interrupt signal. The SCP domain receives a fault notification, triggering a reset of the AP domain's Cores and DSU, and executing a copy of the Gold Edition BL31 image; The SCP domain uses core configuration commands to guide the AP domain to reload BL31, BL33, Kernel, and operating system in sequence, thus completing the AP domain restart.
[0009] In conjunction with the first aspect, in one implementation, triggering the reset of the AP domain's Cores and DSU, and executing the replication of the Gold Edition BL31 image, specifically includes: Trigger a reset of the Cores and DSU of the AP domain to reset the AP domain-specific resources, including the core processor and DSU bus; Perform a copy of the Gold Edition BL31 image to replace the runtime BL31 image.
[0010] In conjunction with the first aspect, in one implementation method, the heartbeat fallback trigger mechanism specifically includes: The AP domain periodically sends heartbeat packets to the SCP domain and periodically checks whether the SCP domain receives the heartbeat packet within a preset time: If so, then no action will be taken; If not, the SCP domain will proactively trigger the restart of the AP domain, forcibly restarting the AP domain.
[0011] In conjunction with the first aspect, in one implementation, the SCP domain actively triggers the restart of the AP domain, forcibly restarting the AP domain, specifically including: The SCP domain actively guides the AP domain to reload BL31, BL33, Kernel, and operating system in sequence through core configuration commands, forcibly completing the AP domain restart.
[0012] In conjunction with the first aspect, in one implementation method, During the AP domain restart process, the SCP domain, RP domain, DSP domain, and CP domain continue to operate independently.
[0013] Secondly, embodiments of this application provide a dual-trigger independent restart device for the vehicle infotainment SoC chip domain, the dual-trigger independent restart device for the vehicle infotainment SoC chip domain comprising: A module is created to create a dual-path restart triggering mechanism, which includes an active notification triggering mechanism and a heartbeat fallback triggering mechanism. An execution module, which is used to drive the active notification triggering mechanism and the heartbeat fallback triggering mechanism to run simultaneously; The active notification triggering mechanism is as follows: when the AP domain detects a predictable fault, it notifies the SCP domain, and the SCP domain performs resource reset and mirror copying operations before controlling the AP domain to restart. The heartbeat fallback trigger mechanism involves the AP domain periodically sending heartbeat packets to the SCP domain, and the SCP domain controlling the AP domain to restart based on the heartbeat packet reception status.
[0014] In conjunction with the second aspect, in one implementation method, The multi-Domain architecture of the vehicle infotainment SoC includes the AP domain, SCP domain, and functional domain; The functional domains include the RP domain, DSP domain, and CP domain; The AP domain is the object being restarted, running an operating system; the SCP domain is the restart control entity, running an RTOS. During the AP domain restart process, the SCP domain, RP domain, DSP domain, and CP domain continue to operate independently.
[0015] Thirdly, embodiments of this application provide a dual-trigger independent restart device for the vehicle infotainment SoC chip domain. The dual-trigger independent restart device for the vehicle infotainment SoC chip domain includes a processor, a memory, and a dual-trigger independent restart program for the vehicle infotainment SoC chip domain stored in the memory and executable by the processor. When the dual-trigger independent restart program for the vehicle infotainment SoC chip domain is executed by the processor, it implements the steps of the dual-trigger independent restart method for the vehicle infotainment SoC chip domain described above.
[0016] The beneficial effects of the technical solutions provided in this application include: (1) Strong architecture adaptability: At the architecture level, it can be well adapted to the multi-domain hardware isolation architecture of the vehicle SoC, ensuring the stable operation of the system in the complex vehicle hardware environment, and providing a basic guarantee for the reliability and compatibility of the vehicle system. (2) Reliable restart triggering mechanism: The dual-path triggering mechanism (active notification + heartbeat backup) is adopted. This dual protection method greatly improves the reliability of restart triggering, can effectively deal with various situations that may cause system abnormalities, and promptly start the restart process to restore the normal operation of the system; (3) Restart execution process optimization: Through the resource pre-cleaning + underlying link loading process led by SCP, the restart process is made more orderly and efficient. Resource pre-cleaning can avoid conflicts and errors caused by resource occupation during the restart process, while underlying link loading ensures that the critical links of the system can be restored quickly and correctly, reducing restart time and instability factors after system recovery. (4) Effective isolation protection: Interference-free restart is achieved under Domain-level hardware isolation, ensuring the independence between different functional domains during the restart process, avoiding the impact of restart operation on other normally operating domains, and improving the stability and security of the entire vehicle system; (5) Provide multiple restart control methods: This application not only provides an independent restart control method for the AP domain of the vehicle SoC chip, but also provides a backup restart method for the AP domain of the vehicle SoC based on heartbeat detection, a restart system for the AP domain of the vehicle SoC with multi-domain isolation, and a resource control method for restarting the AP domain of the vehicle SoC. These diverse methods can meet the vehicle restart control needs under different scenarios and requirements, and improve the flexibility and controllability of the system. Attached Figure Description
[0017] Figure 1 This is a flowchart illustrating the dual-trigger independent restart method for the vehicle infotainment SoC chip domain in this application; Figure 2A schematic diagram of the multi-domain architecture of an in-vehicle infotainment SoC; Figure 3 This is a schematic diagram of the functional module of the dual-trigger independent restart device in the vehicle infotainment SoC chip domain of this application; Figure 4 This is a schematic diagram of the hardware structure of the dual-trigger independent restart device in the vehicle infotainment SoC chip domain of this application. Detailed Implementation
[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0019] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.
[0020] SoC: System on Chip, an integrated circuit that integrates all or most system components, such as processor, memory, peripherals, and communication interfaces, on a single chip.
[0021] Domain: A domain typically refers to a responsibility area or security / functional partition within the architecture of a system or component. It divides the system into several isolated but collaborative parts.
[0022] AP domain: Application Processor domain, in the SoC architecture, is the processing domain responsible for executing application layer and operating system tasks. It typically includes the main processor and its cache, memory system, and peripheral control unit. The AP domain is responsible for the operation and management of the operating system, applications, and most general computing workloads.
[0023] SCP Domain: System Control Processor. The SCP domain is an independent or semi-independent subsystem within the SoC, responsible for the centralized management of the control functions of the entire system. It typically does not undertake high-performance computing tasks (these tasks are handled by the AP domain or CPU / HAL), but focuses on system-level coordination, routing of control signals, clock and power management, low-level peripheral control, system initialization, and security and access control of other domains.
[0024] RP Domain: Real-Time Processor. The RP domain is a processing subsystem in the SoC / system architecture specifically designed to handle real-time tasks and deterministic timing requirements. Compared to general application processing domains (such as AP / CPU), the RP focuses on completing tasks under strict time constraints, ensuring the predictability of the worst-case execution time (WCET) of tasks, and low-latency interrupt / event response.
[0025] DSP Domain: Digital Signal Processor. The DSP domain is a subsystem in a SoC / multi-domain architecture specifically designed for efficiently performing digital signal processing tasks. It typically features a dedicated processing core, a custom instruction set, efficient multiply-accumulate units, and optimizations for workloads such as real-time communication, audio / video encoding / decoding, and sensor signal processing.
[0026] Cluster Processor (CP) is a computing subsystem within a SoC / multi-core system architecture, consisting of one or more relatively independent processing clusters. A cluster processor typically comprises several smaller processing cores, potentially sharing cache, memory subsystems, and peripheral interfaces, and is specifically designed to handle highly parallel and communication-intensive workloads. Unlike a single large-core AP / CPU, the CP domain is designed with high throughput, energy efficiency, and scalability in mind.
[0027] ARCH: Architecture, the overall design of a system or processor, including instruction set, memory model, module partitioning, etc.
[0028] BSP: Board Support Package, provides low-level initialization, device drivers, bootloader and hardware abstraction layer for a specific hardware platform, enabling the upper-level operating system or application to run on that hardware.
[0029] The Linux kernel is an open-source, portable operating system kernel responsible for core functions such as hardware abstraction, resource management, process / thread scheduling, interrupt handling, memory management, device drivers, and the file system. It typically runs on an application processor (AP) or CPU, providing general services for upper-layer applications and interrupt-intensive tasks.
[0030] CPU: Central Processing Unit, the core unit that executes instructions and controls computation.
[0031] Microkernel: A minimalist kernel design. Its core responsibilities typically include process / thread management, IPC, basic scheduling and interrupt handling, while other services are implemented in user space to improve modularity and security.
[0032] RTOS: Real-Time Operating System, provides deterministic task scheduling and interrupt latency to meet strict timing requirements.
[0033] Hypervisor architecture: The Hypervisor architecture allows multiple virtual machines to run in parallel on the same physical hardware, providing resource virtualization, isolation, and management capabilities.
[0034] Cache: A cache is a high-speed storage located between the processor and memory, used to reduce access latency and improve throughput. It is usually divided into L1, L2, L3 and other levels.
[0035] ATF: ARM Trusted Firmware, an open-source firmware framework for the ARM architecture, responsible for security initialization, boot phase control, and basic support for the Trust Engine during the early stages of the boot sequence. It typically includes PSCI, the EL3 runtime environment, and exception handling, serving as the primary boot firmware to provide consistent security and initialization services for subsequent boot phases (such as BL31 / BL32 / BL33, operating system boot, etc.).
[0036] BL31: Boot Loader stage 31, a boot stage in the ARM Trusted Firmware architecture, running at EL3 (exception level 3), responsible for initializing the system, setting the boundary between the secure and insecure worlds, and booting into the next stage (such as BL32, BL33). It typically carries the core runtime of Trusted Firmware.
[0037] BL32: Boot Loader stage 32. In the ARM Trusted Firmware architecture, BL32 is responsible for loading and starting trusted world components at the PTA (Protection Trusted Archive) level, such as Trusted Execution Environments (TEEs, such as the TrustZone secure world). BL32 runs within a protected secure world.
[0038] UBOOT: Short for U-Boot (Universal Boot Loader), a common open-source bootloader responsible for hardware initialization and loading the operating system kernel or root file system after the system powers on. It features rich hardware support, scripted booting, and network booting capabilities, and is widely used in embedded devices.
[0039] BL33: Boot Loader stage 33. In the ARM Trusted Firmware architecture, BL33 typically serves as the boot loading stage in the insecure world, responsible for switching the system from the secure world to the insecure world and starting the main operating system kernel (such as Linux / Android). BL33 runs at EL1 or a lower exception level.
[0040] Android: The Android operating system is a Linux-based mobile operating system designed for smartphones, tablets, and embedded devices. It includes the kernel, system services, application framework, application layer, and HAL / Vendor implementations for interacting with device hardware.
[0041] DSU: DynamIQ Shared Unit. A DSU is a key shared resource subsystem in the DynamIQ architecture, typically referring to a collection of hardware units shared and accessed uniformly across one or more clusters. It is responsible for resolving issues related to data sharing between clusters, cache coherency, memory access scheduling, and bus / interconnect resource allocation. Simply put, the DSU is the "core infrastructure for achieving cluster-level sharing and collaborative operation."
[0042] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.
[0043] Firstly, this application provides a dual-trigger independent restart method for the vehicle infotainment SoC chip domain, which can solve the problem of restart effectiveness when the vehicle infotainment SoC AP domain fails, lacking proactive notification before failure and resource pre-cleaning; solve the problem of restart timeliness when the vehicle infotainment SoC AP domain completely crashes (without notification capability), lacking independent domain proactive fallback detection; and solve the problem of isolation when the AP domain restart conflicts with other domains (such as the CP domain) and affects the operation of other domains under the multi-Domain architecture of the vehicle infotainment SoC.
[0044] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the dual-trigger independent restart method for the vehicle infotainment SoC chip domain in this application. Figure 1 As shown, the dual-trigger independent reboot method for the vehicle infotainment SoC chip domain includes: S1: Create a dual-path restart triggering mechanism, which includes an active notification triggering mechanism and a heartbeat fallback triggering mechanism; S2: Drive the active notification triggering mechanism and the heartbeat fallback triggering mechanism to run simultaneously; Among them, the active notification trigger mechanism is that when the AP domain detects a warning fault, it notifies the SCP domain, and after the SCP domain performs resource reset and mirror replication operations, it controls the AP domain to restart. The heartbeat fallback trigger mechanism is that the AP domain periodically sends heartbeat packets to the SCP domain, and based on the heartbeat packet reception situation, the SCP domain controls the AP domain to restart.
[0045] See Figure 2 As shown, it is a schematic diagram of the multi-Domain architecture of the in-vehicle SoC, which includes an AP domain, an SCP domain, and a functional domain. The functional domain includes an RP domain, a DSP domain, and a CP domain.
[0046] The AP domain runs the Linux kernel and the Android system. Specifically, the AP domain, as the restart object, runs the operating system and needs to be independently restarted on the premise that the entire system does not lose power during a fault. Its startup link involves ATF (BL31, BL32) → BL33 (UBOOT) → Kernel → Android.
[0047] The SCP domain, as the restart control entity, runs RTOS and is responsible for receiving AP domain fault notifications, detecting AP domain heartbeats, performing partial resource resets of the AP domain, and startup link control.
[0048] Figure 2 In it, Power represents power supply, On represents startup, RESET represents restart, BOOT from ROM represents the first represents the first-level Boot that automatically runs after the SoC powers on and cold starts, and can also be called Boot stage1. This part of the code will automatically load the program image from the external storage chip according to the hardware configuration of the SoC; psci smccc is a privilege-level call related to power in ARM, psci is the ARM standard power state coordination interface, and smccc is the standard SMC call (SMC call convention) implemented in cooperation with ATF; Kernel represents the kernel; RP BOOT, DSP BOOT, CP BOOT, MP BOOT are the respective boot programs of each functional domain, used to boot their respective operating systems; RTOS RP running, DSP running, RTOS MP running are the corresponding operating systems of each functional domain and indicate that the application programs are in a normal running state; driving represents the special application programs that may run after the corresponding functional domain starts. The main responsibility of BL2 is to perform relevant initialization operations for the subsequent image loading and to be responsible for loading the subsequent firmware into RAM. In this application, the functions of BL21 plus BL22 are equivalent to BL2. BL21 mainly performs DDR initialization, and BL22 is mainly responsible for loading the subsequent firmware into RAM.
[0049] Furthermore, the proactive notification triggering mechanism specifically includes: S11: When the Kernel of the AP domain detects a predictable fault, it sends a fault notification to the RTOS MPrunning of the SCP domain via an interrupt signal. Specifically, when the kernel in the AP domain detects a predictable fault, such as a kernel crash, it sends a fault notification to the RTOS MP running in the SCP domain via an interrupt signal (such as Raise Interrupt). S12: The SCP domain receives a fault notification, triggers AP Cores / DSU RESET, and executes copy golden BL31; that is, after the SCP domain receives a fault notification, it triggers AP Cores / DSU RESET (i.e., resets the Cores and DSU of the AP domain, where Cores represents the cores), and executes copy golden BL31 (i.e., copies the golden version of BL31 image). For the Gold Edition BL31 image, the system will copy a copy of BL31 into the running memory during the first cold boot. This copied BL31 image is called the Gold Edition BL31 image. S13: The SCP domain, through core configuration commands, guides the AP domain to reload BL31, BL33, Kernel, and operating system sequentially, completing the AP domain reboot. That is, it guides the AP domain to reload BL31→BL33→Kernel→operating system, completing an independent AP domain reboot without affecting the normal operation of the SCP domain and other domains (RP, DSP, CP).
[0050] Furthermore, trigger AP Cores / DSU RESET and execute copy golden BL31, specifically including: S121: Trigger AP Cores / DSU RESET to reset AP domain-specific resources, including core processors and DSU buses; S122: Execute copy golden BL31 to replace the runtime BL31 image with copy golden BL31.
[0051] Specifically, this application includes a resource pre-cleaning mechanism. When the SCP domain triggers AP Cores / DSU RESET, it performs a reset operation on the AP domain-specific resources and replaces the runtime BL31 image by copying golden BL31 to avoid residual faults affecting the effectiveness of the restart.
[0052] Furthermore, this application also includes boot link control. The SCP domain precisely controls the boot process of the AP domain through core configuration instructions, ensuring that it strictly follows the vehicle SoC underlying boot sequence of BL31→BL33→Kernel→operating system, thus ensuring the complete recovery of the complex Linux+Android system.
[0053] Furthermore, the heartbeat safety net trigger mechanism specifically includes: The AP domain periodically sends heartbeat packets to the SCP domain and periodically checks whether the SCP domain receives the heartbeat packet within a preset time: If so, then no action will be taken; If not, the AP domain is determined to be completely down, meaning it has no notification capability. The SCP domain will then proactively trigger the restart of the AP domain, forcibly restarting the AP domain to ensure full coverage of fault scenarios.
[0054] Furthermore, the SCP domain actively triggers the restart of the AP domain, forcibly restarting the AP domain, specifically including: The SCP domain actively guides the AP domain to reload BL31, BL33, Kernel, and operating system in sequence through core configuration commands, forcibly completing the AP domain restart.
[0055] Furthermore, in one embodiment, during the AP domain restart process, the SCP domain, RP domain, DSP domain, and CP domain continue to operate independently.
[0056] This application also provides a domain-level isolation guarantee mechanism. Relying on the hardware domain isolation characteristics of the vehicle SoC, during the AP domain restart process, the SCP domain and other domains (RP, DSP, CP) remain independent and their resources do not interfere with each other. This ensures that the normal function of other domains is not affected when the AP domain is restarted independently, provided that the entire system is powered on.
[0057] The dual-trigger independent reboot method for the vehicle infotainment SoC chip domain in this application embodiment: Strong architectural adaptability: At the architectural level, it can be well adapted to the multi-domain hardware isolation architecture of the vehicle SoC, ensuring the stable operation of the system in the complex vehicle hardware environment and providing a basic guarantee for the reliability and compatibility of the vehicle system. Reliable restart triggering mechanism: It adopts a dual-path triggering mechanism (active notification + heartbeat backup). This dual protection method greatly improves the reliability of restart triggering, can effectively deal with various situations that may cause system abnormalities, and promptly start the restart process to restore normal system operation; Restart execution process optimization: Through the resource pre-cleaning and underlying link loading process led by SCP, the restart process is made more orderly and efficient. Resource pre-cleaning can avoid conflicts and errors caused by resource occupation during the restart process, while underlying link loading ensures that the critical links of the system can be restored quickly and correctly, reducing restart time and instability factors after system recovery. Effective isolation protection: Interference-free restart is achieved under domain-level hardware isolation, ensuring the independence between different functional domains during the restart process, avoiding the impact of restart operations on other normally operating domains, and improving the stability and security of the entire vehicle system; This application provides multiple restart control methods: It not only provides an independent restart control method for the AP domain of the vehicle infotainment SoC chip, but also provides a backup restart method for the AP domain of the vehicle infotainment SoC based on heartbeat detection, a restart system for the AP domain of the vehicle infotainment SoC with multi-domain isolation, and a resource control method for restarting the AP domain of the vehicle infotainment SoC. These diverse methods can meet the vehicle restart control needs under different scenarios and requirements, and improve the flexibility and controllability of the system.
[0058] Secondly, embodiments of this application also provide a dual-trigger independent restart device for the vehicle infotainment SoC chip domain.
[0059] In one embodiment, reference is made to Figure 3 , Figure 3 This is a functional module diagram of the dual-trigger independent restart device in the vehicle infotainment SoC chip domain of this application. Figure 3 As shown, the dual-trigger independent restart device in the vehicle infotainment SoC chip domain includes: a creation module and an execution module.
[0060] The creation module is used to create a dual-path restart triggering mechanism, which includes an active notification triggering mechanism and a heartbeat fallback triggering mechanism. The execution module is used to drive the active notification triggering mechanism and the heartbeat fallback triggering mechanism to run simultaneously. The active notification triggering mechanism notifies the SCP domain when the AP domain detects a predictable fault. The SCP domain performs resource reset and mirroring operations and then controls the AP domain to restart. The heartbeat fallback triggering mechanism involves the AP domain periodically sending heartbeat packets to the SCP domain. Based on the heartbeat packet reception status, the SCP domain controls the AP domain to restart.
[0061] In this application, the multi-domain architecture of the vehicle infotainment SoC includes an AP domain, an SCP domain, and a functional domain; the functional domain includes an RP domain, a DSP domain, and a CP domain; the AP domain is the object to be restarted and runs an operating system, while the SCP domain is the main restart control entity and runs an RTOS; during the restart process of the AP domain, the SCP domain, RP domain, DSP domain, and CP domain maintain independent operation.
[0062] Thirdly, this application provides a dual-trigger independent restart device for the vehicle infotainment SoC chip domain. The dual-trigger independent restart device for the vehicle infotainment SoC chip domain can be a personal computer (PC), a laptop computer, a server, or other devices with data processing capabilities.
[0063] Reference Figure 4 , Figure 4 This is a schematic diagram of the hardware structure of the dual-trigger independent restart device in the vehicle infotainment SoC chip domain involved in the embodiments of this application. In this embodiment, the dual-trigger independent restart device in the vehicle infotainment SoC chip domain may include a processor, memory, communication interface, and communication bus.
[0064] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.
[0065] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces. These interfaces are used for interconnecting devices within the dual-trigger independent restart device of the vehicle infotainment SoC chip domain, as well as for interconnecting the dual-trigger independent restart device of the vehicle infotainment SoC chip domain with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.
[0066] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.
[0067] The processor can be a general-purpose processor, which can call the dual-trigger independent restart program of the vehicle infotainment SoC chip domain stored in the memory and execute the dual-trigger independent restart method of the vehicle infotainment SoC chip domain provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the dual-trigger independent restart program of the vehicle infotainment SoC chip domain is called can be referred to the various embodiments of the dual-trigger independent restart method of the vehicle infotainment SoC chip domain of this application, and will not be repeated here.
[0068] Those skilled in the art will understand that Figure 4 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0069] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.
[0070] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.
[0071] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.
[0072] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.
[0073] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.
[0074] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.
Claims
1. A dual-trigger independent restart method for a vehicle infotainment SoC chip domain, implemented based on a multi-domain architecture of the vehicle infotainment SoC, characterized in that, The dual-trigger independent reboot method for the vehicle infotainment SoC chip domain includes: A dual-path restart triggering mechanism is created, which includes an active notification triggering mechanism and a heartbeat fallback triggering mechanism. This causes the active notification triggering mechanism and the heartbeat fallback triggering mechanism to run simultaneously; The active notification triggering mechanism is as follows: when the AP domain detects a predictable fault, it notifies the SCP domain, and the SCP domain performs resource reset and mirror copying operations before controlling the AP domain to restart. The heartbeat fallback trigger mechanism involves the AP domain periodically sending heartbeat packets to the SCP domain, and the SCP domain controlling the AP domain to restart based on the heartbeat packet reception status.
2. The dual-trigger independent restart method for a vehicle infotainment SoC chip domain as described in claim 1, characterized in that: The multi-Domain architecture of the vehicle infotainment SoC includes the AP domain, SCP domain, and functional domain; The functional domains include the RP domain, DSP domain, and CP domain; The AP domain is the object being restarted, running an operating system, while the SCP domain is the restart control entity, running an RTOS.
3. The dual-trigger independent restart method for a vehicle infotainment SoC chip domain as described in claim 2, characterized in that, The specific mechanisms for triggering proactive notifications include: When the Kernel of the AP domain detects a predictable fault, it sends a fault notification to the RTOS MP running in the SCP domain via an interrupt signal. The SCP domain receives a fault notification, triggering a reset of the AP domain's Cores and DSU, and executing a copy of the Gold Edition BL31 image; The SCP domain uses core configuration commands to guide the AP domain to reload BL31, BL33, Kernel, and operating system in sequence, thus completing the AP domain restart.
4. The dual-trigger independent restart method for a vehicle infotainment SoC chip domain as described in claim 3, characterized in that, The triggering of resetting the Cores and DSU of the AP domain and executing the replication of the Gold Edition BL31 image specifically includes: Trigger a reset of the Cores and DSU of the AP domain to reset the AP domain-specific resources, including the core processor and DSU bus; Perform a copy of the Gold Edition BL31 image to replace the runtime BL31 image.
5. The dual-trigger independent restart method for a vehicle infotainment SoC chip domain as described in claim 2, characterized in that, The heartbeat fallback trigger mechanism specifically includes: The AP domain periodically sends heartbeat packets to the SCP domain and periodically checks whether the SCP domain receives the heartbeat packet within a preset time: If so, then no action will be taken; If not, the SCP domain will proactively trigger the restart of the AP domain, forcibly restarting the AP domain.
6. The dual-trigger independent restart method for a vehicle infotainment SoC chip domain as described in claim 5, characterized in that, The SCP domain actively triggers the restart of the AP domain, forcibly restarting the AP domain, specifically including: The SCP domain actively guides the AP domain to reload BL31, BL33, Kernel, and operating system in sequence through core configuration commands, forcibly completing the AP domain restart.
7. The dual-trigger independent restart method for a vehicle infotainment SoC chip domain as described in claim 2, characterized in that: During the AP domain restart process, the SCP domain, RP domain, DSP domain, and CP domain continue to operate independently.
8. A dual-trigger independent restart device for a vehicle infotainment SoC chip domain, implemented based on a multi-domain architecture of the vehicle infotainment SoC, characterized in that, The dual-trigger independent restart device of the vehicle SoC chip domain includes: A module is created to create a dual-path restart triggering mechanism, which includes an active notification triggering mechanism and a heartbeat fallback triggering mechanism. An execution module, which is used to drive the active notification triggering mechanism and the heartbeat fallback triggering mechanism to run simultaneously; The active notification triggering mechanism is as follows: when the AP domain detects a predictable fault, it notifies the SCP domain, and the SCP domain performs resource reset and mirror copying operations before controlling the AP domain to restart. The heartbeat fallback trigger mechanism involves the AP domain periodically sending heartbeat packets to the SCP domain, and the SCP domain controlling the AP domain to restart based on the heartbeat packet reception status.
9. The dual-trigger independent restart device for a vehicle infotainment SoC chip domain as described in claim 8, characterized in that: The multi-Domain architecture of the vehicle infotainment SoC includes the AP domain, SCP domain, and functional domain; The functional domains include the RP domain, DSP domain, and CP domain; The AP domain is the object being restarted, running an operating system; the SCP domain is the restart control entity, running an RTOS. During the AP domain restart process, the SCP domain, RP domain, DSP domain, and CP domain continue to operate independently.
10. A dual-trigger independent reboot device for a vehicle infotainment SoC chip domain, characterized in that, The dual-trigger independent restart device for the vehicle infotainment SoC chip domain includes a processor, a memory, and a dual-trigger independent restart program for the vehicle infotainment SoC chip domain stored in the memory and executable by the processor. When the dual-trigger independent restart program for the vehicle infotainment SoC chip domain is executed by the processor, it implements the steps of the dual-trigger independent restart method for the vehicle infotainment SoC chip domain as described in any one of claims 1 to 7.