CN117908969A - EFuse-based starting method, device and system of SoC system, soC chip and electronic equipment - Google Patents

EFuse-based starting method, device and system of SoC system, soC chip and electronic equipment Download PDF

Info

Publication number
CN117908969A
CN117908969A CN202211237064.4A CN202211237064A CN117908969A CN 117908969 A CN117908969 A CN 117908969A CN 202211237064 A CN202211237064 A CN 202211237064A CN 117908969 A CN117908969 A CN 117908969A
Authority
CN
China
Prior art keywords
subsystem
data
starting
power
mode
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211237064.4A
Other languages
Chinese (zh)
Inventor
徐伟龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Yunbao Intelligent Co ltd
Original Assignee
Shenzhen Yunbao Intelligent Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Yunbao Intelligent Co ltd filed Critical Shenzhen Yunbao Intelligent Co ltd
Priority to CN202211237064.4A priority Critical patent/CN117908969A/en
Publication of CN117908969A publication Critical patent/CN117908969A/en
Pending legal-status Critical Current

Links

Landscapes

  • Stored Programmes (AREA)

Abstract

The invention discloses a starting method of an SoC system based on eFuses, which comprises the following steps: when the SoC system is powered on, eFuse data stored in an eFuse memory and external power-on control word data are acquired; obtaining a corresponding starting mode according to the eFuse data and the power-on control word data, wherein each eFuse data and the power-on control word data combination corresponds to a starting mode in advance; and executing the power-on starting operation according to the starting execution sequence corresponding to the obtained starting mode. The invention also discloses a corresponding device, an SoC system, a chip and electronic equipment. By implementing the invention, a plurality of starting modes can be realized in one SoC system, so that the development efficiency of a chip can be improved, the development period of the chip can be shortened, the development cost of the chip can be reduced, and the competitiveness of the chip can be improved.

Description

EFuse-based starting method, device and system of SoC system, soC chip and electronic equipment
Technical Field
The present invention relates to the field of SoC (System on chip) starting technologies, and in particular, to a method and apparatus for starting an SoC System based on eFuse (ELECTRICAL FUSE, electrically programmable fuse), an SoC System, a chip, and an electronic device.
Background
The ARM open source SCP FIRMWARE is a SCP (System Control Processor ) BL1 (1 st level Boot Loader, first-level boot loader) located in ROM, and its main function is to move SCP BL2 (2 nd level Boot Loader, second-level boot loader) from an external nonvolatile device into SRAM (static random-Access memory). The SCP BL2 in the SRAM is used as a second-stage running program, and is guided by the SCP BL1 and jumps to the BL2 for further execution, and its main functions are to initialize clocks, plls (Phase Locked Loop, phase-locked loops), mhus (MESSAGE HANDLING units), timers, counters, etc., and to process interrupt processing and inter-core communication, etc., as well as run-time services.
In ARM Neoverse N (an architecture platform) of the current V9 architecture, three CPU subsystems are included, SCP, MCP (Manageability Control Processor, management control processor), AP (Application Processor ). After the system is powered up, the SCP BL1 operates first and resets the AP Core 0. The AP BL1 (first level boot program) starts running from the set address in the ROM of the AP. The main function of the AP BL1 located in the ROM is similar to that of the SCP BL1, and is mainly used to move the AP BL2 (second level boot program) from the external nonvolatile device into the SRAM of the AP. The AP BL2 moves SCP BL2 from an external nonvolatile device to DDR SDRAM (Double Data Rate Synchronous Dynamic Random Access Memory, double rate synchronous dynamic random access memory), and performs security authentication on the SCP BL2, and after the authentication is passed, the SCP is informed to acquire the SCP BL2 version from the DDR SDRAM. After the SCP BL2 version is obtained, the operation is continued by jumping to the SCP BL2, and the AP is informed that the SCP BL2 version is obtained, and the AP BL2 continues to execute the following functional modules after receiving the completion reply. Since then, the early start-up of the system is essentially complete.
In the start-up flow of N2, scpbl 1 located in the SCP ROM and AP BL1 located in the AP ROM are regarded as secure as the root of trust of the system. AP BL1 then loads authentication AP BL2 and AP BL2 loads authentication SCP BL2. The next stage is executed on the basis of success of the previous stage, and the whole process is serial and safe.
However, for a DPU including SCP, MCP, AP large-scale CPU architecture, in some usage scenarios, not only secure but also non-secure start-up needs to be supported, and at the same time, not only release versions, but also debug versions in the chip development process need to be supported. For non-secure start-up, secure authentication is not required in the version start-up process. Aiming at the problem that version debugging needs to be supported in the process of chip development; the debug version, i.e. the version start, does not have to start from the SCP BL1 nor does the SCP have to be needed to unset the AP, but rather there is no strong coupling between the cores and the start can be done individually. For the above functional requirements, these functions are not supported in existing ARM open source code. Meanwhile, ARM open source codes are used, the chip development flow can only be serial, and parallel development and debugging cannot be carried out.
Disclosure of Invention
The invention aims to solve the technical problem of providing a starting method and device of an SoC system based on eFuses, the SoC system, a chip and electronic equipment, which can realize various starting modes, improve the research and development efficiency of the chip, reduce the cost and improve the competitiveness of the product.
To solve the above-mentioned technical problem, as an aspect of the present invention, there is provided a method for starting an SoC system based on eFuse, applied to an SoC system including a plurality of subsystems, including at least:
when the SoC system is powered on, eFuse data stored in an eFuse memory and external power-on control word data are acquired;
Obtaining a corresponding starting mode according to the eFuse data and the power-on control word data, wherein each eFuse data and the power-on control word data combination corresponds to a starting mode in advance;
and executing the power-on starting operation according to the starting execution sequence corresponding to the obtained starting mode.
Wherein the step of obtaining a corresponding startup mode according to the eFuse data and the power-on control word data further comprises:
when the eFuse data are non-all-zero and the power-on control word data are first data, determining that the current starting mode is a safe starting mode of a service scene;
When the eFuse data is non-all zero and the power-on control word data is second data, determining that the current starting mode is a non-safe starting mode of a service scene;
When the eFuse data are all zero and the power-on control word data are third data, determining that the current starting mode is an independent non-safe starting mode aiming at the first subsystem in the debugging scene;
when the eFuse data are all zero and the power-on control word data are fourth data, determining that the current starting mode is an independent non-safe starting mode aiming at the second subsystem in the debugging scene;
and when the eFuse data is all zero and the power-on control word data is fifth data, determining that the current starting mode is an independent non-safe starting mode aiming at the third subsystem in the debugging scene.
Wherein, the step of executing the power-on startup operation according to the startup execution sequence corresponding to the acquired startup mode further comprises:
Acquiring a starting execution sequence corresponding to the starting mode according to the determined starting mode;
And controlling at least one of the first subsystem, the second subsystem and the third subsystem according to the starting execution sequence, and sequentially executing and completing the power-on starting operation.
When the current starting mode is a safe starting mode of the service scene, the operation of executing the power-on starting operation according to the starting execution sequence preset by the obtained starting mode further comprises:
Executing a first-stage bootstrap loader of the first subsystem, and loading a second-stage bootstrap of the first subsystem into the SRAM from an external nonvolatile memory;
signature authentication is carried out on the version in the SRAM, and after the authentication is passed, the second-stage bootstrap program of the first subsystem is skipped;
Executing a second-level bootstrap program of the first subsystem, and loading the second-level bootstrap program of the second subsystem into an SRAM of the second subsystem;
Signature authentication is carried out on a second-level bootstrap program of the second subsystem, and after the authentication is passed, jie Fuwei the second subsystem enables the second subsystem to start running from a set address;
After resetting the second subsystem, moving the trusted firmware second-level bootstrap program of the third subsystem to DDR;
Performing security authentication on a trusted firmware second-level bootstrap program in the DDR, and enabling a Jie Fuwei third subsystem to start running from a set address after the authentication is passed;
The whole safe starting process is completed.
When the current starting mode is a non-secure starting mode of the service scene, the operation of executing the power-on starting operation according to the starting execution sequence preset by the obtained starting mode further comprises:
Executing a first-stage bootstrap loader of the first subsystem, loading a second-stage bootstrap of the first subsystem into the SRAM from an external nonvolatile memory, and jumping to the second-stage bootstrap of the first subsystem;
Executing a second-stage bootstrap program of the first subsystem, loading the second-stage bootstrap program of the second subsystem into an SRAM of the second subsystem, resetting the second subsystem, and enabling the second subsystem to start running from a set address;
After the second subsystem is reset, the second-stage bootstrap program of the trusted firmware of the third subsystem is moved to the DDR, and the first core of the third subsystem is reset, so that the third subsystem starts to operate from a set address, and the rest cores of the third subsystem are reset and operate in sequence;
And finishing the whole unsafe starting process.
Wherein, when the current startup mode is a separate non-secure startup mode for the first subsystem in the debug scenario, the operation of executing the power-on startup operation according to the startup execution order preset by the obtained startup mode further includes:
executing a first level boot loader of the first subsystem in an external non-volatile memory;
moving a second-level bootstrap program of a first subsystem in an external nonvolatile memory to a corresponding SRAM;
Redirecting an interrupt vector table and initializing a stack environment;
and jumping to the second-level bootstrap program of the first subsystem, and executing the second-level bootstrap program of the first subsystem.
The current starting mode is an independent non-secure starting mode for the second subsystem in the debugging scene, and the operation of executing the power-on starting operation according to the starting execution sequence preset by the obtained starting mode further comprises:
executing a first level boot loader of the second subsystem in the external non-volatile memory;
Moving a second-level bootstrap program of a second subsystem in the external nonvolatile memory to a corresponding SRAM;
Redirecting an interrupt vector table and initializing a stack environment;
And jumping to a second-stage bootstrap program of the second subsystem, executing the second-stage bootstrap program of the second subsystem, initializing a clock, a PLL, a GPIO and a sensor, performing interrupt processing and runtime service, and monitoring temperature, power consumption and voltage change in real time.
The current starting mode is an independent non-secure starting mode for the third subsystem in the debugging scene, and the operation of executing the power-on starting operation according to the starting execution sequence preset by the obtained starting mode further comprises:
The first system is a System Control Processor (SCP), the second management controller is a Management Control Processor (MCP), and the third system is an Application Processor (AP).
Accordingly, in another aspect of the present invention, there is also provided a starting apparatus of an eFuse-based SoC system, which includes at least:
A determination data acquisition unit for acquiring eFuse data stored in the eFuse memory and an external power-on control word data when the SoC system is powered on;
The starting mode determining unit is used for obtaining a corresponding starting mode according to the eFuse data and the power-on control word data, wherein each eFuse data and each power-on control word data combination corresponds to a starting mode in advance;
The power-on execution unit is used for executing power-on starting operation according to the starting execution sequence corresponding to the obtained starting mode;
And the corresponding relation storage unit is used for storing preset corresponding relation between each eFuse data and the combination of the power-on control word data and the starting mode.
The corresponding relation between each preset eFuse data and the combination of the power-on control word data and the starting mode is specifically as follows:
when the eFuse data is non-all zero and the power-on control word data is first data, the corresponding starting mode is a safe starting mode of a service scene;
When the eFuse data is non-all zero and the power-on control word data is second data, the corresponding starting mode is a non-safety starting mode of the service scene;
When the eFuse data are all zero and the power-on control word data are third data, the corresponding starting mode is an independent non-safe starting mode aiming at the first subsystem in the debugging scene;
when the eFuse data is all zero and the power-on control word data is fourth data, the corresponding starting mode is an independent non-safe starting mode aiming at the second subsystem in the debugging scene;
When the eFuse data is all zero and the power-on control word data is fifth data, the corresponding starting mode is an independent non-safe starting mode aiming at the third subsystem in the debugging scene.
Wherein the power-on execution unit further includes:
The starting execution sequence acquisition unit is used for acquiring a starting execution sequence corresponding to the starting mode according to the starting mode determined by the starting mode determination unit;
and the execution unit is used for controlling at least one of the first subsystem, the second subsystem and the third subsystem according to the starting execution sequence, and sequentially executing and completing the power-on starting operation.
The first system is a System Control Processor (SCP), the second management controller is a Management Control Processor (MCP), and the third system is an Application Processor (AP).
Correspondingly, in yet another aspect of the present invention, a Soc system is provided, which includes a plurality of subsystems, and further includes the aforementioned starting device.
Accordingly, in yet another aspect of the present invention, a chip integrated with the SoC system is provided.
Correspondingly, in yet another aspect of the present invention, an electronic device is provided with at least the aforementioned chip.
The embodiment of the invention has the following beneficial effects:
The invention provides a starting method and device of an SoC system based on eFuse, the SoC system, a chip and electronic equipment.
In the embodiment of the invention, two starting schemes of safe starting and unsafe starting can be supported, and the method and the device are applied to different use scenes, so that the product competitiveness can be improved.
In the embodiment of the invention, a plurality of debugging modes are simultaneously supported, and multi-core concurrent debugging can be supported only by matching different external power-on control words with different SoC system chips in the debugging stage, so that the development efficiency of the chips is greatly improved, the development period of the chips is shortened, the development cost of the chips is reduced, and the competitiveness of the chips is improved.
Drawings
In order to more clearly illustrate the embodiments of the invention or the technical solutions of the prior art, the drawings which are required in the description of the embodiments or the prior art will be briefly described, it being obvious that the drawings in the description below are only some embodiments of the invention, and that it is within the scope of the invention to one skilled in the art to obtain other drawings from these drawings without inventive faculty.
FIG. 1 is a schematic diagram of a main flow of one embodiment of a method of starting an eFuse-based SoC system provided by the present invention;
FIG. 2 is a schematic diagram of one embodiment of a startup device of an eFuse-based SoC system provided by the present invention;
Fig. 3 is a schematic diagram of the power-on execution unit in fig. 2.
Detailed Description
The present invention will be described in further detail with reference to the accompanying drawings, for the purpose of making the objects, technical solutions and advantages of the present invention more apparent.
FIG. 1 illustrates a main flow diagram of one embodiment of a method of starting an eFuse-based SoC system provided by the present invention; in this embodiment, the method at least includes:
Step S10, when the SoC system is powered on, eFuse data stored in an eFuse memory and external power-on control word data are acquired; wherein the power-on control word data is a group of data including a plurality of bits.
Step S11, obtaining a corresponding starting mode according to the eFuse data and the power-on control word data, wherein each eFuse data and the power-on control word data combination corresponds to a starting mode in advance;
specifically, in an embodiment of the present invention, the step S11 further includes:
when the eFuse data are non-all-zero and the power-on control word data are first data, determining that the current starting mode is a safe starting mode of a service scene;
When the eFuse data is non-all zero and the power-on control word data is second data, determining that the current starting mode is a non-safe starting mode of a service scene;
When the eFuse data is all zero and the power-on control word data is third data, determining that the current starting mode is an independent non-safe starting mode aiming at a first subsystem (such as a System Control Processor (SCP)) in a debugging scene;
When the eFuse data is all zero and the power-on control word data is fourth data, determining that the current starting mode is an independent non-secure starting mode aiming at a second subsystem (such as a Management Control Processor (MCP)) in a debugging scene;
when the eFuse data is all zero and the power-on control word data is fifth data, the current starting mode is determined to be a single non-secure starting mode for a third subsystem (such as an Application Processor (AP)) in the debugging scene.
Step S12, power-on starting operation is executed according to the starting execution sequence corresponding to the obtained starting mode.
More specifically, as shown in Table 1 below, a table of correspondence between each eFuse data and power-up control word data combinations and startup modes is shown in one embodiment:
Table 1: correspondence table
From this, it can be seen that when ns_ FORBID is all 0, it is indicated that the eFuse memory has not written data yet, the SoC system chip may be in a debug stage, and multiple debug scenarios may be implemented by the combination of eFuse and power-on control word, where: an AP unsafe self-starting scene, an MCP unsafe self-starting scene and an SCP unsafe self-starting scene. When NS_ FORBID is all 0 and bit [0] of the power-on control word is 1, the AP is started from FLASH in a non-secure way; when NS_ FORBID is all 0 and bit [1] of the power-on control word is 1, SCP starts up from FLASH in a non-safe way; when NS_ FORBID is all 0 and bit [2] of the power-on control word is 1, the MCP is started from FLASH in a non-secure way; thus, the purpose of parallel development and debugging of each CPU small system is achieved.
When ns_ FORBID is not all 0, it indicates that the eFuse memory has written data, and the SoC system chip is in an application scenario, and can adopt a secure start mode and a non-secure start mode, and determine a specific start mode by combining the content of the power-on control word.
More specifically, the step S11 further includes:
step S110, acquiring a starting execution sequence corresponding to the starting mode according to the determined starting mode;
And step S111, controlling at least one of the first subsystem, the second subsystem and the third subsystem according to the starting execution sequence, and sequentially executing and completing the power-on starting operation. The first system is a System Control Processor (SCP), the second management controller is a Management Control Processor (MCP), and the third system is an Application Processor (AP).
The following describes the power-on startup operation in various startup modes in detail:
When the current starting mode is a safe starting mode of the service scene, the operation of executing the power-on starting operation according to the starting execution sequence preset by the obtained starting mode further comprises:
executing a first-stage boot loader (SCP BL 1) of the first subsystem, and loading a second-stage boot loader (SCP BL 2) of the first subsystem into a corresponding SRAM of the first Subsystem (SCP) from an external nonvolatile memory (such as FLASH);
Signature authentication is carried out on the version in the SRAM, and after the authentication is passed, the second-stage bootstrap program (SCP BL 2) of the first subsystem is skipped;
executing a second level bootstrap program (SCP BL 2) of the first subsystem, and loading the second level bootstrap program (MCP BL 2) of the second subsystem into an SRAM of the second subsystem (MCP);
signature authentication is carried out on a second-level bootstrap program (MCP BL 2) of the second subsystem, and after the authentication is passed, jie Fuwei the second subsystem starts to run from a set address;
after resetting the second subsystem, moving trusted firmware (e.g., ARM Trusted Firmware, ATF) second level boot program (ATF BL 2) of the third subsystem (AP) into the DDR;
The method comprises the steps that safety authentication is conducted on a trusted firmware second-level bootstrap program (ATF BL 2) in the DDR, and after authentication is passed, a third subsystem is Jie Fuwei, and the third subsystem starts to run from a set address;
The whole safe starting process is completed.
More specifically, in one specific example, the following detailed steps may be included:
1) The SoC system is powered up and controls the first mirror image (scpbl 1) in the SCP ROM to run from the specified address.
2) SCP BL1 loads the second image (scpbl 2 FW/key_pub/signature) from QSPI FLASH to SRAM.
3) And calling a hash engine to perform hash (hash) calculation on the root public key_PUB in the second image.
4) Comparing the calculated hash value with the hash value stored in the eFuse, and if the calculated hash value and the hash value are not equal, indicating that the software is not issued by a signature center, and terminating the operation; otherwise, the operation is continued.
5) And calling a hash engine to perform SHA256 calculation on the SCP BL2 FW to obtain a result A.
6) And calling the RSA engine to decrypt the signature by using the KEY_PUB to obtain B.
7) Comparing the A and the B, if the A and the B are consistent, indicating that the software is not tampered; otherwise, it indicates that the software has been tampered with.
8) If the software is tampered with, the operation is terminated.
9) If the software is not tampered with, the jump is made to SCP BL2 for continued operation.
10 SCP BL2 loads the third image (AP BL2 FW/key_pub/signature) from QSPI FLASH to the DDR physical address.
11A hash engine is called to perform hash (hash) calculation on the root public key_pub in the third image.
12 Comparing the calculated hash value with the hash value stored in the eFuse, and if the calculated hash value and the hash value are not equal, indicating that the software is not issued by the signature center, stopping the AP from running; otherwise, the operation is continued.
13 A hash engine is called to carry out SHA256 calculation on the AP BL2 FW to obtain a result A.
14 The RSA engine is called to decrypt the signature with key_pub to get B.
15 Comparing A with B, if the two are consistent, indicating that the software is not tampered; and otherwise, the software is tampered.
16 If the software is tampered with, the AP is not awakened.
17 If the software has not been tampered with, wake the AP up from the specified address.
18 SCP BL2 loads the fourth image (MCP FW/key_pub/signature) from QSPI FLASH to MCP SRAM.
19 A hash engine is called to perform hash (hash) calculation on the root public key_pub in the fourth image.
20 Comparing the calculated hash value with the hash value stored in the eFuse, and if the calculated hash value and the hash value are not equal, indicating that the software is not issued by a signature center, and terminating the operation of the MCP; otherwise, the operation is continued.
21 A hash engine is called to carry out SHA256 calculation on MCP FW to obtain a result A.
22 The RSA engine is called to decrypt the signature with key_pub to get B.
23 Comparing A with B, if the two are consistent, indicating that the software is not tampered; otherwise, it indicates that the software has been tampered with.
24 If the software is tampered with, the MCP is not awakened.
25 If the software has not been tampered with, wake the MCP to run from the specified address.
And (II) when the current starting mode is the unsafe starting mode of the service scene, the operation of executing the power-on starting operation according to the starting execution sequence preset by the obtained starting mode further comprises the following steps:
Executing a first-stage boot loader (SCP BL 1) of the first subsystem, loading a second-stage boot loader (SCP BL 2) of the first subsystem into an SRAM corresponding to the first Subsystem (SCP) from an external nonvolatile memory (FLASH), and jumping to the second-stage boot loader (SCP BL 2) of the first subsystem;
executing a second-level bootstrap program (SCP BL 2) of the first subsystem, loading the second-level bootstrap program (MCP BL 2) of the second subsystem into an SRAM of the second subsystem, resetting the second subsystem (MCP) and enabling the second subsystem to start running from a set address;
After the second subsystem is reset, the trusted firmware second-level bootstrap program (ATF BL 2) of the third subsystem (AP) is moved to the DDR, and the first core (APCore 0) of the third subsystem is reset, so that the third subsystem starts to operate from a set address, the remaining functional modules of the ATF are sequentially moved in the subsequent steps, and the remaining cores of the third subsystem are reset and operate in sequence;
And finishing the whole unsafe starting process.
More specifically, in one specific example, the following detailed steps may be included:
1) The SoC system is powered on, and a first mirror image (SCP BL 1) in the SCP ROM is controlled to run from a designated address.
2) SCP BL1 loads the second image (SCP BL2 FW) from QSPI FLASH to SRAM.
3) Jump to SCP BL2 to continue operation.
4) SCP BL2 loads the third image (AP BL2 FW) from QSPI FLASH to the DDR physical address.
5) Setting the start address of the AP.
6) The wake-up AP operates from the specified address.
7) SCP BL2 loads the fourth image (MCP FW) from QSPI FLASH to MCP SRAM;
8) The start address of the MCP is set.
9) The wake-up MCP is run from the specified address.
(III) in the case that the current starting mode is a single non-secure starting mode aiming at the first subsystem in the debugging scene, the operation of executing the power-on starting operation according to the starting execution sequence preset by the obtained starting mode further comprises:
Executing a first level boot loader (scpbl 1) of the first subsystem in an external non-volatile memory (FLASH);
moving a second-stage boot program SCP BL2 of a first subsystem in an external nonvolatile memory (FLASH) to a corresponding SRAM;
Redirecting an interrupt vector table and initializing a stack environment;
Jump to the second level bootstrap program (SCP BL 2) of the first subsystem, execute the second level bootstrap program (SCP BL 2) of the first subsystem, initialize clocks, PLLs, MHUs, timers, IICs (integrated circuit buses) and GPIOs (general purpose input output), and perform interrupt processing and runtime services.
(IV) the current starting mode is an independent non-safe starting mode aiming at the second subsystem in the debugging scene, and the operation of executing the power-on starting operation according to the starting execution sequence preset by the obtained starting mode further comprises the following steps:
executing a first level boot loader (MCP BL 1) of the second subsystem in an external non-volatile memory (FLASH);
moving a second-level boot program (MCP BL 2) of a second subsystem in an external non-volatile memory (FLASH) into a corresponding SRAM;
Redirecting an interrupt vector table and initializing a stack environment;
And jumping to a second-stage bootstrap program (MCP BL 2) of the second subsystem, executing the second-stage bootstrap program (MCP BL 2) of the second subsystem, initializing a clock, a PLL, a GPIO and a sensor, performing interrupt processing and runtime service, and monitoring temperature, power consumption and voltage change in real time.
Fifth, the current startup mode is a separate non-secure startup mode for the third subsystem in the debug scenario, and the operation of executing the power-on startup operation according to the startup execution sequence preset by the obtained startup mode further includes:
the SoC system is powered up and the third subsystem (AP) is executed in an external non-volatile memory (FLASH).
The CMN is initialized (Control Matrix Network ).
OCM (On Chip Memory) is initialized.
The version is migrated into the OCM.
The ATFs BL31, BL32 and UEFI are sequentially pulled up, and in one example, a one-by-one pulling-up manner may be adopted.
In the chip development and debugging stage, parallel debugging and development are needed, so that the development efficiency can be improved, and the development period is shortened.
Referring now to FIG. 2, a schematic diagram illustrating one embodiment of a startup device for an eFuse-based SoC system is shown. As also shown in fig. 3, in this embodiment, the apparatus 1 at least includes:
A determination data acquisition unit 10 for acquiring eFuse data stored in the eFuse memory and an external power-on control word data when the SoC system is powered on;
a startup mode determining unit 11, configured to obtain a corresponding startup mode according to the eFuse data and the power-on control word data, where each eFuse data and the power-on control word data combination corresponds to a startup mode in advance;
A power-on execution unit 12, configured to execute a power-on start operation according to a start execution order corresponding to the obtained start mode;
And a correspondence relation storage unit 13 for storing preset correspondence relation between each eFuse data and the combination of the power-on control word data and the start mode.
More specifically, the correspondence between each preset eFuse data and the combination of the power-on control word data and the starting mode is specifically:
When the eFuse data are non-all-zero and the power-on control word data are first data, the corresponding starting mode is a safe starting mode of a service scene;
When the eFuse data is non-all zero and the power-on control word data is second data, the corresponding starting mode is a non-safety starting mode of the service scene;
When the eFuse data are all zero and the power-on control word data are third data, the corresponding starting mode is an independent non-safe starting mode aiming at the first subsystem in the debugging scene;
When the eFuse data are all zero and the power-on control word data are fourth data, the corresponding starting mode is an independent non-safe starting mode aiming at the second subsystem in the debugging scene;
when the eFuse data is all zero and the power-on control word data is fifth data, the current starting mode is an independent non-safe starting mode aiming at the third subsystem in the debugging scene.
More specifically, the power-on execution unit 12 further includes:
A start execution order obtaining unit 120, configured to obtain a start execution order corresponding to the start mode according to the start mode determined by the start mode determining unit;
And the execution unit 121 is configured to control at least one of the first subsystem, the second subsystem, and the third subsystem according to the start execution order, and sequentially execute and complete a power-on start operation.
In a specific example, the first system is a System Control Processor (SCP), the second management controller is a Management Control Processor (MCP), and the third system is an Application Processor (AP).
For the execution order of the start-up corresponding to each start-up mode, reference may be made to the foregoing description of fig. 1 and details are not repeated herein.
In yet another aspect of the present invention, there is further provided an SoC system, which includes a plurality of subsystems, and the starting apparatus described in fig. 2. For more details, reference is made to the foregoing descriptions of fig. 1 to 3, and no further description is given here.
Correspondingly, in yet another aspect of the present invention, a chip is further provided, which is integrated with the SoC system, where the SoC system includes a plurality of subsystems, and the starting device described in fig. 2. For more details, reference is made to the foregoing descriptions of fig. 1 to 3, and no further description is given here.
Accordingly, in still another aspect of the present invention, there is further provided an electronic device, at least provided with the foregoing chip, where the chip is integrated with an SoC system, and the SoC system includes a plurality of subsystems, and the foregoing starting apparatus described in fig. 2. The electronic device may be a server or a cluster of servers of a data center. For more details, reference is made to the foregoing descriptions of fig. 1 to 3, and no further description is given here.
The invention provides a starting method and device of an eFuse-based SoC system, the SoC system, a chip and electronic equipment, which are based on the starting flow of the existing open source firmware (such as ARM open source firmware), and the starting mode is controlled by the combination of the eFuse and a power-on control word, so that a safe starting mode and a non-safe starting mode can be realized, and various starting modes such as self-starting of each CPU core can be realized.
In the embodiment of the invention, two starting schemes of safe starting and unsafe starting can be supported, and the method and the device are applied to different use scenes, so that the product competitiveness can be improved.
In the embodiment of the invention, a plurality of debugging modes are simultaneously supported, and multi-core concurrent debugging can be supported only by matching different external power-on control words with different SoC system chips in the debugging stage, so that the development efficiency of the chips is greatly improved, the development period of the chips is shortened, the development cost of the chips is reduced, and the competitiveness of the chips is improved.
It will be apparent to those skilled in the art that embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The above disclosure is only a preferred embodiment of the present invention, and it is needless to say that the scope of the invention is not limited thereto, and therefore, the equivalent changes according to the claims of the present invention still fall within the scope of the present invention.

Claims (15)

1. The starting method of the SoC system based on eFuses is applied to the SoC system comprising a plurality of subsystems, and is characterized by at least comprising the following steps:
when the SoC system is powered on, eFuse data stored in an eFuse memory and external power-on control word data are acquired;
Obtaining a corresponding starting mode according to the eFuse data and the power-on control word data, wherein each eFuse data and the power-on control word data combination corresponds to a starting mode in advance;
and executing the power-on starting operation according to the starting execution sequence corresponding to the obtained starting mode.
2. The method of claim 1, wherein the step of obtaining the corresponding startup mode based on the eFuse data and power-on control word data further comprises:
when the eFuse data are non-all-zero and the power-on control word data are first data, determining that the current starting mode is a safe starting mode of a service scene;
When the eFuse data is non-all zero and the power-on control word data is second data, determining that the current starting mode is a non-safe starting mode of a service scene;
When the eFuse data are all zero and the power-on control word data are third data, determining that the current starting mode is an independent non-safe starting mode aiming at the first subsystem in the debugging scene;
when the eFuse data are all zero and the power-on control word data are fourth data, determining that the current starting mode is an independent non-safe starting mode aiming at the second subsystem in the debugging scene;
and when the eFuse data is all zero and the power-on control word data is fifth data, determining that the current starting mode is an independent non-safe starting mode aiming at the third subsystem in the debugging scene.
3. The method of claim 2, wherein the step of performing a power-on startup operation according to a startup execution order corresponding to the obtained startup mode further comprises:
Acquiring a starting execution sequence corresponding to the starting mode according to the determined starting mode;
And controlling at least one of the first subsystem, the second subsystem and the third subsystem according to the starting execution sequence, and sequentially executing and completing the power-on starting operation.
4. The method of claim 3, wherein when the current startup mode is a safe startup mode of the service scenario, the operation of performing the power-on startup operation according to the startup execution order preset by the obtained startup mode further comprises:
Executing a first-stage bootstrap loader of the first subsystem, and loading a second-stage bootstrap of the first subsystem into the SRAM from an external nonvolatile memory;
signature authentication is carried out on the version in the SRAM, and after the authentication is passed, the second-stage bootstrap program of the first subsystem is skipped;
Executing a second-level bootstrap program of the first subsystem, and loading the second-level bootstrap program of the second subsystem into an SRAM of the second subsystem;
Signature authentication is carried out on a second-level bootstrap program of the second subsystem, and after the authentication is passed, jie Fuwei the second subsystem enables the second subsystem to start running from a set address;
After resetting the second subsystem, moving the trusted firmware second-level bootstrap program of the third subsystem to DDR;
Performing security authentication on a trusted firmware second-level bootstrap program in the DDR, and enabling a Jie Fuwei third subsystem to start running from a set address after the authentication is passed;
The whole safe starting process is completed.
5. The method of claim 3, wherein when the current startup mode is a non-secure startup mode of the service scenario, the operation of performing the power-on startup operation according to the startup execution order preset by the obtained startup mode further comprises:
Executing a first-stage bootstrap loader of the first subsystem, loading a second-stage bootstrap of the first subsystem into the SRAM from an external nonvolatile memory, and jumping to the second-stage bootstrap of the first subsystem;
Executing a second-stage bootstrap program of the first subsystem, loading the second-stage bootstrap program of the second subsystem into an SRAM of the second subsystem, resetting the second subsystem, and enabling the second subsystem to start running from a set address;
After the second subsystem is reset, the second-stage bootstrap program of the trusted firmware of the third subsystem is moved to the DDR, and the first core of the third subsystem is reset, so that the third subsystem starts to operate from a set address, and the rest cores of the third subsystem are reset and operate in sequence;
And finishing the whole unsafe starting process.
6. The method of claim 3, wherein the current boot mode is a separate non-secure boot mode for the first subsystem in the debug scenario, the performing the power-on boot operation according to a boot execution order preset by the obtained boot mode further comprising:
executing a first level boot loader of the first subsystem in an external non-volatile memory;
moving a second-level bootstrap program of a first subsystem in an external nonvolatile memory to a corresponding SRAM;
Redirecting an interrupt vector table and initializing a stack environment;
and jumping to the second-level bootstrap program of the first subsystem, and executing the second-level bootstrap program of the first subsystem.
7. The method of claim 3, wherein the current boot mode is a separate non-secure boot mode for the second subsystem in the debug scenario, the performing the power-on boot operation according to a boot execution order preset by the obtained boot mode further comprising:
executing a first level boot loader of the second subsystem in the external non-volatile memory;
Moving a second-level bootstrap program of a second subsystem in the external nonvolatile memory to a corresponding SRAM;
Redirecting an interrupt vector table and initializing a stack environment;
and jumping to a second-level bootstrap program of the second subsystem, and executing the second-level bootstrap program of the second subsystem.
8. The method of any of claims 2 to 7, wherein the first system is a System Control Processor (SCP), the second management controller is a Management Control Processor (MCP), and the third system is an Application Processor (AP).
9. A launch device of an eFuse-based SoC system, comprising at least:
A determination data acquisition unit for acquiring eFuse data stored in the eFuse memory and an external power-on control word data when the SoC system is powered on;
The starting mode determining unit is used for obtaining a corresponding starting mode according to the eFuse data and the power-on control word data, wherein each eFuse data and each power-on control word data combination corresponds to a starting mode in advance;
The power-on execution unit is used for executing power-on starting operation according to the starting execution sequence corresponding to the obtained starting mode;
And the corresponding relation storage unit is used for storing preset corresponding relation between each eFuse data and the combination of the power-on control word data and the starting mode.
10. The apparatus of claim 9, wherein the correspondence of each of the preset eFuse data and the combination of the power-on control word data with the startup mode is specifically:
when the eFuse data is non-all zero and the power-on control word data is first data, the corresponding starting mode is a safe starting mode of a service scene;
When the eFuse data is non-all zero and the power-on control word data is second data, the corresponding starting mode is a non-safety starting mode of the service scene;
When the eFuse data are all zero and the power-on control word data are third data, the corresponding starting mode is an independent non-safe starting mode aiming at the first subsystem in the debugging scene;
when the eFuse data is all zero and the power-on control word data is fourth data, the corresponding starting mode is an independent non-safe starting mode aiming at the second subsystem in the debugging scene;
When the eFuse data is all zero and the power-on control word data is fifth data, the corresponding starting mode is an independent non-safe starting mode aiming at the third subsystem in the debugging scene.
11. The apparatus of claim 10, wherein the power-on execution unit further comprises:
The starting execution sequence acquisition unit is used for acquiring a starting execution sequence corresponding to the starting mode according to the starting mode determined by the starting mode determination unit;
and the execution unit is used for controlling at least one of the first subsystem, the second subsystem and the third subsystem according to the starting execution sequence, and sequentially executing and completing the power-on starting operation.
12. The apparatus of any of claims 9 to 11, wherein the first system is a System Control Processor (SCP), the second management controller is a Management Control Processor (MCP), and the third system is an Application Processor (AP).
13. A SoC system comprising a plurality of subsystems, further comprising a starting device according to any of claims 9-12.
14. A chip, characterized in that it is integrated with the SoC system as claimed in claim 13.
15. An electronic device, characterized in that at least a chip as claimed in claim 14 is provided.
CN202211237064.4A 2022-10-10 2022-10-10 EFuse-based starting method, device and system of SoC system, soC chip and electronic equipment Pending CN117908969A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211237064.4A CN117908969A (en) 2022-10-10 2022-10-10 EFuse-based starting method, device and system of SoC system, soC chip and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211237064.4A CN117908969A (en) 2022-10-10 2022-10-10 EFuse-based starting method, device and system of SoC system, soC chip and electronic equipment

Publications (1)

Publication Number Publication Date
CN117908969A true CN117908969A (en) 2024-04-19

Family

ID=90680631

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211237064.4A Pending CN117908969A (en) 2022-10-10 2022-10-10 EFuse-based starting method, device and system of SoC system, soC chip and electronic equipment

Country Status (1)

Country Link
CN (1) CN117908969A (en)

Similar Documents

Publication Publication Date Title
TWI643130B (en) SYSTEM AND METHOD FOR AUTO-ENROLLING OPTION ROMs IN A UEFI SECURE BOOT DATABASE
US10747883B2 (en) Collated multi-image check in system-on-chips
TWI335536B (en) Information handling system (ihs) method and for updating a non-volatile memory (nvm) included in an information handling system
US9658858B2 (en) Multi-threaded low-level startup for system boot efficiency
EP2831722B1 (en) Method and system for verifying proper operation of a computing device after a system change
US7216223B2 (en) Configuring multi-thread status
US9703635B2 (en) Method, computer program, and computer for restoring set of variables
KR101931007B1 (en) Initialization trace of a computing device
CN101504704B (en) Star trust chain supporting embedded platform application program integrality verification method
CN101276389B (en) Separation of logical trusted platform modules within a single physical trusted platform module
US11579893B2 (en) Systems and methods for separate storage and use of system BIOS components
CN102298529B (en) Providing silicon integrated code for a system
CN110785738B (en) Lead time determination of calibration parameters for components coupled to a system-on-chip
JP2015049906A (en) System and method for secure boot rom patch
CN103999041A (en) Backing up firmware during initialization of device
US20210357202A1 (en) Firmware updating
TW201721412A (en) Selecting and loading firmware volumes
US20220067162A1 (en) Update signals
TWI604336B (en) Runtime verification using external device
CN117908969A (en) EFuse-based starting method, device and system of SoC system, soC chip and electronic equipment
CN106293620B (en) The method of parameter in intel detection of platform Flash Rom
US11295000B1 (en) Static configuration of accelerator card security modes
WO2016184180A1 (en) Method and apparatus for safe startup of system
US11204781B2 (en) Optimizing power, memory and load time of a computing system during image loading based on image segmentation
US20240111543A1 (en) Concurrent execution and copy of updated basic input/output system instructions

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination