Multi-core starting method and device, equipment, storage medium and program product

Abstract

The invention relates to a multi-core starting method and device, equipment, a storage medium and a program product. The method comprises the steps that in response to a first mirror image starting instruction of a master core, the master core executes a first mirror image file starting operation of a slave core, and under the condition that starting of the first mirror image file of the slave core is completed, the master core sends a second mirror image starting instruction to the slave core to instruct the slave core to execute a second mirror image file starting operation of the slave core. According to the method, after the master core starts the first mirror image file of the slave core, the slave core is instructed to start the second mirror image file of the slave core, so that the slave core finishes starting, and the process is equivalent to that the master core turns part of mirror image file starting operation of the slave core to be executed by the slave core, so that the operation time of the master core is saved, and the starting efficiency is improved. Therefore, the overall starting time of the main core for controlling the multiple cores is greatly shortened, and the starting speed of the multiple cores is further improved.

Description

Multi-core startup method, device, equipment, storage medium and program product Technical Field

[0001] The present application relates to the field of chip technology, and in particular to a multi-core startup method, apparatus, device, storage medium, and program product. Background Art

[0002] With the development of artificial intelligence and the Internet of Things (IoT) technology, single-core chips are no longer able to meet the computing power requirements of some application scenarios, and more and more multi-core chips have emerged. For example, the system-on-chip (SOC) in the vehicle domain control system integrates multiple cores.

[0003] In the related art, each core is started up by having a main core in the multiple cores control the other cores to start up in sequence. However, the related art has the problem of slow startup speed of multiple cores.

[0004] Summary of the Invention

[0005] Based on this, it is necessary to provide a multi-core startup method, device, equipment, storage medium and program product to address the above technical problems, which can improve the startup speed of multi-core.

[0006] In a first aspect, an embodiment of the present application provides a multi-core startup method, the method comprising:

[0007] In response to the first image startup instruction of the master core, the master core executes the first image file startup operation of the slave core;

[0008] When the first image file startup of the slave core is completed, the master core sends a second image startup instruction to the slave core; the second image startup instruction is used to instruct the slave core to execute the second image file startup operation of the slave core.

[0009] The technical solution in the embodiment of the present application is that in response to the first mirror image startup instruction of the master core, the master core executes the first mirror image file startup operation of the slave core. When the first mirror image file startup of the slave core is completed, the master core sends a second mirror image startup instruction to the slave core to instruct the slave core to execute the second mirror image file startup operation of the slave core. In this method, after the master core starts the first mirror image file of the slave core, it instructs the slave core to start its own second mirror image file so that the slave core completes the startup. This process is equivalent to the master core transferring part of the mirror file startup operation of the slave core to the slave core for execution, thereby saving the operation time of the master core, greatly shortening the startup time of the master core controlling the multi-core as a whole, and further improving the speed of multi-core startup. At the same time, during the multi-core startup process, the slave core executes its own second mirror image file startup, so that the slave core will not be in an idle state, so that the core resources of the slave core can be fully utilized, thereby improving the resource utilization of the master core and the slave core.

[0010] In one embodiment, the file size of the first image file is smaller than the file size of the second image file.

[0011] According to the technical solution in the embodiment of the present application, the file size of the first image file is smaller than the file size of the second image file, so that the main core only executes the startup operation of the first image file with a smaller file size in the slave core, and instructs the slave core to execute the startup operation of the second image file with a larger file size in the slave core, thereby saving the time of controlling the execution of the slave core startup, shortening the multi-core startup time as a whole, and improving the speed of multi-core startup.

[0012] In one embodiment, the method further includes:

[0013] When the master core sends the second image start instruction to the slave core, the master core synchronously executes its own second image file start operation.

[0014] The technical solution in the embodiment of the present application is that when the master core sends a second mirror image startup instruction to the slave core, the master core synchronously executes its own second mirror image file startup operation; in the process of the slave core starting its own second mirror image file, the master core can synchronously execute its own second mirror image file startup operation to complete the master core startup, which is equivalent to the master core being responsible for starting a part of the mirror file and the slave core being responsible for starting another part of the mirror file, and the startup process of the master core and the slave core can be carried out synchronously, so that the master core only needs to execute its own mirror file startup and the first mirror file startup of the slave core. During this period, the slave core also synchronously executes its own second mirror file startup, saving the operation time of the master core, greatly shortening the overall startup time of the multi-core, thereby improving the speed of multi-core startup. In addition, when the master core executes its own second mirror image file startup operation, the slave core also synchronously executes its own second mirror image file startup, so that the slave core will not be in an idle waiting state, so that the core resources of the slave core can be fully utilized, thereby improving the resource utilization of the master core and the slave core.

[0015] In one embodiment, the slave cores include a first slave core and a second slave core; the master core executes a first image file startup operation of the slave cores, including:

[0016] The master core executes a first image file startup operation of the first slave core;

[0017] When the first image file startup of the first slave core is completed, the master core executes the first image file startup operation of the second slave core.

[0018] The technical solution in the embodiment of the present application is to execute the first image file startup operation of the first slave core through the master core, and when the first image file startup of the first slave core is completed, the master core executes the first image file startup operation of the second slave core; that is, in the case of two slave cores, the master core first executes the first image file startup of one of the slave cores, and only when the first image file startup is completed, executes the first image file startup of the other slave core, so that multiple slave cores will not affect each other, thereby improving the stability of the multi-core startup process.

[0019] In one embodiment, the method further includes:

[0020] During the process of executing the first mirror file startup operation of the second slave core, the master core synchronously sends a second mirror startup instruction to the first slave core, where the second mirror startup instruction is used to instruct the first slave core to execute the second mirror file startup operation of the first slave core.

[0021] According to the technical solution in the embodiment of the present application, during the process of the master core executing the first mirror file startup operation of the second slave core, the master core synchronously sends the second mirror startup instruction to the first slave core to instruct the first slave core to execute the second mirror file startup operation of the first slave core. The master core executes the first mirror file startup of multiple slave cores in sequence, but after the master core completes the startup of the first mirror file of any slave core, while starting the first mirror file of another slave core, it will instruct the corresponding slave core that has completed the startup of the first mirror file to synchronously execute the startup of its own second mirror file. This greatly shortens the startup time of the two slave cores controlled by the master core to a certain extent, thereby improving the speed of multi-core startup. In addition, during the process of the master core executing the second mirror file startup operation, the first slave core also synchronously executes the startup of its own second mirror file, so that the first slave core will not be in an idle waiting state, so that the core resources of the first slave core can be fully utilized, thereby improving the resource utilization rate of the first slave core.

[0022] In one embodiment, when the first image file of the slave core is started, the master core sends a second image start instruction to the slave core, including:

[0023] When the first image file startup of the second slave core is completed, the master core sends a second image startup instruction to the second slave core; the second image startup instruction is used to instruct the second slave core to execute the second image file startup operation of the second slave core.

[0024] In the technical solution of the embodiment of the present application, upon completion of the startup of the first image file of the second slave core, the master core sends a second image startup instruction to the second slave core. In this method, after the startup of the first image file of the second slave core is completed, the master core instructs the second slave core to execute the second image file startup operation of the second slave core, thereby saving the master core time to execute the startup of the second slave core and shortening the startup time of the master core controlling the second slave core. In addition, the master core transfers the second image file startup operation of the second slave core to the second slave core, so that the second slave core does not wait in vain, allowing the core resources of the second slave core to be fully utilized, thereby improving the resource utilization rate of the second slave core.

[0025] In one embodiment, the first image file includes a startup image file, and the first image file startup operation includes:

[0026] Copy the information in the boot image file of the slave core to the boot file storage area;

[0027] The startup address of the startup image file points to the startup file storage interval, and triggers the execution of the startup image file.

[0028] The technical solution in the embodiment of the present application copies the information in the startup image file of the slave core to the startup file storage interval, points the startup address of the startup image file to the startup file storage interval, and triggers the execution of the startup image file; this method copies the information in the startup image file of the slave core to a specific startup file storage interval, and the startup file storage interval only stores the information in the startup image file, and does not contain other information outside the startup image file, thereby improving the acquisition of the startup image file before parsing the startup image file, and further improving the startup speed of the slave core.

[0029] In one embodiment, the second image file includes an application image file, and the second image file startup operation includes:

[0030] Copy the information in the application image file from the core to the application storage area;

[0031] Point the startup address of the application image file to the application storage interval and trigger the running of the application image file.

[0032] The technical solution in the embodiment of the present application copies the information in the application image file of the slave core to the application storage interval, points the startup address of the application image file to the application storage interval, and triggers the running of the application image file; the method copies the information in the application image file of the slave core to a specific application storage interval, and the application storage interval only stores the information in the application image file, and no other information outside the application file exists, thereby being able to parse the speed of obtaining the application image file before starting the application image file, thereby further improving the startup speed of the slave core.

[0033] In one embodiment, the method further includes:

[0034] The master core obtains the master core status feedback information after its own startup and the slave core status feedback information after the slave core starts running;

[0035] The master core generates a monitoring message based on the master core status feedback information and the slave core status feedback information; the monitoring message is used to indicate the operating status of the master core and the slave core.

[0036] The technical solution in the embodiment of the present application is to obtain the main core status feedback information after the main core starts running and the slave core status feedback information after the slave core starts running, and generate a monitoring message based on the main core status feedback information and the slave core status feedback information; in this method, multi-core monitoring messages are generated to timely obtain the operating status of the main core and the slave core, and abnormal operating status is promptly resolved to eliminate faults, thereby improving the business processing progress and speed of the main core and / or slave core, and thereby improving the stability of the multi-core chip startup process.

[0037] In a second aspect, an embodiment of the present application provides a multi-core startup device, the device comprising:

[0038] A first execution module, configured to execute a first image file startup operation of the slave core in response to a first image startup instruction;

[0039] The second execution module is used to send a second image startup instruction to the slave core when the first image file startup of the slave core is completed; the second image startup instruction is used to instruct the slave core to execute the second image file startup operation of the slave core.

[0040] In a third aspect, the present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any one of the methods of the first aspect when executing the computer program.

[0041] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of any one of the methods of the first aspect when executed by a processor.

[0042] In a fifth aspect, the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of any one of the methods of the first aspect above.

[0043] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present application. The same reference numerals are used throughout the drawings to represent the same components. In the drawings:

[0045] FIG1 is a schematic diagram of the overall process of implementing a multi-core startup method using relevant technologies in one embodiment;

[0046] FIG2 is an application environment diagram of a multi-core startup method according to an embodiment;

[0047] FIG3 is a schematic diagram of a flow chart of a multi-core startup method according to an embodiment;

[0048] FIG4 is a diagram showing a specific application environment of a multi-core startup method according to an embodiment;

[0049] FIG5 is a schematic diagram of a flow chart of a multi-core startup method in another embodiment;

[0050] FIG6 is a schematic diagram of a flow chart of a multi-core startup method in another embodiment;

[0051] FIG7 is a schematic diagram of a flow chart of a multi-core startup method according to another embodiment;

[0052] FIG8 is a schematic diagram showing a comparison of the startup time required for multi-core startup in another embodiment;

[0053] FIG9 is a schematic flow chart of a multi-core startup method according to another embodiment;

[0054] FIG10 is a schematic flow chart of a multi-core startup method according to another embodiment;

[0055] FIG11 is a structural block diagram of a multi-core startup device according to an embodiment;

[0056] FIG12 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0057] The following embodiments of the technical solution of the present application will be described in detail with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present application and are therefore only examples and are not intended to limit the scope of protection of the present application.

[0058] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application; the term "include" and any variations thereof in the specification and claims of this application and the above-mentioned figure descriptions are intended to cover non-exclusive inclusions.

[0059] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0060] With the development of artificial intelligence and the Internet of Things (IoT) technology, single-core chips are no longer able to meet the computing power requirements of some application scenarios, leading to the emergence of an increasing number of multi-core chips. Related technologies primarily enable the startup of multi-core chips by having the master core of the multi-core chip sequentially control the startup image files and application image files of other cores.

[0061] For example, the SOC in a vehicle domain control system integrates multiple cores, including microcontroller units (MCU) 1, MCU2, and microprocessor units (MPUs), with MCU1 serving as the master core. In practical applications, when the SOC is started, all of the cores within it must be activated. Related technologies typically achieve this by having the master core, MCU1, sequentially control its own startup and the startup of other cores.

[0062] For example, as shown in Figure 1, a flowchart of a multi-core startup method using relevant technologies is illustrated. In Figure 1, IPC (Inter-Process Communication) represents multi-core communication, that is, the communication connection between MCU2 and MCU1, and the communication connection between MPU and MCU1.

[0063] Typically, each core starts by parsing its boot image file (i.e., Boot image file) to launch the installer, and then parses its application image file (i.e., App image file) to launch the application on the core. The core is not booted until both the boot image file and the application image file are parsed.

[0064] In this regard, please continue to refer to Figure 1. In the relevant technology, the multi-core startup process is generally that after starting the main core MCU1, MCU1 first parses the startup image file of MCU2 and the application image file of MCU2 in sequence, and then parses the startup image file of MPU and the application image file of MPU in sequence, and then parses the application image file of MCU1. After all the startup image files and application image files are parsed, the multi-core startup is completed, and the startup of SOC is also completed.

[0065] At the same time, when the parsing of the startup image file of MCU2 and the application image file of MCU2 is completed, that is, when the startup of MCU2 is completed, MCU1 can send an application startup instruction to MCU2 to instruct MCU2 to start the application installed on itself. Among them, when the application on MCU2 is running, MCU2 will monitor its own running status to generate MCU2 status feedback information, and feed back the MCU2 status feedback information to MCU1; when the parsing of the startup image file of MPU and the application image file of MPU is completed, that is, when the startup of MPU is completed, MCU1 can send an application startup instruction to MPU to instruct MPU to start the application installed on itself. Among them, when the application on MPU is running, MPU will monitor its own running status to generate MPU status feedback information, and feed back the MPU status feedback information to MCU1.

[0066] It should be noted that after MCU1 sends the application startup instruction to MPU, MCU1 can trigger its own application startup instruction, monitor its own operating status and obtain MCU1 status feedback information, among which MCU1 can determine whether the status feedback information of MCU1, MCU2 and MPU is obtained, and generate a monitoring message after determining that the status feedback information of MCU1, MCU2 and MPU is obtained.

[0067] Optionally, the multi-core chip is located in a vehicle domain control system, and the monitoring message may be a controller area network (CAN) message.

[0068] The aforementioned multi-core boot operations are all performed by the master core MCU1. Only after the slave cores (MCU2 and MPU) have completed booting will the master core parse its own application image file and complete its own boot. However, while the master core is parsing its own application image file, the slave cores are in a waiting state, preventing their core resources from being fully utilized and reducing their resource utilization. Furthermore, since the application image file is large, the master core takes a long time to parse, resulting in a slow multi-core boot speed.

[0069] Based on this, in order to solve the problem that the startup speed of the above-mentioned multi-cores is slow, and when the main core executes the parsing process, the already started slave cores are in an idle waiting state, and the core resources of the slave cores cannot be fully utilized, the embodiment of the present application proposes a multi-core startup method, in which the main core sequentially parses the startup image files of other cores and the main core's own application image files. After the parsing of the startup image files of other cores is completed, the other cores are instructed to parse their own application image files, thereby saving the operation time of the main core and further improving the speed of multi-core startup.

[0070] As shown in Figure 2, an application environment diagram of the multi-core startup method provided in an embodiment of the present application is provided. The application environment includes the master core and slave core in the multi-core chip. Among them, the multi-core chip can be applied to high-performance devices, such as mobile phones, computers, cameras, self-driving vehicles and other devices that need to meet high computing requirements. The multi-core chip is not limited to SOC and can also be other chips. In the embodiment of the present application, the master core and the slave core are connected by communication, and the connection method can be Bluetooth, mobile network, WiFi, etc.

[0071] In one embodiment, FIG3 is a flow chart of a multi-core startup method in one embodiment of the present application. In this embodiment of the present application, the execution subject of the method is the master core in FIG2 as an example for explanation. The multi-core startup method may include the following steps:

[0072] S100 : In response to a first image startup instruction of a master core, the master core executes a first image file startup operation of a slave core.

[0073] In the embodiment of the present application, the first image refers to the startup image (i.e., the Boot image). The first image startup instruction of the main core represents an instruction to start the main core installation program by parsing the startup image file of the main core. In the embodiment of the present application, responding to the first image startup instruction of the main core can be understood as indicating that the startup of the main core startup image file has been completed.

[0074] Accordingly, the first image file of the slave core represents the boot image file (i.e., the Boot image file) of the slave core. Then, when the master core executes the boot operation of the first image file of the slave core, it means that the master core executes the boot operation of the boot image file of the slave core. Here, the first image file of the slave core can be obtained from the image file library according to the slave core identification information, and then the boot operation of the boot image file is completed by parsing the boot image file of the slave core. That is, the master core executing the boot operation of the first image file of the slave core can be understood as the process of the master core parsing the first image file of the slave core.

[0075] The master core in the embodiments of the present application can be any core in a multi-core chip. For example, as shown in FIG4 , taking the multi-core chip as an SOC, the master core in the multi-core chip can be MCU1 in FIG4 , and the slave cores can be MCU2 and MPU; alternatively, the master core can be MCU2, and the slave cores can be MCU1 and MPU, etc. It should be noted that the number of cores specifically referred to in the embodiments of the present application is not limited to one master core plus one slave core, but can also be one master core plus two, three, or even more slave cores, etc.

[0076] For example, assuming that the master core is MCU1, the slave cores include MCU2 and MPU, and the above-mentioned first image file is a Boot image file as an example, then the implementation process of the embodiment of the present application includes responding to the Boot image startup instruction of MCU1, that is, after the Boot image file of MCU1 is started, MCU1 can execute the Boot image file startup operation of MCU2 and the Boot image file startup operation of MPU.

[0077] In which case, when the first image file of the master core is started, the master core can obtain an image file library from a local location, a disk, a hard disk, or a cloud location, and then obtain the first image file of the corresponding slave core from the image file library according to the slave core identification information, and execute the first image file startup operation of the slave core. In which, the image file library may include different image files of the master core, the master core identification information, and the corresponding relationship between the two, and may also include different image files of the slave core, the slave core identification information, and the corresponding relationship between the two. Optionally, the master core identification information and the slave core identification information can both be represented by at least one of letters, numbers, and symbols, but the master core identification information and the slave core identification information are different.

[0078] In one embodiment, the method for executing the first image file startup operation of the slave core may be that the master core automatically executes the first image file startup operation of the slave core after acquiring the first image file of the slave core.

[0079] In another embodiment, the method for executing the first image file startup operation of the slave core may be that after the master core obtains the first image file of the slave core, it receives and responds to the startup operation execution instruction of the first image file input by the user, and then executes the startup operation of the first image file of the slave core. Optionally, the method for the user to input the startup operation execution instruction of the first image file may be voice, gesture, action, keystroke, etc.

[0080] S200: When the first image file startup of the slave core is completed, the master core sends a second image startup instruction to the slave core; wherein the second image startup instruction is used to instruct the slave core to execute the second image file startup operation of the slave core.

[0081] The second image in the embodiment of the present application refers to an application image (ie, App image), and the second image startup instruction of the slave core represents an instruction to start the slave core application by parsing the slave core application image file.

[0082] Then, based on the above-mentioned master core executing the first image file startup operation of the slave core, when the master core determines that the startup of the first image file of the slave core is completed, it can automatically generate the second image startup instruction of the slave core, and then send the second image startup instruction of the slave core to the slave core to instruct the slave core to execute its own second image file startup operation.

[0083] For example, let's take the example where the first image file is a Boot image file, the second image file is an App image file, the master core is MCU1, and the slave cores include MCU2 and MPU. In actual applications, after the Boot image files of MCU2 and MPU are started, MCU1 can send an App image start instruction to MCU2 to instruct MCU2 to execute its own App image file startup operation, and send an App image start instruction to the MPU to instruct the MPU to execute its own App image file startup operation.

[0084] In some scenarios, the way in which the main core generates the second mirror image startup instruction of the slave core can be: after the main core determines that the startup of the first mirror file of the slave core is completed, it outputs a prompt message that the startup of the first mirror file of the slave core is completed. After the main core outputs the prompt message that the startup of the first mirror file of the slave core is completed, the user can input the second mirror image startup instruction of the slave core to the main core. The main core receives the second mirror image startup instruction of the slave core and sends the second mirror image startup instruction of the slave core to the slave core to instruct the slave core to execute its own second mirror file startup operation.

[0085] In one embodiment, the file size of the first image file is smaller than the file size of the second image file.

[0086] For example, if the first image file is a Boot image file and the second image file is an App image file, the size of the Boot image file is smaller than the size of the App image file.

[0087] In an embodiment of the present application, since the file size of the first image file is smaller than the file size of the second image file, the main core only executes the startup operation of the first image file with a smaller file size on the slave core, and instructs the slave core to execute the startup operation of the second image file with a larger file size on the slave core to complete the startup of the slave core, thereby saving the time of controlling the execution of the slave core startup, thereby shortening the multi-core startup time as a whole and improving the speed of multi-core startup.

[0088] In actual applications, since the second image file of the slave core is large, when the traditional technology parses the second image file of the slave core through the main core, it will cause the main core to occupy a long parsing time, making it impossible for the main core to perform other operations during the parsing process. In order to solve this problem, the embodiment of the present application instructs the slave core to parse its own second image file, so that the main core can save time in parsing the second image file of the slave core, thereby shortening the startup time of the multi-core and improving the startup speed of the multi-core.

[0089] For example, taking the master core as MCU1, the slave cores including MCU2 and MPU, the first image file as the Boot image file, and the second image file as the App image file as an example, the file size of the Boot image file is smaller than the file size of the App image file. In actual applications, the file size of the Boot image file is smaller than the file size of the App image file. In this way, MCU1 only executes the Boot image file startup operation with the smaller file size of MCU2 and MPU, and instructs MCU2 and MPU to execute their respective App image file startup operations with the larger file size.

[0090] The technical solution in the embodiment of the present application is that in response to the first mirror image startup instruction of the master core, the master core executes the first mirror image file startup operation of the slave core. When the first mirror image file startup of the slave core is completed, the master core sends a second mirror image startup instruction to the slave core to instruct the slave core to execute the second mirror image file startup operation of the slave core. In this method, after the master core starts the first mirror image file of the slave core, it instructs the slave core to start its own second mirror image file so that the slave core completes the startup. This process is equivalent to the master core transferring part of the mirror file startup operation of the slave core to the slave core for execution, thereby saving the operation time of the master core, greatly shortening the startup time of the master core controlling the multi-core as a whole, and further improving the speed of multi-core startup. At the same time, during the multi-core startup process, the slave core executes its own second mirror image file startup, so that the slave core will not be in an idle state, so that the core resources of the slave core can be fully utilized, thereby improving the resource utilization of the master core and the slave core.

[0091] In some scenarios, while a slave core is booting from a portion of an image file, the master core can simultaneously execute other operations to minimize the time it takes for the master core to control the multi-core boot. Based on this, in one embodiment, after the step in S200, the method may further include: when the master core sends a second image boot instruction to the slave core, the master core synchronously executes its own second image file boot operation.

[0092] The second image file of the main core represents the application image file (i.e., App image file) of the main core. Therefore, the main core executing its own second image file startup operation represents the main core executing its startup image file startup operation. This can involve obtaining the main core's second image file from an image file library based on the main core identification information, and then parsing the main core's second image file to complete the application image file startup operation. That is, the main core executing the main core's second image file startup operation can be understood as the main core parsing the main core's second image file.

[0093] For example, the method of executing the second image file startup operation of the main core may be that the main core automatically executes the second image file startup operation of the main core after obtaining the second image file of the main core.

[0094] For another example, the method for executing the second image file startup operation of the main core can also be that after the main core obtains the second image file of the main core, it receives and responds to the startup operation execution instruction of the second image file input by the user, and then executes the second image file startup operation of the main core.

[0095] In actual applications, after the master core sends the slave core's second image startup instruction to the slave core, the slave core responds to the received slave core's second image startup instruction, and after the slave core responds to the slave core's second image startup instruction, that is, when the slave core is parsing the slave core's second image file, the master core can synchronously execute the master core's second image file startup operation.

[0096] For example, taking the main core as MCU1 and the second image file as the App image file as an example, in actual application, MCU1 sends the App image startup instruction of the slave core to the slave core. After the slave core responds to the App image startup instruction of the slave core, that is, while the slave core is parsing its own App image file, MCU1 can synchronously execute the APP image file startup operation of MCU1.

[0097] The technical solution in the embodiment of the present application is that when the master core sends a second mirror image startup instruction to the slave core, the master core synchronously executes its own second mirror image file startup operation; in the process of the slave core starting its own second mirror image file, the master core can synchronously execute its own second mirror image file startup operation to complete the master core startup, which is equivalent to the master core being responsible for starting a part of the mirror file and the slave core being responsible for starting another part of the mirror file, and the startup process of the master core and the slave core can be carried out synchronously, so that the master core only needs to execute its own mirror file startup and the first mirror file startup of the slave core. During this period, the slave core also synchronously executes its own second mirror file startup, saving the operation time of the master core, greatly shortening the overall startup time of the multi-core, thereby improving the speed of multi-core startup. In addition, when the master core executes its own second mirror image file startup operation, the slave core also synchronously executes its own second mirror image file startup, so that the slave core will not be in an idle waiting state, so that the core resources of the slave core can be fully utilized, thereby improving the resource utilization of the master core and the slave core.

[0098] The following describes the process of the master core executing the slave core's first image file startup operation using a scenario with two slave cores as an example. In one embodiment, the slave cores include a first slave core and a second slave core; as shown in FIG5 , the step of the master core executing the slave core's first image file startup operation in S100 may include:

[0099] S110 : The master core executes a first image file startup operation of the first slave core.

[0100] The first image file of the first slave core refers to the boot image file (i.e., the Boot image file) of the first slave core, and the master core executing the boot operation of the first slave core's first image file means that the master core executes the boot operation of the boot image file of the first slave core. Alternatively, the master core executing the boot operation of the boot image file of the first slave core can be understood as the process of the master core parsing the boot image file of the first slave core.

[0101] For example, the master core is MCU1, the slave cores include MCU2 and MPU, the first slave core is MCU2 or MPU, and the above-mentioned first image file is a Boot image file as an example, then the implementation process of the embodiment of the present application includes that MCU1 can execute the Boot image file startup operation of MCU2 or MPU.

[0102] Specifically, the master core may obtain the first image file corresponding to the first slave core from the image file library according to the identification information of the first slave core, and then perform the first image file startup operation of the first slave core.

[0103] Optionally, the method for executing the first image file startup operation of the first slave core can be to analyze the first image file of the first slave core, and then determine the startup running time of the first image file of the first slave core based on the analysis result, and then start and run the first image file of the first slave core according to the startup running time.

[0104] Alternatively, the first image file startup operation of the first slave core may be performed by starting and running the first image file of the first slave core according to a preset startup and operation rule. Optionally, the preset startup and operation rule may be user-defined or determined based on historical experience; the startup and operation rule may include information such as the startup and operation mode and startup and operation conditions of the first image file.

[0105] S120 : When the first image file startup of the first slave core is completed, the master core executes the first image file startup operation of the second slave core.

[0106] Wherein, the first image file of the second slave core refers to the startup image file (i.e., the Boot image file) of the second slave core, and the master core executing the startup operation of the first image file of the second slave core means that the master core executes the startup operation of the startup image file of the second slave core. Alternatively, the master core executing the startup operation of the startup image file of the second slave core can be understood as the process of the master core parsing the startup image file of the second slave core.

[0107] For example, the master core is MCU1, the slave cores include MCU2 and MPU, and one of MCU2 and MPU is the first slave core and the other is the second slave core. Here, the first slave core is MCU2 and the second slave core is MPU for illustration. In actual applications, MCU1 executes the Boot image file startup operation of MCU2. After the Boot image file startup of MCU2 is completed, MCU1 executes the Boot image file startup operation of MPU.

[0108] Optionally, after determining that the startup of the first image file of the first slave core is complete, the master core may output relevant information of the startup completion of the first image file of the first slave core, and then execute the first image file startup operation of the second slave core.

[0109] It should be noted here that the master core outputs the related information of the startup completion of the first image file of the first slave core to prompt that the first image file of the first slave core has been started, and the related information of the startup completion can be output in the form of view, text, voice, etc.

[0110] In one embodiment, the method for executing the startup operation of the first image file of the second slave core can be to analyze the first image file of the second slave core, and then determine the startup and running time of the first image file of the second slave core based on the analysis result, and then start and run the first image file of the second slave core according to the startup and running time.

[0111] In another embodiment, the method for executing the first image file startup operation of the second slave core may also be to start and run the first image file of the second slave core according to a preset startup and operation rule.

[0112] The technical solution in the embodiment of the present application is to execute the first image file startup operation of the first slave core through the master core, and when the first image file startup of the first slave core is completed, the master core executes the first image file startup operation of the second slave core; that is, in the case of two slave cores, the master core first executes the first image file startup of one of the slave cores, and only when the first image file startup is completed, executes the first image file startup of the other slave core, so that multiple slave cores will not affect each other, thereby improving the stability of the multi-core startup process.

[0113] In practical applications, the first image file startup operation refers to the operation of parsing the first image file. The implementation process of the first image file startup operation is described below. In one embodiment, the first image file includes a startup image file. As shown in Figure 6, the step of the first image file startup operation in S120 can be implemented in the following manner:

[0114] S121 , copy the information in the boot image file of the slave core to the boot file storage area.

[0115] Specifically, the master core may obtain the startup image file of the slave core from the image file library according to the identification information of the slave core, and then copy the information in the startup image file of the slave core to the startup file storage interval.

[0116] Optionally, the startup file storage area may not be limited to a memory area in the computer device where the multi-core chip is located, or a disk area connected to the computer device, etc.

[0117] S122: Point the startup address of the startup image file to the startup file storage interval, and trigger the execution of the startup image file.

[0118] Among them, the master core can point the startup address of the slave core's startup image file to the startup file storage interval, and trigger the startup of the slave core's startup image file in the startup file storage interval through the startup address of the slave core's startup image file, that is, run the slave core's startup image file.

[0119] For example, taking the main core as MCU1, the slave cores including MCU2 and MPU, and the first image file including the Boot image file as an example, in actual application, MCU1 can copy the information in the Boot image file of MCU2 to the startup file storage interval area1, and then point the startup address add1 of the Boot image file of MCU2 to area1, and trigger the startup of the Boot image file of MCU2 in area1 through the startup address add1 of the Boot image file of MCU2; at the same time, MCU1 can also copy the information in the Boot image file of MPU to the startup file storage interval area2, and then point the startup address add2 of the Boot image file of MPU to area2, and trigger the startup of the Boot image file of MPU in area2 through the startup address add2 of the Boot image file of MPU.

[0120] During the above implementation process, the information in the startup image files of different slave cores is copied to different startup file storage areas, so that the startup addresses of the startup image files of different slave cores point to different areas, so that the master core can quickly start the startup image files of different slave cores, further improving the startup speed of the startup image files of different slave cores.

[0121] The technical solution in the embodiment of the present application copies the information in the startup image file of the slave core to the startup file storage interval, points the startup address of the startup image file to the startup file storage interval, and triggers the execution of the startup image file; this method copies the information in the startup image file of the slave core to a specific startup file storage interval, and the startup file storage interval only stores the information in the startup image file, and does not contain other information outside the startup image file, thereby improving the speed of obtaining the startup image file before parsing the startup image file, and further improving the startup speed of the slave core.

[0122] In some scenarios, to significantly shorten the time it takes for the master core to control the startup of a slave core, the master core needs to send a boot-up instruction to the slave core under specific conditions, instructing the slave core to respond to the instruction and execute the second-image-based boot-up operation. In this regard, in one embodiment, the multi-core startup method may further include: while the master core is executing the first-image-based boot-up operation of the second slave core, synchronously sending a second-image-based boot-up instruction to the first slave core. The second-image-based boot-up instruction is used to instruct the first slave core to execute the second-image-based boot-up operation of the first slave core.

[0123] In actual applications, after the master core completes the first image file startup operation of the first slave core, that is, after the first image file of the first slave core is parsed, it can continue to execute the first image file startup operation of the second slave core, that is, to parse the first image file of the second slave core.

[0124] Among them, in order to greatly shorten the startup time of the main core controlling multiple cores, the main core can synchronously send a second image startup instruction to the first slave core during the process of executing the first image file startup operation of the second slave core to instruct the first slave core to execute the second image file startup operation of the first slave core, that is, to instruct the first slave core to parse its own second image file.

[0125] For example, taking the master core as MCU1, the slave cores including MCU2 and MPU, where the first slave core is MCU2, the second slave core is MPU, and the first image file is the Boot image file, and the second image file is the App image file as an example, in actual application, MCU1 can synchronously send the App image startup instruction to MCU2 during the process of executing the MPU's Boot image file startup operation.

[0126] Optionally, the second mirror image startup instruction sent to the first slave core may be generated in a manner that: the master core automatically generates the second mirror image startup instruction for the first slave core after executing the first mirror file startup operation of the first slave core; or, after executing the first mirror file startup operation of the first slave core, the master core outputs a prompt message indicating that the startup of the first mirror file of the first slave core is completed, and after the user receives the prompt message, the second mirror image startup instruction of the first slave core is input to the master core, and accordingly, the master core obtains the second mirror image startup instruction of the first slave core.

[0127] It should be noted that after the master core obtains the second image startup instruction of the first slave core, it immediately sends the second image startup instruction of the first slave core to the first slave core. Accordingly, after the first slave core obtains the second image startup instruction, it can obtain the second image file of the first slave core from the image file library based on the identification information of the first slave core, and then execute the second image file startup operation of the first slave core, that is, parse the second image file of the first slave core.

[0128] According to the technical solution in the embodiment of the present application, during the process of the master core executing the first mirror file startup operation of the second slave core, the master core synchronously sends a second mirror startup instruction to the first slave core to instruct the first slave core to execute the second mirror file startup operation of the first slave core. The master core executes the first mirror file startup of multiple slave cores in sequence, but after the master core completes the startup of the first mirror file of any slave core, while starting the first mirror file of another slave core, it will instruct the corresponding slave core that has completed the startup of the first mirror file to synchronously execute the startup of its own second mirror file. This greatly shortens the startup time of the two slave cores controlled by the master core to a certain extent, thereby improving the speed of multi-core startup. In addition, during the process of the master core executing the second mirror file startup operation, the first slave core also synchronously executes the startup of its own second mirror file, so that the first slave core will not be in an idle waiting state, thereby making full use of the core resources of the first slave core and improving the resource utilization rate of the first slave core.

[0129] In actual application, the second image file startup operation refers to the parsing operation of the second image file. The implementation process of the second image file startup operation is described below. In one embodiment, the second image file includes an application image file. As shown in Figure 7, the steps of the second image file startup operation can be implemented in the following manner:

[0130] S210 , copying the information in the application image file of the slave core to the application storage area.

[0131] The master core may obtain the application image file of the slave core from the image file library according to the slave core identification information, and then copy the information in the application image file of the slave core to the application storage interval.

[0132] Optionally, the above-mentioned application storage interval can be a memory area in the computer device where the multi-core chip is located, but it belongs to a different memory area from the startup file storage area, and belongs to a different area in the same memory as the startup file storage area; or, the above-mentioned application storage interval can also be a disk area connected to the computer device, but it belongs to a different disk area from the startup file storage area, and belongs to a different area in the same disk as the startup file storage area, and so on.

[0133] S220: Point the startup address of the application image file to the application storage interval, and trigger the running of the application image file.

[0134] Furthermore, the master core can point the startup address of the slave core's application image file to the application storage interval, and trigger the startup of the slave core's application image file in the application storage interval through the startup address of the slave core's application image file, that is, run the slave core's application image file.

[0135] For example, taking the main core as MCU1, the slave cores including MCU2 and MPU, and the second image file as the App image file as an example, in actual application, MCU1 can copy the information in the App image file of MCU2 to the application storage interval area3, and then point the startup address add3 of the App image file of MCU2 to area3, and trigger the startup of the App image file of MCU2 in area3 through the startup address add3 of the App image file of MCU2. At the same time, MCU1 can also copy the information in the App image file of MPU to the application storage interval area4, and then point the startup address add4 of the App image file of MPU to area4, and trigger the startup of the App image file of MPU in area4 through the startup address add4 of the App image file of MPU.

[0136] During the above implementation process, the information in the application image files of different slave cores is copied to different application storage areas, so that the startup addresses of the application image files of different slave cores are pointed to different areas, so that the main core can quickly start the application image files of different slave cores, further improving the startup speed of the application image files of different slave cores.

[0137] The technical solution in the embodiment of the present application copies the information in the application image file of the slave core to the application storage interval, points the startup address of the application image file to the application storage interval, and triggers the running of the application image file; this method copies the information in the application image file of the slave core to a specific application storage interval, and the application storage interval only stores the information in the application image file, and no other information outside the application file exists, thereby improving the speed of obtaining the application image file before parsing and starting the application image file, and further improving the startup speed of the slave core.

[0138] In one embodiment, the step of the master core sending the second image startup instruction to the slave core in S200 above when the first image file startup of the slave core is completed may include: when the first image file startup of the second slave core is completed, the master core sending the second image startup instruction to the second slave core, wherein the second image startup instruction is used to instruct the second slave core to execute the second image file startup operation of the second slave core.

[0139] In actual applications, after the master core completes the first image file startup operation of the second slave core, that is, after the first image file of the second slave core is parsed, it can continue to execute the second image file startup operation of the master core, that is, to parse the second image file of the master core.

[0140] Among them, in order to greatly shorten the startup time of the main core controlling multiple cores, the main core can synchronously send a second image startup instruction to the second slave core during the process of executing the first image file startup operation of the second slave core to instruct the second slave core to execute the second image file startup operation of the second slave core, that is, to instruct the second slave core to parse its own second image file.

[0141] For example, taking the master core as MCU1, the slave cores including MCU2 and MPU, where the first slave core is MCU2, the second slave core is MPU, and the second image file is the App image file as an example, in actual application, while MCU1 is executing the MPU's Boot image file startup operation, MCU1 can synchronously send an App image startup instruction to the MPU to instruct the MPU to execute the MPU's App image file startup operation.

[0142] Optionally, the second image startup instruction sent to the second slave core can be generated in a manner that: the main core automatically generates the second image startup instruction for the second slave core after executing the first image file startup operation of the second slave core; or, after executing the first image file startup operation of the second slave core, the main core outputs a prompt message indicating that the startup of the first image file of the second slave core is completed, and after the user receives the prompt message, the second image startup instruction of the second slave core is input to the main core. Correspondingly, the main core obtains the second image startup instruction of the second slave core.

[0143] It should be noted that after the master core obtains the second image startup instruction of the second slave core, it immediately sends the second image startup instruction of the second slave core to the second slave core. Accordingly, after the second slave core obtains the second image startup instruction, it can obtain the second image file of the second slave core from the image file library based on the second slave core identification information, and then perform the second image file startup operation of the second slave core, that is, parse the second image file of the second slave core.

[0144] For example, taking the master core of a multi-core chip as MCU1, the slave cores including MCU2 and MPU, the first image file as the Boot image file, and the second image file as the App image file as an example, for the same multi-core chip, FIG8 is a schematic diagram showing a comparison of the time required to parse different image files when implementing multi-core startup using the relevant technology and the embodiment of the present application, wherein the upper portion of FIG8 illustrates the time required to parse different image files when implementing multi-core startup using the relevant technology, and the lower portion of FIG8 illustrates the time required to parse different image files when implementing multi-core startup using the embodiment of the present application. In the actual test process, the time required for MCU1 to parse the App image file of MCU2 using the relevant technology is 12.8 milliseconds, and the time required for MCU1 to parse the App image file of MPU is 102.4 milliseconds. Correspondingly, when the multi-core startup method in the embodiment of the present application is adopted, the time required for MCU1 to parse the App image file of MCU2 is 12.8 milliseconds, and the time required for MCU1 to parse the App image file of MPU is 51.2 milliseconds. At the same time, in the related art and the embodiment of the present application, the parsing time required for MCU1 to parse the Boot image file of MCU2 is 400 nanoseconds, and the parsing time required to parse the Boot image file of MPU is also 400 nanoseconds.

[0145] It should be noted here that since the processing performance of the MPU is greater than the processing performance of the MCU1, naturally, the speed at which the MPU executes the MPU application startup operation is greater than the speed at which the MCU1 executes the MPU application startup operation. Therefore, the parsing time required for the MCU1 to parse the MPU's App image file in the related technology is greater than the parsing time required for the MPU to parse the MPU's App image file in the embodiment of the present application.

[0146] Based on the above test results, it can be seen that in the process of the main core controlling the startup of the slave core, 64 milliseconds (i.e., the sum of 51.2 milliseconds and 12.8 milliseconds) of parsing time is saved. However, before the multi-core startup is completed, even if the main core does not perform the parsing operation, it is necessary to wait for the slave core to perform the parsing operation and obtain status feedback information. Among them, the interval time from the completion of the App image file parsing until the main core obtains the status feedback information in the related technology and the embodiment of the present application is equal. In actual applications, since the process of the slave core parsing the App image file and the process of the main core starting its own Boot image file are executed synchronously, the overall startup time saved by the embodiment of the present application relative to the related technology for implementing multi-core startup is 63.2 milliseconds (i.e., 12.8 milliseconds plus 102.4 milliseconds minus 52 milliseconds), which is equivalent to saving more than half of the startup time by using the embodiment of the present application relative to the related technology for implementing multi-core startup (the startup time is increased by more than 50% relative to the related technology).

[0147] In the technical solution of the embodiment of the present application, upon completion of the startup of the first image file of the second slave core, the master core sends a second image startup instruction to the second slave core. In this method, after the startup of the first image file of the second slave core is completed, the master core instructs the second slave core to execute the second image file startup operation of the second slave core, thereby saving the master core time to execute the startup of the second slave core and shortening the startup time of the master core controlling the second slave core. In addition, the master core transfers the second image file startup operation of the second slave core to the second slave core, so that the second slave core does not wait in vain, allowing the core resources of the second slave core to be fully utilized, thereby improving the resource utilization rate of the second slave core.

[0148] In some scenarios, it is necessary to monitor the operating status of each core in a multi-core chip so that abnormal operating conditions can be handled promptly based on the acquired monitoring results, minimizing the impact on the business processing progress of each core. The following describes the process of acquiring the monitoring results of each core. In one embodiment, after the steps in S200 above are executed, as shown in FIG9 , the multi-core startup method may further include the following steps:

[0149] S230 : The master core obtains the master core status feedback information after the master core starts running and the slave core status feedback information after the slave core starts running.

[0150] In actual applications, the parsing of the startup image file and the application image file of the slave core is completed, that is, after the slave core is started, the application on the slave core is started, and the slave core can automatically monitor its own running status during the running of the application; at the same time, the parsing of the startup image file and the application image file of the main core is completed, that is, after the main core is started, the application on the main core is started, and the main core can automatically monitor its own running status during the running of the application.

[0151] Furthermore, after the main core or the slave core is started, each will output relevant information about the completion of the startup. After the user receives the relevant information about the completion of the startup, he can input corresponding status monitoring instructions to the main core and the slave core respectively to instruct the main core and the slave core to start the application and monitor their own operating status during the operation of the application.

[0152] Among them, after the main core monitors its own operating status, the main core can generate main core status feedback information based on the main core's operating status; at the same time, after the slave core monitors its own operating status, the slave core can also generate slave core status feedback information based on the slave core's operating status, and send the slave core status feedback information to the main core.

[0153] Optionally, the above-mentioned operating status may be normal operation or abnormal operation; the above-mentioned status feedback information may include information such as operating status, operating time, identification information of the master core or slave core, fault cause and fault resolution strategy.

[0154] For example, taking MCU1 as the main core, in actual application, after the parsing of the Boot image file of MCU1 and the App image file of MCU1 is completed, that is, after the startup of MCU1 is completed, the application on MCU1 is started. During the running of the application on MCU1, MCU1 automatically monitors its own running status and generates MCU1 status feedback information according to the running status of MCU1, that is, the main core status feedback information.

[0155] In addition, taking the slave core including MCU2 and MPU, and the first slave core is MCU2, and the second slave core is MPU as an example, in actual application, the Boot image file of MCU2 and the App image file of MCU2 are parsed, that is, after the MCU2 is started, the application on MCU2 is started, and during the operation of the application on MCU2, MCU2 automatically monitors its own operating status and generates MCU2 status feedback information based on the operating status of MCU2. At the same time, in actual application, the Boot image file of MPU and the App image file of MPU are parsed, that is, after the MPU is started, the application on MPU is started, and during the operation of the application on MPU, MPU automatically monitors its own operating status and generates MPU status feedback information based on the operating status of MPU. In this example, the slave core status feedback information includes MCU2 status feedback information and MPU status feedback information.

[0156] S240: The master core generates a monitoring message based on the master core status feedback information and the slave core status feedback information, wherein the monitoring message is used to indicate the operating status of the master core and the slave core.

[0157] Based on the master core status feedback information and slave core status feedback information obtained in the previous steps, the master core can combine the master core status feedback information and the slave core status feedback information to obtain a multi-core monitoring message. In the case where the multi-core chip is a chip in the vehicle domain control system, the above monitoring message is a CAN message; of course, depending on the system in which the multi-core chip is located, the monitoring message can also be other types of messages.

[0158] Furthermore, the master core can output monitoring messages of multiple cores for users to view. When the master core and / or slave core are in abnormal operating status, users can adopt fault resolution strategies in a timely manner to eliminate the fault and minimize the impact on the business processing progress and speed of the master core and / or slave core.

[0159] For ease of understanding, as shown in Figure 10, it is a schematic diagram of the overall process of the above-mentioned multi-core startup method. The schematic diagram takes the master core as MCU1, the slave cores including MCU2 and MPU, wherein the first slave core is MCU2, the second slave core is MPU, the first image file is the Boot image file, and the second image file is the App image file as an example, illustrating a multi-core startup process in an embodiment of the present application: after starting MCU1, MCU1 parses the Boot image file of MCU2 and the Boot image file of MPU in sequence, and then parses the App image file of MCU1. After the parsing of the Boot image file of MCU2 is completed, MCU1 sends the App image startup instruction of MCU2 to MCU2 to instruct MCU2 to parse the App image file. When the parsing of the MCU2 App image file is completed, MCU2 triggers the application startup instruction of MCU2, and during the running of the application on MCU2, MCU2 monitors the running status of MCU2 to generate MCU2 status feedback information, and then feeds back the MCU2 status feedback information to MCU1. At the same time, when MCU1 sends the application image startup instruction of MCU2 to MCU2, MCU1 will synchronously parse the Boot image file of MPU.

[0160] In addition, after the MPU's Boot image file is parsed, MCU1 sends the MPU's application image startup instruction to the MPU to instruct the MPU to parse the MPU's App image file. After the MPU's App image file is parsed, the MPU triggers the MPU's application startup instruction, and during the application running on the MPU, the MPU monitors the MPU's running status to generate MPU status feedback information, and then feeds the MPU status feedback information back to MCU1. Further, MCU1 generates a monitoring message after obtaining the MCU1 status feedback information, MCU2 status feedback information, and MPU status feedback information.

[0161] The technical solution in the embodiment of the present application is to obtain the main core status feedback information after the main core starts running and the slave core status feedback information after the slave core starts running, and generate a monitoring message based on the main core status feedback information and the slave core status feedback information; in this method, multi-core monitoring messages are generated to timely obtain the operating status of the main core and the slave core, and abnormal operating status is promptly resolved to eliminate faults, thereby improving the business processing progress and speed of the main core and / or slave core, and thereby improving the stability of the multi-core chip startup process.

[0162] To facilitate understanding by those skilled in the art, the multi-core startup method provided in this application is described by taking the execution subject as the main core as an example. Specifically, the method includes:

[0163] (1) In response to the first image startup instruction of the master core, the master core executes the first image file startup operation of the first slave core.

[0164] (2) When the first mirror file startup of the first slave core is completed, the master core executes the first mirror file startup operation of the second slave core; wherein, during the process of executing the first mirror file startup operation of the second slave core, the master core synchronously sends a second mirror startup instruction to the first slave core, and the second mirror startup instruction is used to instruct the first slave core to execute the second mirror file startup operation of the first slave core; the file size of the first mirror file is smaller than the file size of the second mirror file.

[0165] The first image file includes a startup image file, and the first image file startup operation in the above step (2) includes:

[0166] (21) Copy the information in the boot image file of the slave core to the boot file storage area;

[0167] (22) The startup address of the startup image file is pointed to the startup file storage interval, and the startup image file is triggered to run.

[0168] (3) When the first mirror file startup of the second slave core is completed, the master core sends a second mirror startup instruction to the second slave core and synchronously executes its own second mirror file startup operation; the second mirror startup instruction is used to instruct the second slave core to execute the second mirror file startup operation of the second slave core.

[0169] The second image file includes an application image file, and the second image file startup operation in the above step (3) includes:

[0170] (31) Copy the information in the application image file from the core to the application storage area;

[0171] (32) The startup address of the application image file is pointed to the application storage interval, and the application image file is triggered to run.

[0172] (4) The master core obtains the master core status feedback information after its own startup and the slave core status feedback information after the slave core starts running.

[0173] (5) The master core generates a monitoring message based on the master core status feedback information and the slave core status feedback information; the monitoring message is used to indicate the operating status of the master core and the slave core.

[0174] The execution process of the above (1) to (5) can be specifically referred to the description of the above embodiment. The implementation principles and technical effects are similar and will not be repeated here.

[0175] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0176] Based on the same inventive concept, embodiments of the present application also provide a multi-core startup device for implementing the multi-core startup method described above. The solution provided by this device is similar to the solution described in the method described above. Therefore, the specific limitations of one or more multi-core startup device embodiments provided below can be found in the above-mentioned limitations of the multi-core startup method and will not be further elaborated here.

[0177] In one embodiment, as shown in FIG11 , a multi-core startup device is provided, including: a first execution module 11 and a second execution module 12 , wherein:

[0178] A first execution module 11 is configured to execute a first image file startup operation of a slave core in response to a first image startup instruction;

[0179] The second execution module 12 is configured to send a second image startup instruction to the slave core when the first image file startup of the slave core is completed; the second image startup instruction is configured to instruct the slave core to execute the second image file startup operation of the slave core.

[0180] The file size of the first image file is smaller than the file size of the second image file.

[0181] The multi-core startup device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0182] In one embodiment, the multi-core startup device includes a synchronous execution module; wherein:

[0183] The synchronous execution module is used for the master core to synchronously execute its own second image file startup operation when the master core sends a second image startup instruction to the slave core.

[0184] The multi-core startup device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0185] In one embodiment, the slave core includes a first slave core and a second slave core; the first execution module 11 includes: a first execution unit and a second execution unit, wherein:

[0186] A first execution unit, configured to execute a first image file startup operation on a first slave core;

[0187] The second execution unit is configured to execute a first image file startup operation of the second slave core when the first image file startup of the first slave core is completed.

[0188] The multi-core startup device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0189] In one embodiment, the multi-core startup device further includes: an instruction sending module, wherein:

[0190] An instruction sending module is used to synchronously send a second image startup instruction to the first slave core during the process of executing the first image file startup operation of the second slave core; the second image startup instruction is used to instruct the first slave core to execute the second image file startup operation of the first slave core;

[0191] The first image file includes a startup image file, and the first image file startup operation includes:

[0192] Copy the information in the boot image file of the slave core to the boot file storage area;

[0193] The startup address of the startup image file points to the startup file storage interval, and triggers the execution of the startup image file.

[0194] The multi-core startup device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0195] In one embodiment, the second execution module 12 includes: an instruction sending unit, wherein:

[0196] The instruction sending unit is used to send a second image startup instruction to the second slave core when the first image file startup of the second slave core is completed; the second image startup instruction is used to instruct the second slave core to execute the second image file startup operation of the second slave core.

[0197] The multi-core startup device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0198] In one embodiment, the second image file includes an application image file, and the second image file startup operation includes:

[0199] Copy the information in the application image file from the core to the application storage area;

[0200] Point the startup address of the application image file to the application storage interval and trigger the running of the application image file.

[0201] The multi-core startup device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0202] In one embodiment, the multi-core startup device includes: a feedback information acquisition module and a monitoring message generation module, wherein:

[0203] A feedback information acquisition module is used to obtain the status feedback information of the master core after the master core starts running and the status feedback information of the slave core after the slave core starts running;

[0204] The monitoring message generation module is used to generate monitoring messages based on the status feedback information of the master core and the status feedback information of the slave core; the monitoring messages are used to indicate the operating status of the master core and the slave core.

[0205] The multi-core startup device provided in this embodiment can execute the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here.

[0206] For the specific definition of the multi-core startup device, please refer to the definition of the multi-core startup method above, which will not be repeated here. Each module in the above-mentioned multi-core startup device can be implemented in whole or in part by software, hardware, or a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0207] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in FIG12 . The computer device includes a processor, a memory, and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store an image file library. The network interface of the computer device is used to communicate with an external endpoint via a network connection. When the computer program is executed by the processor, a multi-core startup method is implemented.

[0208] Those skilled in the art will understand that the structure shown in FIG12 is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0209] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0210] In response to the first image startup instruction, executing the first image file startup operation of the slave core;

[0211] When the first image file startup of the slave core is completed, a second image startup instruction is sent to the slave core; the second image startup instruction is used to instruct the slave core to execute the second image file startup operation of the slave core.

[0212] In one embodiment, a readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0213] In response to the first image startup instruction, executing the first image file startup operation of the slave core;

[0214] When the first image file startup of the slave core is completed, a second image startup instruction is sent to the slave core; the second image startup instruction is used to instruct the slave core to execute the second image file startup operation of the slave core.

[0215] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0216] In response to the first image startup instruction, executing the first image file startup operation of the slave core;

[0217] When the first image file startup of the slave core is completed, a second image startup instruction is sent to the slave core; the second image startup instruction is used to instruct the slave core to execute the second image file startup operation of the slave core.

[0218] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. For purposes of illustration and not limitation, RAM may be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The processors involved in the various embodiments provided herein may be general-purpose processors, central processing units (CPUs), graphics processors (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), data processing logic devices based on quantum computing, and the like, without limitation thereto.

[0219] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some or all of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application, and they should all be included in the scope of the claims and specification of the present application. In particular, as long as there is no structural conflict, the various technical features mentioned in the various embodiments can be combined in any way. The present application is not limited to the specific embodiments disclosed herein, but includes all technical solutions that fall within the scope of the claims.

Claims

1. A multi-core startup method, characterized in that: The method comprises: In response to the first image startup instruction of the master core, the master core executes the first image file startup operation of the slave core; When the first image file of the slave core is started up, the master core sends a second image start instruction to the slave core; the second image start instruction is used to instruct the slave core to execute the second image file start operation of the slave core.

2. The method according to claim 1, characterized in that The file size of the first image file is smaller than the file size of the second image file.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: In the case where the master core sends the second image file startup instruction to the slave core, the master core synchronously executes its own second image file startup operation.

4. The method according to claim 1 or 2, characterized in that: The slave core includes a first slave core and a second slave core; The master core executes the first image file startup operation of the slave core, including: The master core executes a first image file startup operation of the first slave core; When the first image file of the first slave core is started up completely, the master core executes the first image file start-up operation of the second slave core.

5. The method according to claim 4, characterized in that The method further comprises: During the process of executing the first mirror file startup operation of the second slave core, the master core synchronously sends the second mirror startup instruction to the first slave core, where the second mirror startup instruction is used to instruct the first slave core to execute the second mirror file startup operation of the first slave core.

6. The method according to claim 4, characterized in that When the startup of the first image file of the slave core is completed, the master core sends a second image startup instruction to the slave core, including: When the first image file of the second slave core is started up, the master core sends the second image start instruction to the second slave core; the second image start instruction is used to instruct the second slave core to execute the second image file start operation of the second slave core.

7. The method according to claim 1 or 2, characterized in that: The first image file includes a startup image file, and the first image file startup operation includes: Copying the information in the startup image file of the slave core to the startup file storage interval; The startup address of the startup image file is pointed to the startup file storage interval, and the startup image file is triggered to run.

8. The method according to claim 1 or 2, characterized in that: The second image file includes an application image file, and the second image file startup operation includes: Copying the information in the application image file of the slave core to the application storage interval; Point the startup address of the application image file to the application storage interval and trigger the running of the application Program image file.

9. The method according to claim 1 or 2, characterized in that: The method further comprises: The master core obtains the master core state feedback information after the master core starts running and the slave core state feedback information after the slave core starts running; The master core generates a monitoring message according to the master core state feedback information and the slave core state feedback information; the monitoring message is used to indicate the operating states of the master core and the slave core.

10. A multi-core startup device, characterized in that: The device comprises: A first execution module, configured to execute a first image file startup operation of the slave core in response to a first image startup instruction; The second execution module is used to send a second image startup instruction to the slave core when the first image file startup of the slave core is completed; the second image startup instruction is used to instruct the slave core to execute the second image file startup operation of the slave core.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 9 are implemented.

12. A readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

13. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

Images