A method for booting up a multi-core heterogeneous SoC and a multi-core heterogeneous SoC

Abstract

This application provides a multi-core heterogeneous SoC boot method and a multi-core heterogeneous SoC, relating to the field of chip technology. The multi-core heterogeneous SoC includes a boot module, a security domain, and a non-security domain. The security domain includes a watchdog module and a processing module. The method includes: the boot module determining whether to perform a rollback based on the attribute information of a first partition; if not, the watchdog module determining whether the operating system of the security domain has started within a preset first time period; if not, triggering a multi-core heterogeneous SoC restart; if the operating system of the security domain has started within the first time period, the processing module determining whether the non-security domain has started within a preset second time period; if not, triggering a multi-core heterogeneous SoC restart; if a rollback is performed, the boot module boots the multi-core heterogeneous SoC based on the attribute information of a second partition. This application can trigger a multi-core heterogeneous SoC restart, thereby achieving a rollback.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a multi-core heterogeneous SoC boot method and a multi-core heterogeneous SoC. Background Technology

[0002] Multi-core heterogeneous SoCs (System-on-Chips) are widely used in key areas such as smart terminals, automotive electronics, and industrial control due to their high computing power and multi-task parallel processing capabilities. These SoCs typically integrate multiple hardware domains, including a non-security domain responsible for business processing and a security domain responsible for system security monitoring. These different functional domains work together to achieve complex system functions. In practical applications of multi-core heterogeneous SoCs, image upgrades are a crucial step in ensuring system function iteration and vulnerability patching. Currently, most mainstream upgrade solutions adopt an A / B dual-partition architecture, storing the old and new images in two independent partitions to enable rollback in case of upgrade failure.

[0003] However, in actual applications, various faults often prevent multi-core heterogeneous SoCs from restarting, thus making it impossible to roll back. Summary of the Invention

[0004] This application is made in view of at least one of the above-mentioned technical problems existing in the prior art. This application can trigger a multi-core heterogeneous SoC restart and thus achieve rollback.

[0005] In a first aspect, embodiments of this application provide a boot method for a multi-core heterogeneous SoC, wherein the multi-core heterogeneous SoC includes a boot module, a security domain, and a non-security domain, and the security domain includes a watchdog module and a processing module. The method includes: The boot module determines whether to perform a rollback based on the attribute information of the first partition; If no rollback is performed, the watchdog module determines whether the operating system of the security domain has started within a preset first time period. If not, it triggers the multi-core heterogeneous SoC to restart. If the operating system of the security domain has started within the first time period, the processing module determines whether the non-security domain has started within the preset second time period. If not, it triggers the multi-core heterogeneous SoC to restart. If a rollback is performed, the boot module starts the multi-core heterogeneous SoC based on the attribute information of the second partition.

[0006] Secondly, embodiments of this application provide a multi-core heterogeneous SoC, including: a boot module, a security domain and a non-security domain, wherein the security domain includes a watchdog module and a processing module; The boot module is configured to determine whether to perform a rollback based on the attribute information of the first partition; if a rollback is performed, the multi-core heterogeneous SoC is started based on the attribute information of the second partition. The watchdog module is configured to determine whether the operating system of the security domain has started within a preset first time period if no rollback is performed; if not, to trigger the multi-core heterogeneous SoC to restart. The processing module is configured to determine whether the non-security domain has started within a preset second time period if the operating system of the security domain has already started within the first time period; if not, to trigger the multi-core heterogeneous SoC to restart.

[0007] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory stores an executable program, and the processor executes the executable program to perform the steps of the method as described in any of the preceding claims.

[0008] This application provides a multi-core heterogeneous SoC boot method and a multi-core heterogeneous SoC. It improves system fault tolerance through layered monitoring. Specifically, the first layer of monitoring is performed by a watchdog module monitoring the operating system boot of the secure domain, and the second layer of monitoring is performed by a processing module monitoring the boot of the non-secure domain. After an abnormal restart of the multi-core heterogeneous SoC, the boot module re-executes the rollback determination, preventing the system from falling into an infinite loop of exception and restart, thus achieving a complete fault-tolerant chain of exception, restart, rollback, and recovery. The watchdog module is independent hardware built into the secure domain and does not depend on any software to run. Even if the operating system in the secure domain fails to boot, it can still trigger a hardware restart. The boot module is independent of the secure and non-secure domains, and the rollback determination is not affected by image anomalies, ensuring decision reliability from the bottom layer. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart of a multi-core heterogeneous SoC boot method provided in one embodiment of this application; Figure 2 This is a flowchart of a multi-core heterogeneous SoC boot method provided in another embodiment of this application; Figure 3 This is a schematic diagram of a multi-core heterogeneous SoC provided in one embodiment of this application. Detailed Implementation

[0011] To enable those skilled in the art to better understand the technical solutions of the embodiments of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] like Figure 1 As shown in the figure, this application provides a boot method for a multi-core heterogeneous SoC. The multi-core heterogeneous SoC includes a boot module, a security domain, and a non-security domain. The security domain includes a watchdog module and a processing module. The method includes: Step 101: The boot module determines whether to perform a rollback based on the attribute information of the first partition. If yes, proceed to step 106; otherwise, proceed to step 102.

[0013] The boot module is a hardware core independent of the secure and non-secure domains. It executes the above steps by running a bootloader. The first partition is the new partition in the A / B dual-partition architecture, such as the new partition after the image upgrade. The second partition is the old partition in the A / B dual-partition architecture, such as the old partition before the image upgrade.

[0014] The attribute information may include the startup identifier and the cumulative time spent on restart verification. The attribute information may also include the startup identifier and the remaining number of restarts. The specific content of the attribute information can be adjusted according to actual business needs. For rollback determination based on the startup identifier and the cumulative time spent on restart verification, and rollback determination based on the startup identifier and the remaining number of restarts, please refer to the following embodiments.

[0015] The attribute information can also include an activation attribute, which indicates that the current partition is the preferred boot loader. This activation attribute is exclusive; only one partition (A or B) can have this attribute. The activation attribute allows the boot module to quickly identify the partition to be booted, avoiding boot chaos from multiple partitions. During rollback, only the activation attribute needs to be modified to complete the partition switch, simplifying the rollback logic and improving boot efficiency.

[0016] Step 102: The watchdog module determines whether the operating system of the security domain starts within a preset first time period. If so, proceed to step 103; otherwise, proceed to step 105.

[0017] The first duration, timeout1, can be configured permanently, meaning it's embedded in the watchdog module at the chip's factory. Alternatively, it can be configured dynamically. For example, if the boot module determines that a rollback is not to be performed, it can send a configuration instruction containing the first duration to the watchdog module.

[0018] After the watchdog module starts timing, it waits for the Safety OS in the security domain to send a feed command. If the feed command is received within timeout1, the startup is considered successful; otherwise, the startup is considered to have failed and a restart is triggered.

[0019] Step 103: The processing module determines whether the non-security domain is started within the preset second time period. If so, the current process is terminated; otherwise, step 104 is executed.

[0020] The processing module of the security domain, i.e., the security domain core, is the hardware core that runs the security domain. Non-security domains refer to application domains or application domains and their subdomains. The processing module loads a second timeout (timeout2), starts a software timer to monitor the startup status of the non-security domains, and if startup is not completed within timeout2, a SOC restart is triggered. The second timeout can be statically configured, i.e., embedded in the Safety OS and automatically loaded when the Safety OS starts; or it can be dynamically configured by the boot module or the non-security domain. After a successful application domain startup, it monitors the status of its subdomains. If all its subdomains have started, the application domain reports back to the security domain's processing module that both the application domain and its subdomains have started successfully.

[0021] Step 104: The processing module triggers a restart of the multi-core heterogeneous SoC.

[0022] Step 105: The watchdog module triggers a restart of the multi-core heterogeneous SoC.

[0023] Multi-core heterogeneous SoC reboot is a hardware-level global reboot.

[0024] Step 106: The boot module starts the multi-core heterogeneous SoC based on the attribute information of the second partition.

[0025] This application's embodiments enhance system fault tolerance through layered monitoring. Specifically, the first layer of monitoring, controlled by a watchdog module, monitors the startup of the operating system in the secure domain, while the second layer, controlled by a processing module, monitors the startup of the non-secure domain. After an abnormal reboot of a multi-core heterogeneous SoC, the boot module re-executes the rollback determination, preventing the system from entering an infinite loop of anomalies and reboots, thus achieving a complete fault-tolerant chain of anomalies, reboots, rollbacks, and recovery. The watchdog module is independent hardware built into the secure domain and does not rely on any software to operate; even if the operating system in the secure domain fails to boot, it can still trigger a hardware reboot. The boot module is independent of both the secure and non-secure domains, and its rollback determination is unaffected by image anomalies, ensuring decision reliability from the underlying layer.

[0026] In one embodiment of this application, the attribute information of the first partition includes: a boot identifier and the remaining number of reboots; The boot module determines whether to perform a rollback based on the attribute information of the first partition, including: The boot module determines whether the boot flag of the first partition indicates that the first partition has been booted by a multi-core heterogeneous SoC. If not, it determines whether the remaining number of reboots is 0. If the operating system of the security domain fails to start within the first time period, or the non-security domain fails to start within the second time period, the method further includes the following after triggering a multi-core heterogeneous SoC reboot: The boot module decrements the remaining number of restarts by 1.

[0027] The boot flag is essentially a Boolean or enumerated status flag used to indicate whether the first partition has successfully booted the SoC, serving as the basis for determining the partition's usability. The remaining reboot count is essentially a non-negative integer parameter. Its core function is to limit the maximum number of abnormal reboot retries allowed for the first partition, preventing the system from entering an infinite reboot loop. The initial value can be 1-5 times to adapt to different scenarios. The reboot count can be decremented immediately after a reboot, i.e., when the boot module reruns the bootloader after the SoC reboot is complete, the count is decremented before performing the rollback check. Alternatively, it can be decremented before rebooting; when the watchdog module or processing module triggers a reboot command, it first notifies the boot module to decrement the count before triggering the reboot.

[0028] This application embodiment uses a two-layer judgment logic of startup flag and remaining restart count to clarify the rule that partitions that fail to start are only allowed a limited number of retries, and a forced rollback is performed after the remaining restart count is exhausted, thus solving the problem of repeated restarts of abnormal partitions and the inability of the system to recover in traditional solutions.

[0029] In practical applications, the cumulative time spent on restart verification can also be used to determine whether to perform a rollback. Specifically, after the boot module determines that the first partition's boot flag is not bootable, it performs the following judgment: (1) Calculate the cumulative time taken for the first partition to restart and verify; (2) If the cumulative timeout is ≥60s (the cumulative timeout threshold for startup verification), determine to execute rollback; (3) If the cumulative time is less than 60 seconds, rollback will not be performed.

[0030] The decision to perform a rollback can also be determined by combining the cumulative time spent on restart verification and the remaining number of restarts. Specifically, after the boot module determines that the first partition's boot flag is not bootable, it performs the following checks: (1) Calculate the cumulative time taken for multiple restarts of the verification in the first partition; (2) If the cumulative timeout is ≥60s (the cumulative timeout threshold for startup verification), the rollback process will be executed regardless of whether the remaining number of restarts is 0; (3) If the cumulative time is less than 60 seconds, determine whether the remaining number of restarts is 0. If the remaining number of restarts is 0, execute the rollback process; otherwise, do not execute the rollback.

[0031] In one embodiment of this application, if the non-security domain is activated within a second duration, the method further includes: The non-security domain updates the boot identifier of the first partition; the updated boot identifier of the first partition indicates that the first partition has been booted by a multi-core heterogeneous SoC.

[0032] Once the boot flag is updated to indicate successful boot, the boot module reads this flag during subsequent SoC boots and directly determines that no rollback will be performed. There is no need to check the remaining reboot count, and the watchdog module or processing module no longer needs to perform timeout monitoring. The entire boot process skips the "retry-reboot-rollback" logic and directly enters the normal boot process, significantly reducing boot time.

[0033] In one embodiment of this application, the non-security domain includes: an application domain; The processing module determines whether the non-security domain starts within a preset second time period, including: The processing module determines whether it has received a startup notification from the application domain within the second time period.

[0034] If the processing module receives a startup notification from the application domain within the second time period, it indicates that the non-security domain has started within the second time period. The processing module can then disable the Timer, terminate the monitoring logic, and allow the non-security domain to enter normal operation. Otherwise, if it is determined that the non-security domain has not started within the second time period, the processing module will trigger a full domain restart.

[0035] Non-security domains refer to functional domains in a multi-core heterogeneous SoC other than security domains. In this application embodiment, it refers to the application domain, typically the AP1 master control domain, which is the core domain carrying core business logic. Startup notifications can be transmitted through inter-core communication or bus communication.

[0036] The application domain is the core of the non-security domain, and its startup state directly determines the availability of the SoC's core services. By using startup notifications as the basis for judgment, there is no need for processing modules to traverse the states of all sub-modules in the non-security domain. This simplifies the judgment logic, reduces the computational overhead of processing modules, and ensures the availability of the SoC's most core service capabilities.

[0037] In one embodiment of this application, the non-security domain further includes: a subdomain of the application domain; The startup notification is sent to the operating system of the security domain after the application domain determines that all its subdomains have started.

[0038] The non-security domain follows a hierarchical structure of application domain and subdomains. The application domain is the core control unit of the non-security domain, while subdomains are functional sub-modules attached to the application domain, such as GPU subdomains, communication subdomains, and microcontroller subdomains, providing essential support for the application domain to complete its core business. Once the application domain confirms that all subdomains are running, it can send a startup notification immediately or wait until the subdomains have been running stably for a certain period before sending it. If any subdomain fails to start within a timeout period, the application domain determines that the non-security domain startup has failed, does not send a startup notification, and waits for the processing module to trigger a restart. In practical applications, subdomains can also be divided into core subdomains and non-core subdomains. Only the startup status of the core subdomains needs to be monitored; if so, a startup notification is sent.

[0039] In this application embodiment, the application domain uniformly summarizes the subdomain status, so that the determination logic of the non-security domain startup status is fully adapted to the hierarchical architecture characteristics of multi-core heterogeneous SoC, avoiding the processing module from communicating directly with multiple subdomains and reducing the complexity of cross-domain interaction.

[0040] In one embodiment of this application, the application domain determines whether its subdomains are all started through inter-core communication, and the application domain sends a startup notification to the operating system of the security domain through inter-core communication.

[0041] The operating system in the security domain runs on the processing module. Inter-core communication is a hardware-level communication method built into the SoC. Compared with bus communication, it has lower latency and can strictly meet the timing constraints of the second duration, avoiding misjudgments caused by communication delays.

[0042] In one embodiment of this application, the boot module starts a multi-core heterogeneous SoC based on the attribute information of the second partition, including: The boot module determines whether the boot identifier of the second partition indicates that the second partition contains a bootloader. If so, it boots the multi-core heterogeneous SoC based on the bootloader of the second partition.

[0043] The attribute information may also include a boot identifier, which indicates whether the corresponding partition contains a bootloader.

[0044] The boot module reads the bootloader from the specified address in the second partition, transfers system control to the bootloader, and the bootloader loads the image in the second partition to complete the SoC boot. After booting, the boot module sets the activation attribute of the second partition to active and the first partition to inactive.

[0045] This application embodiment solves the problem that the system cannot boot at all when rolling back to a partition without a bootloader in the traditional rollback scheme by verifying the boot identifier. Only when the second partition has a valid bootloader will the rollback be performed.

[0046] In one embodiment of this application, if the operating system of the security domain has already started within a first duration, before the processing module determines whether the non-security domain has started within a preset second duration, the method further includes: The processing module controls the watchdog module to stop timing.

[0047] Specifically, the processing module can send a stop timing command to the watchdog module, and the watchdog module executes the command to clear the timeout1 timer register and disable the timeout1 timeout alarm logic.

[0048] This application clearly states that the watchdog module stops timing after the security domain has been successfully started but before the non-security domain monitoring begins. This is the only connecting action between the two core monitoring links, eliminating the timing overlap problem where the watchdog module is still timing timeout1 while the processing module has already started timeout2. This also avoids the two timing logics competing for hardware resources and eliminates monitoring logic confusion.

[0049] The following examples will use the OTA (Over-the-Air) scenario as an example to explain in detail the startup method of a multi-core heterogeneous SoC.

[0050] The first partition (partition A) is the OTA upgrade image area (for writing new images), and the second partition (partition B) is the backup area. Both partitions involve the following four attributes: Attribute 1 (available in both A and B partitions): Boot identifier, used to identify whether the corresponding partition has successfully booted the multi-core heterogeneous SoC. It is the core basis for determining whether to perform a rollback or terminate the retry. Attribute 2 (available for both A and B partitions): Remaining number of restarts. This is the preset maximum number of retries for a corresponding partition in case of a startup error. It is used to quantitatively control the retry opportunities for the corresponding partition to avoid infinite restarts. The number of retries is automatically reduced each time a restart is triggered due to a startup error in the partition. Attribute 3 (available in both A and B partitions): Boot identifier, used to identify whether the corresponding partition contains a boot loader, and is a prerequisite for booting the corresponding partition; Attribute 4 (Shared by A / B partitions, Exclusivity): Activation attribute, used to identify the current partition as the preferred boot partition. Its core feature is exclusivity, meaning that only one partition (A partition) or the second partition (B partition) can have this attribute at any given time. Before the OTA upgrade, the second partition is active, and the first partition is inactive. After the upgrade takes effect, the first partition becomes active, and the second partition becomes inactive. After the rollback, the second partition is restored to active, and the first partition remains inactive.

[0051] When the SoC is running normally, it receives OTA upgrade packages from the cloud, writes the new system image to the first partition, and obtains four partition attributes.

[0052] like Figure 2 As shown, the multi-core heterogeneous SoC boot method includes the following steps: Step 201: The boot module determines whether to perform a rollback.

[0053] After the OTA upgrade is completed, the SoC will automatically restart, the boot module will power on and initialize, and it will read the four attributes of the A / B partitions. It will first determine the preferred partition based on the active attribute, and then combine the boot identifier of the first partition and the remaining number of restarts to determine whether to perform a rollback according to the following logic: If the first partition is marked as booted: then the first partition is active and the second partition is inactive. The SoC will boot normally directly based on the first partition without needing to execute retry / rollback logic. If the boot flag for the first partition is "not booted": further verify the remaining reboot count for the first partition: Remaining reboot attempts > 0: Determine not to perform rollback, proceed to step 202 to verify the boot status of the new image in the first partition; Remaining reboot attempts = 0: Determine to perform rollback and proceed to step 204, where a rollback boot is performed based on the four attributes of the second partition.

[0054] Step 202: Start monitoring in the security domain.

[0055] The watchdog module starts with a preset first duration to monitor the startup status of the operating system in the security domain of the new image in the first partition; If the watchdog module does not detect the boot ready signal sent by the operating system of the security domain within the first time period, it triggers the multi-core heterogeneous SoC to restart. After restarting, the boot module decrements the remaining number of restarts of the first partition by 1 and persists the updated value, while keeping other attributes of partitions A / B unchanged, and returns to step 201 to re-execute the verification. If the watchdog module detects that the operating system of the security domain has started successfully within the first time period, the processing module of the security domain sends a stop timing command to the watchdog module, controlling the watchdog module to immediately terminate the first time period, clear the timing register, and exit the security domain monitoring mode; after the processing module completes the watchdog timing stop operation, it starts the preset second time period and enters the non-security domain startup monitoring process in step 203.

[0056] Step 203: Start monitoring in non-security domains.

[0057] The processing module monitors the startup status of the non-security domain, which includes the application domain and its subdomains, such as the vehicle-to-everything (V2X) communication subdomain and the display subdomain in the vehicle scenario. After the application domain starts, it determines whether its subdomains have all started through inter-core communication. Once it is confirmed that all subdomains have started and are ready, it sends a startup notification to the operating system of the security domain through inter-core communication.

[0058] The processing module determines whether the startup notification was received within the second time period: If no startup notification is received, the processing module triggers a multi-core heterogeneous SoC restart; the boot module decrements the remaining restart count of the first partition by 1, persists the data to storage, keeps other attributes of partitions A / B unchanged, and returns to step 201 for re-verification; If a startup notification is received, the processing module terminates the second duration timer and ends non-security domain monitoring; the application domain performs attribute update operations, and simultaneously updates the corresponding attributes of partitions A and B: the startup identifier of the first partition is updated from unbooted to booted, the remaining reboot count is reset to the preset value, and the activation attribute of the first partition is changed from unactivated to activated; the activation attribute of the second partition is simultaneously changed from activated to inactivated, while the startup identifier, remaining reboot count, and boot identifier of the second partition remain unchanged; all attributes are persistently stored; the multi-core heterogeneous SoC completes startup and enters normal operation. During subsequent startups, the boot module reads that the first partition is activated and directly starts normally based on the first partition, without triggering retry / rollback logic.

[0059] Step 204: The boot module performs a rollback boot based on the second partition attributes.

[0060] When the remaining number of reboots for the first partition decreases to 0, the boot module starts the multi-core heterogeneous SoC based on the attribute information of the second partition and executes the rollback process.

[0061] The boot module reads four attributes of the second partition. First, it determines whether the boot identifier of the second partition indicates that it contains a bootloader. If there is no bootloader, it triggers a SoC hardware alarm, such as lighting up a fault light in an automotive scenario, reporting a fault log to the cloud, and terminating the boot process. If there is a bootloader, the boot module loads the bootloader in the second partition.

[0062] The boot module loads the original image within the second partition sequentially based on the boot program of the second partition, completing the rollback boot.

[0063] After the rollback boot is complete, the boot module marks the OTA upgrade as failed and pushes the upgrade failure log to the cloud: the second partition remains active, the boot flag is "booted", the boot flag indicates that a valid bootloader is included, and the remaining number of reboots remains stable; the boot flag of the first partition remains "unbooted", the remaining number of reboots is reset to the preset value, and the boot flag indicates that a valid bootloader is included, so as to facilitate the next OTA upgrade retry; the SoC enters a stable operating state, and during subsequent boots, the boot module reads that the second partition is active and prioritizes booting from the second partition.

[0064] like Figure 3As shown, this application embodiment provides a multi-core heterogeneous SoC, including: a boot module 301, a security domain 302 and a non-security domain 303, wherein the security domain 302 includes a watchdog module 3021 and a processing module 3022; The boot module 301 is configured to determine whether to perform a rollback based on the attribute information of the first partition; if a rollback is performed, the multi-core heterogeneous SoC is started based on the attribute information of the second partition. The watchdog module 3021 is configured to determine whether the operating system of security domain 302 has started within a preset first time period if no rollback is performed; if not, trigger a multi-core heterogeneous SoC restart. The processing module 3022 is configured to determine whether the non-security domain 303 has started within a preset second time period if the operating system of the security domain 302 has started within the first time period. If not, it triggers a multi-core heterogeneous SoC restart.

[0065] In one embodiment of this application, the attribute information of the first partition includes: a boot identifier and the remaining number of reboots; The boot module 301 is configured to determine whether the boot flag of the first partition indicates that the first partition has booted the multi-core heterogeneous SoC. If not, it determines whether the remaining number of reboots is 0. If the operating system of the security domain 302 does not start within the first duration, or the non-security domain 303 does not start within the second duration, the remaining number of reboots is decremented by 1 after triggering the multi-core heterogeneous SoC reboot.

[0066] In one embodiment of this application, if a non-security domain starts within a second time period, the non-security domain 303 updates the startup identifier of the first partition; wherein, the updated startup identifier of the first partition indicates that the first partition has booted a multi-core heterogeneous SoC.

[0067] In one embodiment of this application, the non-security domain 303 includes: an application domain; Processing module 3022 determines whether a startup notification sent by the application domain has been received within the second time period.

[0068] In one embodiment of this application, the non-security domain 303 further includes: a subdomain of the application domain; and a startup notification, which is sent by the application domain to the operating system of the security domain after determining that all its subdomains have started.

[0069] In one embodiment of this application, the application domain determines whether its subdomains are all started through inter-core communication, and the application domain sends a startup notification to the operating system of security domain 302 through inter-core communication.

[0070] In one embodiment of this application, the boot module 301 determines whether the boot identifier of the second partition indicates that the second partition contains a boot program. If so, the multi-core heterogeneous SoC is booted based on the boot program of the second partition.

[0071] In one embodiment of this application, if the operating system of security domain 302 has started within a first duration, before the processing module 3022 determines whether the non-security domain has started within a preset second duration, the processing module 3022 controls the watchdog module 3021 to stop timing.

[0072] This application provides an electronic device, including a memory and a processor. The memory stores an executable program, and the processor executes the executable program to perform the steps of the methods described in any of the above embodiments.

[0073] In this application, "vehicle" can refer to "automobile," "vehicle," or "complete vehicle," or other similar terms, including general motor vehicles such as sedans, SUVs, MPVs, buses, trucks, and other freight or passenger vehicles; water transport vehicles including various boats and vessels; and aircraft, including hybrid vehicles, electric vehicles, gasoline vehicles, plug-in hybrid vehicles, fuel cell vehicles, and other alternative fuel vehicles. Hybrid vehicles refer to vehicles with two or more power sources, and electric vehicles include pure electric vehicles and range-extended electric vehicles; this application does not specifically limit their use.

[0074] It should be understood that in the embodiments of this application, the processor may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0075] It should also be understood that the memory mentioned in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Specifically, non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0076] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) is integrated into the processor.

[0077] It should be noted that the memories described herein are intended to include, but are not limited to, these and any other suitable types of memories.

[0078] In addition to the data bus, this bus may also include a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled "bus" in the diagram.

[0079] It should also be understood that the first, second, third, fourth and various numerical designations used herein are merely for descriptive convenience and are not intended to limit the scope of this application.

[0080] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0081] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0082] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0083] Those skilled in the art will recognize that the various illustrative logical blocks (ILBs) and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0084] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0085] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0086] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0087] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0088] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for booting a multi-core heterogeneous SoC, characterized in that, The multi-core heterogeneous SoC includes a boot module, a secure domain, and a non-secure domain. The secure domain includes a watchdog module and a processing module. The method includes: The boot module determines whether to perform a rollback based on the attribute information of the first partition; If no rollback is performed, the watchdog module determines whether the operating system of the security domain has started within a preset first time period. If not, it triggers the multi-core heterogeneous SoC to restart. If the operating system of the security domain has started within the first time period, the processing module determines whether the non-security domain has started within the preset second time period. If not, it triggers the multi-core heterogeneous SoC to restart. If a rollback is performed, the boot module starts the multi-core heterogeneous SoC based on the attribute information of the second partition.

2. The method as described in claim 1, characterized in that, The attribute information of the first partition includes: boot identifier and remaining restart count; The boot module determines whether to perform a rollback based on the attribute information of the first partition, including: The boot module determines whether the boot identifier of the first partition indicates that the first partition has booted the multi-core heterogeneous SoC. If not, it determines whether the remaining number of reboots is 0. If the operating system of the security domain does not start within the first time period, or the non-security domain does not start within the second time period, after triggering the multi-core heterogeneous SoC restart, the method further includes: The boot module decrements the remaining number of restarts by 1.

3. The method as described in claim 2, characterized in that, If the non-security domain is activated within the second duration, the method further includes: The non-security domain updates the boot identifier of the first partition; wherein, the updated boot identifier of the first partition indicates that the first partition has booted the multi-core heterogeneous SoC.

4. The method as described in claim 1, Its features are, The non-security domain includes: the application domain; The processing module determines whether the non-security domain is activated within a preset second time period, including: The processing module determines whether it receives a startup notification from the application domain within the second time period.

5. The method as described in claim 4, Its features are, The non-security domain further includes: subdomains of the application domain; The startup notification is sent to the operating system of the security domain after the application domain determines that all its subdomains have started.

6. The method as described in claim 4, characterized in that, in, The application domain determines whether all its subdomains are started through inter-core communication, and the application domain sends the start notification to the operating system of the security domain through inter-core communication.

7. The method as described in claim 1, characterized in that, The boot module starts the multi-core heterogeneous SoC based on the attribute information of the second partition, including: The boot module determines whether the boot identifier of the second partition indicates that the second partition contains a boot program. If so, it boots the multi-core heterogeneous SoC based on the boot program of the second partition.

8. The method as described in claim 1, characterized in that, If the operating system of the security domain has already started within the first duration, before the processing module determines whether the non-security domain has started within a preset second duration, the method further includes: The processing module controls the watchdog module to stop timing.

9. A multi-core heterogeneous SoC, characterized in that, include: The system comprises a boot module, a secure domain, and a non-secure domain, wherein the secure domain includes a watchdog module and a processing module. The boot module is configured to determine whether to perform a rollback based on the attribute information of the first partition. If a rollback is performed, the multi-core heterogeneous SoC is started based on the attribute information of the second partition; The watchdog module is configured to determine whether the operating system of the security domain has started within a preset first time period if no rollback is performed; if not, to trigger the multi-core heterogeneous SoC to restart. The processing module is configured to determine whether the non-security domain has started within a preset second time period if the operating system of the security domain has already started within the first time period; if not, to trigger the multi-core heterogeneous SoC to restart.

10. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores an executable program, and the processor executes the executable program to perform the steps of the method as described in any one of claims 1 to 8.

Images