Multistage startup system management method, device, equipment, program product and medium

Abstract

The invention discloses a management method and device of a multi-stage starting system, equipment, a program product and a medium, belongs to the field of computers, is used for performing firmware resource reuse on each stage of boot stage of the multi-stage starting system, and solves the problem of large firmware size of the multi-stage starting system. In the Nth-stage boot stage of the multi-stage startup system, if the to-be-executed function belongs to a non-common module, the to-be-executed function is loaded from the firmware corresponding to the current boot stage, and if the to-be-executed function belongs to a common module, the to-be-executed function is loaded from the firmware of the related boot stage with the minimum stage number of the to-be-executed function, so that the to-be-executed function is loaded. In other words, only one common module of the multi-stage boot stage needs to be set in the firmware of the minimum-stage related boot stage, meanwhile, the storage space and the memory space occupied by the firmware are reduced, and the cost is reduced.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a management method, device, equipment, program product and medium for a multi-level startup system. Background Art

[0002] A multi-stage startup system for a computer system is a startup method that gradually guides a computer system into a normal operating state in stages. The multi-stage startup system includes multiple boot stages. Each boot stage is usually composed of multiple different functional modules, and each functional module is responsible for specific tasks and functions. A single-stage boot stage in the multi-stage startup system usually corresponds to a firmware. The firmware corresponding to each boot stage is usually stored in a storage device and loaded from the storage device to the memory for use when needed. However, since the firmware corresponding to each boot stage is large in size, the storage space and memory space occupied are large, and the cost is increased.

[0003] Therefore, how to provide a solution to the above technical problems is a problem that those skilled in the art need to solve at present. Summary of the invention

[0004] The purpose of the present invention is to provide a management method, device, equipment, program product and medium of a multi-level boot system. In the Nth level boot stage of the multi-level boot system, if the function to be executed belongs to a non-public module, the function to be executed is loaded from the firmware corresponding to the current boot stage. If the function to be executed belongs to a public module, the function to be executed is loaded from the firmware of the related boot stage with the smallest level of the function to be executed. That is, the public module of the multi-level boot stage only needs to be set in the firmware of the related boot stage with the smallest level. At the same time, the storage space and memory space occupied by the firmware are reduced, thereby reducing the cost.

[0005] In order to solve the above technical problems, the present invention provides a management method of a multi-stage startup system, comprising:

[0006] In the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a non-public module, the function to be executed is loaded from the firmware corresponding to the Nth level booting stage and executed; wherein N is any one of 1 to M, M is the total number of levels of the multi-level booting system, and the non-public module refers to: a functional module that needs to be executed in the single-level booting stage;

[0007] In the Nth level boot stage of the multi-level boot system, if the function to be executed belongs to a common module, the function to be executed is loaded and executed from the firmware corresponding to the relevant boot stage with the smallest level of the function to be executed; wherein, the common module refers to: a functional module that needs to be executed by at least two levels of boot stages, and the relevant boot stage refers to: each level of boot stages that needs to execute the function to be executed.

[0008] On the other hand, in the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a common module, loading the function to be executed from the firmware corresponding to the relevant booting stage with the smallest level of the function to be executed and executing the function to be executed includes:

[0009] In the Nth level booting stage of the multi-level booting system, each function to be executed in the current booting stage is executed;

[0010] Among them, the function to be executed includes a jump type function, which is used to search for a target function address in a preset memory space corresponding to the current boot stage according to its own function query information, and use the function in the target function address as the function actually executed by itself.

[0011] On the other hand, the jump type function is specifically used for:

[0012] Based on the function query information it possesses, it determines the target function address corresponding to the function query information from a preset mapping table in a preset memory space corresponding to the current boot stage, and uses the function in the target function address as the function it actually executes;

[0013] The preset mapping table refers to a mapping table between query information and target function addresses.

[0014] On the other hand, the preset memory space corresponding to the current booting stage includes a first sub-memory space and a second sub-memory space;

[0015] The determining, based on the function query information possessed by itself, from a preset mapping table in a preset memory space corresponding to the current boot stage, a target function address corresponding to the function query information comprises:

[0016] The method determines, based on the function query information possessed by the method, a target function address corresponding to the function query information from a preset mapping table in the first sub-memory space;

[0017] If the target function address cannot be determined from the preset mapping table in the first sub-memory space, the target function address corresponding to the function query information is determined from the preset mapping table in the second sub-memory space.

[0018] On the other hand, the preset mapping table and the functions in each target function address in the preset mapping table are all located in the firmware corresponding to the boot stage with the common module and the smallest level in the current boot stage.

[0019] On the other hand, the function query information includes the function number in the preset mapping table to which the function belongs;

[0020] Among them, the function numbers between various preset mapping tables are independent of each other.

[0021] On the other hand, in the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a non-public module, loading the function to be executed from the firmware corresponding to the Nth level booting stage and executing the function includes:

[0022] In the Nth level booting stage of the multi-level booting system, each function to be executed in the current booting stage is executed;

[0023] The to-be-executed function also includes a non-jump type function, and the non-jump type function is located in the firmware corresponding to the current boot stage.

[0024] On the other hand, the computer system where the multi-stage startup system is located includes a system on chip.

[0025] On the other hand, each level of booting stage of the multi-level booting system includes a boot read-only memory as a first level booting stage, a boot loader as a second level booting stage, and a runtime as a third level booting stage;

[0026] Among them, there is a first group of common modules between the first-level boot stage, the second-level boot stage and the third-level boot stage; and there is a second group of common modules between the second-level boot stage and the third-level boot stage.

[0027] On the other hand, the first group of common modules includes a C language standard library, a universal asynchronous receiver / transmitter driver, a timer driver, an encryption driver, a flash memory driver, and a true random number generator driver.

[0028] On the other hand, the management method of the multi-stage startup system also includes:

[0029] After the initialization work of the current boot stage is completed, the image file of the firmware of the next boot stage is loaded from the storage device;

[0030] Verify and decrypt the image file of the next-level boot stage;

[0031] The verified and decrypted image file of the next-level boot stage is loaded into the memory space to carry out the next-level boot stage.

[0032] On the other hand, the management method of the multi-stage startup system also includes:

[0033] After the multi-stage startup system is started, in response to the received function test command, testing the function to be tested pointed to by the function test command;

[0034] Output the test results of the function to be tested.

[0035] On the other hand, in response to the received function test command, testing the function to be tested pointed to by the function test command includes:

[0036] In response to the received function test command, registering the function to be tested pointed to by the function test command into the test framework;

[0037] Execute the function to be tested registered to the test framework and obtain the test result of the function to be tested.

[0038] On the other hand, the function to be tested includes a jump type function;

[0039] The jump type function is used to search for a target function address in a preset memory space corresponding to the current boot stage according to the function query information it possesses, and use the function in the target function address as the function it actually executes;

[0040] The target function address belongs to a memory space where firmware of other booting stages different from the current booting stage is located.

[0041] On the other hand, the function to be tested includes a non-jump type function;

[0042] The non-jump type function is located in the firmware corresponding to the current boot stage.

[0043] On the other hand, the management method of the multi-stage startup system also includes:

[0044] In response to the function test end instruction, classify each test result according to the boot phase of the function to be tested;

[0045] Control the prompter to prompt each classified test result and its corresponding test time;

[0046] The control memory stores each of the classified test results and records the test time corresponding to each of the test results.

[0047] In order to solve the above technical problems, the present invention also provides a management device for a multi-stage startup system, comprising:

[0048] The first action module is used for loading and executing the function to be executed from the firmware corresponding to the Nth level booting stage if the function to be executed belongs to a non-public module in the Nth level booting stage of the multi-level booting system; wherein N is any one of 1 to M, M is the total number of levels of the multi-level booting system, and the non-public module refers to: a functional module that needs to be executed in a single-level booting stage;

[0049] The second action module is used to load and execute the function to be executed from the firmware corresponding to the relevant boot stage with the smallest level of the function to be executed during the Nth level boot stage of the multi-level startup system, if the function to be executed belongs to a common module; wherein the common module refers to: a functional module that needs to be executed by at least two levels of boot stages, and the relevant boot stage refers to: each level of boot stages that needs to execute the function to be executed.

[0050] In order to solve the above technical problems, the present invention also provides a management device for a multi-stage startup system, comprising:

[0051] Memory for storing computer programs;

[0052] The processor is used to implement the steps of the management method of the multi-stage startup system as described above when executing the computer program.

[0053] To solve the above technical problem, the present invention further provides a computer program product, including a computer program / instruction, which implements the steps of the multi-level startup system management method as described above when executed by a processor.

[0054] To solve the above technical problem, the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the multi-level startup system management method as described above are implemented.

[0055] Beneficial effect: The present invention provides a management method for a multi-level boot system. Considering that there are duplications in the functional modules executed in the multi-level boot stages, and the common modules of the multi-level boot stages are set in the firmware of the smallest-level related boot stage, they can be called by other related boot stages. Therefore, in the Nth-level boot stage of the multi-level boot system, if the function to be executed belongs to a non-common module, the function to be executed is loaded from the firmware corresponding to the current boot stage; if the function to be executed belongs to a common module, the function to be executed is loaded from the firmware of the related boot stage with the smallest level with the function to be executed. That is, the common module of the multi-level boot stage only needs to be set in the firmware of the smallest-level related boot stage. At the same time, the storage space and memory space occupied by the firmware are reduced, thereby reducing the cost.

[0056] The present invention also provides a management device, equipment, computer program product and computer-readable storage medium for a multi-stage startup system, which have the same beneficial effects as the management method for a multi-stage startup system. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the relevant technologies and the drawings required for use in the embodiments are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0058] Figure 1 A schematic flow chart of a management method for a multi-stage startup system provided by the present invention;

[0059] Figure 2 A schematic diagram of the working process of a multi-stage starting system provided by the present invention;

[0060] Figure 3 A schematic diagram of the structure of a multi-stage starting system provided by the present invention;

[0061] Figure 4 A schematic diagram of firmware volume comparison provided by the present invention;

[0062] Figure 5 A schematic diagram of the firmware structure of a multi-stage startup system provided by the present invention;

[0063] Figure 6 A schematic diagram of the structure of the memory space of a multi-level startup system provided by the present invention

[0064] Figure 7 A schematic flow chart of another method for managing a multi-stage startup system provided by the present invention;

[0065] Figure 8 A schematic diagram of the structure of a management device for a multi-stage startup system provided by the present invention;

[0066] Fig. 9 A schematic diagram of the structure of a management device for a multi-stage startup system provided by the present invention;

[0067] Fig.10 A schematic diagram of the structure of a computer-readable storage medium provided by the present invention. DETAILED DESCRIPTION

[0068] The core of the present invention is to provide a management method, device, equipment, program product and medium for a multi-level boot system. In the Nth level boot stage of the multi-level boot system, if the function to be executed belongs to a non-public module, the function to be executed is loaded from the firmware corresponding to the current boot stage. If the function to be executed belongs to a public module, the function to be executed is loaded from the firmware of the related boot stage with the smallest level of the function to be executed. That is, the public module of the multi-level boot stage only needs to be set in the firmware of the related boot stage with the smallest level. At the same time, the storage space and memory space occupied by the firmware are reduced, thereby reducing the cost.

[0069] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0070] Please refer to Figure 1 , Figure 1 A schematic flow chart of a management method of a multi-stage startup system provided by the present invention, the management method of the multi-stage startup system comprising:

[0071] S101: In the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a non-public module, the function to be executed is loaded from the firmware corresponding to the Nth level booting stage and executed; wherein N is any one of 1 to M, M is the total number of levels of the multi-level booting system, and the non-public module refers to: a functional module that needs to be executed in a single-level booting stage;

[0072] Specifically, in order to better illustrate the embodiments of the present invention, please refer to Figure 2 , Figure 2 A schematic diagram of the working process of a multi-stage starting system provided by the present invention, Figure 2 The multi-stage boot system in the embodiment may include three boot stages from the first stage to the third stage. After the start, the first stage can be powered on and run automatically with the computer system, and then the hardware is initialized. Then, the next stage (boot stage) firmware can be loaded (from the storage device). After verifying and decrypting the next stage firmware, the next stage firmware can be jumped to the first address (in the memory space) of the next stage firmware to transfer control to the next stage boot stage. After the hardware is initialized, the second stage boot stage can also perform the actions of "loading the next stage firmware, verifying and decrypting the next stage firmware, and jumping to the first address of the next stage firmware". The third stage boot stage is the last stage boot stage, which can initialize the operating system and then enter the scheduler.

[0073] Among them, the first-level boot stage can be BootRom (boot read-only memory), the second-level boot stage can be BootLoader (boot loader), and the third-level boot stage can be RunTime (runtime). Since the firmware corresponding to each level of boot stage will be loaded into the memory in sequence, the control will be handed over to the next level of boot stage after the first level of boot stage ends.

[0074] First of all, it should be noted that each boot stage of the multi-level boot system needs to execute its own functional module, and a single functional module includes at least one function (or API (Application Programming Interface)), and there may be repeated functional modules between different levels of boot stages, so the module can be called a common module, and the common module needs to be executed by at least one boot stage. For a better description of the embodiments of the present invention, please refer to Figure 3 , Figure 3 A schematic diagram of the structure of a multi-stage starting system provided by the present invention, Figure 3 The multi-stage boot system in the embodiment includes three boot stages, namely, a boot read-only memory, a boot loader, and a runtime. The three boot stages can all run on the same processor. Each boot stage needs to execute several functional modules, and there may be repeated functional modules in different boot stages. In the embodiment of the present invention, non-repeated functional modules are placed in the firmware of the boot stage to which they belong. Therefore, in the embodiment of the present invention, in the Nth boot stage of the multi-stage boot system, if the function to be executed belongs to a non-public module (that is, a functional module that only needs to be executed in the current boot stage), the function to be executed can be loaded from the firmware corresponding to the Nth boot stage and executed.

[0075] S102: In the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a common module, the function to be executed is loaded and executed from the firmware corresponding to the relevant booting stage with the smallest level of the function to be executed; wherein, the common module refers to: a functional module that needs to be executed by at least two levels of booting stages, and the relevant booting stage refers to: each level of booting stages that needs to execute the function to be executed.

[0076] Specifically, taking into account the technical problems in the above background technology, and in combination with the fact that there are duplications in the functional modules executed in the multi-level boot stages, and setting the common modules of the multi-level boot stages in the firmware of the smallest related boot stage (the boot stage that needs to execute the functional module), since the previous boot stage will be loaded into the memory first, even if the processor control is transferred to the subsequent boot stage, the subsequent boot stage can also call the function to be tested in the functional module from the memory space for use, that is, for several boot stages "having common modules" in the embodiment of the present invention, the common modules of several boot stages "having common modules" can be stored in the "boot stage with the smallest number of levels". Based on this, the embodiment of the present invention can, in the Nth boot stage of the multi-level startup system, if the function to be executed belongs to the common module, load and execute the function to be executed from the firmware corresponding to the related boot stage with the smallest number of levels of the function to be executed.

[0077] Specifically, under the above measures, for several boot stages "with common modules", the common modules of these boot stages only need to be stored in the "boot stage with the smallest number of levels", and there is no need to store common modules in other boot stages except the "boot stage with the smallest number of levels", thereby reducing the firmware size and saving storage space and memory space.

[0078] The present invention provides a management method for a multi-level boot system. Considering that there are duplications in the functional modules executed in the multi-level boot stages, and the common modules of the multi-level boot stages are set in the firmware of the smallest related boot stage, they can be called by other related boot stages. Therefore, in the Nth level boot stage of the multi-level boot system, if the function to be executed belongs to a non-common module, the function to be executed is loaded from the firmware corresponding to the current boot stage; if the function to be executed belongs to a common module, the function to be executed is loaded from the firmware of the related boot stage with the smallest level with the function to be executed. That is, the common module of the multi-level boot stage only needs to be set in the firmware of the smallest related boot stage, and at the same time, the storage space and memory space occupied by the firmware are reduced, thereby reducing the cost.

[0079] Based on the above embodiments:

[0080] As an optional embodiment, in the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a common module, loading the function to be executed from the firmware corresponding to the relevant booting stage with the smallest level of the function to be executed and executing the function to be executed includes:

[0081] In the Nth level booting stage of the multi-level booting system, each function to be executed in the current booting stage is executed;

[0082] Among them, the function to be executed includes a jump type function, which is used to search for a target function address in a preset memory space corresponding to the current boot stage according to its own function query information, and use the function in the target function address as the function actually executed by itself.

[0083] Specifically, in the embodiments of the present invention, each boot stage at each level can normally execute each to-be-executed function of the current boot stage. For the to-be-executed function "belonging to the common module", in the embodiments of the present invention, it can be set as a jump-type function. The jump-type function can search for the target function address in the preset memory space corresponding to the current boot stage based on the function query information it possesses, and use the function in the target function address as the function it actually executes. That is, the jump-type function can point to another function in the memory and use it as the function actually executed, thereby simplifying the use logic of the common module in the boot stage.

[0084] Of course, in addition to this method, in the relevant boot stages, except for the "boot stage with the smallest number of levels", the method of performing function calls from the memory space of the "boot stage with the smallest number of levels" can also be of many other types, which are not limited in the embodiments of the present invention.

[0085] As an optional embodiment, the jump type function is specifically used for:

[0086] Based on the function query information it possesses, it determines the target function address corresponding to the function query information from a preset mapping table in a preset memory space corresponding to the current boot stage, and uses the function in the target function address as the function it actually executes;

[0087] The preset mapping table refers to a mapping table between query information and target function addresses.

[0088] Specifically, in order to search for the target function address more efficiently and accurately, the embodiment of the present invention sets a "correspondence between function query information and function address" in the preset memory space, so that the target function address can be efficiently and accurately found through the function query information.

[0089] Among them, it is worth mentioning that the preset mapping table can be pre-set in the preset memory space, and can also be set in the firmware where the functional modules involved in the preset mapping table are located, and loaded into the memory space together with the firmware. The embodiment of the present invention is not limited here.

[0090] Of course, in addition to this specific method, the target function address may also be searched in other ways, which are not limited in the embodiment of the present invention.

[0091] As an optional embodiment, the preset memory space corresponding to the current booting stage includes a first sub-memory space and a second sub-memory space;

[0092] Based on the function query information it possesses, determining the target function address corresponding to the function query information from the preset mapping table in the preset memory space corresponding to the current boot stage includes:

[0093] Based on the function query information possessed by itself, determining the target function address corresponding to the function query information from a preset mapping table in the first sub-memory space;

[0094] If the target function address cannot be determined from the preset mapping table in the first sub-memory space, the target function address corresponding to the function query information is determined from the preset mapping table in the second sub-memory space.

[0095] Specifically, considering that there may be problems with the memory and there may be errors in the preset mapping table stored in the memory, the preset memory space in the embodiment of the present invention includes a first sub-memory space and a second sub-memory space, and the preset mapping tables are stored in the first sub-memory space and the second sub-memory space respectively. The second sub-memory space can be used as a backup. When querying the target function address through function query information, the target function address corresponding to the function query information can be first determined from the preset mapping table in the first sub-memory space based on the function query information it possesses. If the target function address cannot be determined from the preset mapping table in the first sub-memory space, the target function address corresponding to the function query information is determined from the preset mapping table in the second sub-memory space. Even if there is a problem with the first sub-memory space or the preset mapping table therein, the target function address can be successfully found from the second sub-memory space.

[0096] As an optional embodiment, the preset mapping table and the functions in each target function address in the preset mapping table are all located in the firmware corresponding to the boot stage with the common module and the smallest level in the current boot stage.

[0097] Specifically, in addition to storing the common modules in the "firmware corresponding to the boot stage with the common modules and the smallest level in the current boot stage", the preset mapping table can also be stored in the "firmware corresponding to the boot stage with the common modules and the smallest level in the current boot stage" to facilitate data management.

[0098] Of course, in addition to this, the preset mapping table may also be stored in other ways, such as independent storage, etc., which is not limited in the embodiment of the present invention.

[0099] As an optional embodiment, the function query information includes a function number in a preset mapping table to which the function belongs;

[0100] Among them, the function numbers between various preset mapping tables are independent of each other.

[0101] Specifically, in order to simplify the function query information and further reduce the amount of data, the function query information in the embodiment of the present invention includes the function number of the function in the preset mapping table to which it belongs. For example, for a multi-level boot system including three-level boot stages of BootRom, BootLoader and RunTime, a first module group can be set for the functional modules shared by the three-level boot stages, and a second module group can be set for the functional modules shared by BootLoader and RunTime. The first module group and its preset mapping table for one can be set in the firmware corresponding to BootRom, and the second module group and its corresponding preset mapping table for another one can be set in the firmware corresponding to BootLoader. Table 1 below is a structural diagram of any preset mapping table. The function number refers to the independent number of each function in the module group corresponding to the preset mapping table in the preset mapping table, and the function address is also the memory address of the function.

[0102] Table 1

[0103] Of course, in addition to the function number, the function query information can also be of other types, such as function name, etc., which is not limited in the embodiment of the present invention.

[0104] As an optional embodiment, in the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a non-public module, loading the function to be executed from the firmware corresponding to the Nth level booting stage and executing the function includes:

[0105] In the Nth level booting stage of the multi-level booting system, each function to be executed in the current booting stage is executed;

[0106] The functions to be executed also include non-jump type functions, and the non-jump type functions are located in the firmware corresponding to the current boot stage.

[0107] Specifically, during the operation of the Nth level boot stage, each function to be executed in the current boot stage can be executed normally. If the function to be executed belongs to a non-public module, that is, a functional module unique to the current boot stage itself, then the function to be executed belongs to a non-jump type function, that is, the function is located in the firmware corresponding to the current boot stage.

[0108] As an optional embodiment, the computer system where the multi-stage startup system is located includes a system on chip.

[0109] Specifically, applying the management method in the embodiment of the present invention to a system on chip (SoC, System on Chip, also known as a system on chip) can reduce the size of the firmware of multiple startup systems, thereby reducing the capacity of the storage device and memory of the upper system, which is conducive to reducing costs.

[0110] Of course, in addition to the system on chip, the computer system where the multi-stage startup system is located can also be of other types, which is not limited in the embodiment of the present invention.

[0111] As an optional embodiment, each level of booting stage of the multi-level booting system includes a boot read-only memory as a first level booting stage, a boot loader as a second level booting stage, and a runtime as a third level booting stage;

[0112] Among them, there is a first group of common modules between the first-level boot stage, the second-level boot stage and the third-level boot stage; and there is a second group of common modules between the second-level boot stage and the third-level boot stage.

[0113] Specifically, the multi-stage boot system of the three boot stages of BootRom, BootLoader and RunTime can concisely and accurately implement the boot process of the computer system.

[0114] Of course, in addition to this specific form, the multi-stage starting system can also be of many other types, which is not limited in the embodiment of the present invention.

[0115] To better illustrate the embodiments of the present invention, please refer to Figures 4 to 6 , Figure 4 A schematic diagram of firmware volume comparison provided by the present invention is shown in FIG. Figure 5 A schematic diagram of the firmware structure of a multi-stage startup system provided by the present invention, Figure 6 A schematic diagram of the structure of the memory space of a multi-stage startup system provided by the present invention. Figure 5 It can be seen that the other modules in each level of booting stage refer to their own unique functional modules. The common modules in the first level booting stage are also the first group of common modules that need to be executed in the three levels of booting stages. The common modules in the second level booting stage are also the second group of common modules that need to be executed in both the second and third levels of booting stages. Correspondingly, each function in the functional modules involved in the first group of common modules can be numbered in the first preset mapping table, and each function in the functional modules involved in the second group of common modules can be numbered in the second preset mapping table. The first preset mapping table is located at address A of the memory space, and the second preset mapping table is located at address B of the memory space.

[0116] Specifically, due to the measure of "storing the functional modules that need to be executed in multiple boot stages only in the related boot stage with the smallest number of levels" in the embodiment of the present invention, the firmware volume corresponding to the "boot stage with common modules deleted" can be directly reduced. For example, in a multi-stage startup system with three boot stages, namely BootRom, BootLoader and RunTime, the firmware volume of BootRom remains unchanged, while the firmware volumes of BootLoader and RunTime boot stages will be reduced.

[0117] Specifically, assuming Figure 6 The first preset mapping table and the second preset mapping table in the system have 256 entries respectively, and each entry occupies 4 bytes. The first preset mapping table and the second preset mapping table occupy 1KB respectively, and the two preset mapping tables occupy 2KB space in total. Assuming that the first group of common modules corresponding to the "first-level boot stage, the second-level boot stage and the third-level boot stage" occupy nKB memory, and the second group of common modules corresponding to the "second-level boot stage and the third-level boot stage" occupy mKB memory, the storage (which can be flash memory) and memory benefits of this method are: 2nKB+mKB-2KB. If n=50KB and m=20KB, the benefits are 118KB. Considering that the firmware is generally stored in multiple copies in Flash, the benefits of Flash are higher.

[0118] As an optional embodiment, the first group of common modules includes a C language standard library, a universal asynchronous receiver / transmitter driver, a timer driver, an encryption driver, a flash memory driver, and a true random number generator driver.

[0119] Specifically, the C language standard library (libc), universal asynchronous receiver and transmitter driver (uart driver), timer driver (timer driver), encryption driver (crypto driver), flash driver (flash driver), and true random number generator driver (TRNG driver) are functional modules that need to be executed in the three boot stages of BootRom, BootLoader, and RunTime.

[0120] Of course, in addition to the above examples, the first group of common modules and the second group of common modules may also be in other specific forms, which are not limited in the embodiments of the present invention.

[0121] As an optional embodiment, the management method of the multi-stage startup system further includes:

[0122] After the initialization work of the current boot stage is completed, the image file of the firmware of the next boot stage is loaded from the storage device;

[0123] Verify and decrypt the image file of the next-level boot stage;

[0124] The verified and decrypted image file of the next-level boot stage is loaded into the memory space to carry out the next-level boot stage.

[0125] Specifically, each level of booting can also be responsible for loading the firmware of the next level of booting, that is, see the attached Figure 2 It can be seen that after the initialization work of the current boot stage is completed, the image file belonging to the firmware of the next boot stage is loaded from the storage device. After the image file of the next boot stage is verified and decrypted, the verified and decrypted image file of the next boot stage is loaded into the memory space for the next boot stage.

[0126] As an optional embodiment, the management method of the multi-stage startup system further includes:

[0127] After the multi-stage startup system is started, in response to the received function test command, the function to be tested pointed to by the function test command is tested;

[0128] Output the test results of the function to be tested.

[0129] Specifically, taking into account the possible need to test functions in a multi-level startup system, and considering that function testing can be performed in the last-level boot stage in the multi-level startup system, in an embodiment of the present invention, after the multi-level startup system is started (that is, in the last-level boot stage), in response to a received function test command, the function to be tested pointed to by the function test command can be tested, and the test result of the function to be tested can be output for easy acquisition by staff.

[0130] As an optional embodiment, in response to a received function test command, testing the function to be tested pointed to by the function test command includes:

[0131] In response to the received function test command, register the function to be tested pointed to by the function test command with the test framework;

[0132] Execute the function to be tested registered to the test framework and obtain the test result of the function to be tested.

[0133] Specifically, in order to better illustrate the embodiments of the present invention, please refer to Figure 7 , Figure 7A flow chart of another multi-stage boot system management method provided by the present invention, wherein the host computer (can be through the serial port) and the Runtime firmware (i.e., the firmware in the runtime boot phase) interact, and the test framework is responsible for distributing the test commands of the host computer and executing the API to be tested, which needs to be registered with the framework. For the function to be tested in the runtime boot phase, the Runtime can call the function to be tested from its own firmware; for BootRom and BootLoader, the API to be tested (in the firmware of the two boot phases, the boot read-only memory and the boot loader) can be exported and imported into the Runtime firmware and registered with the test framework through a jump function. From the perspective of the host computer and the test framework, testing BootRom and BootLoader is just like testing the Runtime's own API.

[0134] As an optional embodiment, the function to be tested includes a jump type function;

[0135] The jump type function is used to search for the target function address in the preset memory space corresponding to the current boot stage according to the function query information it has, and use the function in the target function address as the function it actually executes;

[0136] The target function address belongs to the memory space where the firmware of other booting stages different from the current booting stage is located.

[0137] Specifically, considering that the jump-type function can quickly and accurately point to the "function in the firmware of other boot stages in the memory space", the function to be tested in the embodiment of the present invention may also include a jump-type function, which can search for the target function address in the preset memory space corresponding to the current boot stage according to the function query information it possesses, and use the function in the target function address as the function actually executed by itself. Based on this, even if the boot stage at the previous level has handed over control, the last boot stage can also test the functions in the boot stage of the previous stage, thereby improving the flexibility of the test.

[0138] As an optional embodiment, the function to be tested includes a non-jump type function;

[0139] The non-jump type functions are located in the firmware corresponding to the current boot stage.

[0140] Specifically, in order to quickly and efficiently implement the test of the function in the firmware of the current boot stage, the function to be tested may also include a non-jump type function, that is, directly testing the function in the firmware of the current boot stage.

[0141] As an optional embodiment, the management method of the multi-stage startup system further includes:

[0142] In response to the function test end instruction, classify each test result according to the boot phase of the function to be tested;

[0143] Control the prompter to prompt each classified test result and its corresponding test time;

[0144] The control memory stores each of the classified test results and records the test time corresponding to each of the test results.

[0145] Specifically, considering that the function testing process in the embodiment of the present invention involves function testing in multiple boot stages, the test results finally obtained are relatively complex. In order to facilitate users to clearly obtain the test results of the functions to be tested in each boot stage, the embodiment of the present invention can respond to the function test end instruction, classify each test result according to the boot stage of the function to be tested, and control the prompter to prompt each classified test result and its corresponding test time. In order to facilitate subsequent calls by users, the embodiment of the present invention can also control the memory to store each classified test result and record the corresponding test time of each test result.

[0146] Please refer to Figure 8 , Figure 8 A schematic diagram of the structure of a management device for a multi-stage startup system provided by the present invention, the management device for the multi-stage startup system comprises:

[0147] The first action module 81 is used for loading and executing the function to be executed from the firmware corresponding to the Nth level booting stage if the function to be executed belongs to a non-public module in the Nth level booting stage of the multi-level booting system; wherein N is any one of 1 to M, M is the total number of levels of the multi-level booting system, and the non-public module refers to: a functional module that needs to be executed in a single-level booting stage;

[0148] The second action module 82 is used to load and execute the function to be executed from the firmware corresponding to the relevant boot stage with the smallest level of the function to be executed during the Nth level boot stage of the multi-level boot system, if the function to be executed belongs to a common module; wherein the common module refers to: a functional module that needs to be executed by at least two levels of boot stages, and the relevant boot stage refers to: each level of boot stages that needs to execute the function to be executed.

[0149] Based on the above embodiments:

[0150] As an optional embodiment, the second action module is specifically used for:

[0151] In the Nth level booting stage of the multi-level booting system, each function to be executed in the current booting stage is executed;

[0152] Among them, the function to be executed includes a jump type function, which is used to search for a target function address in a preset memory space corresponding to the current boot stage according to its own function query information, and use the function in the target function address as the function actually executed by itself.

[0153] As an optional embodiment, the jump type function is specifically used for:

[0154] Based on the function query information it possesses, it determines the target function address corresponding to the function query information from a preset mapping table in a preset memory space corresponding to the current boot stage, and uses the function in the target function address as the function it actually executes;

[0155] The preset mapping table refers to a mapping table between query information and target function addresses.

[0156] As an optional embodiment, the preset memory space corresponding to the current booting stage includes a first sub-memory space and a second sub-memory space;

[0157] Based on the function query information it possesses, determining the target function address corresponding to the function query information from the preset mapping table in the preset memory space corresponding to the current boot stage includes:

[0158] Based on the function query information possessed by itself, determining the target function address corresponding to the function query information from a preset mapping table in the first sub-memory space;

[0159] If the target function address cannot be determined from the preset mapping table in the first sub-memory space, the target function address corresponding to the function query information is determined from the preset mapping table in the second sub-memory space.

[0160] As an optional embodiment, the preset mapping table and the functions in each target function address in the preset mapping table are all located in the firmware corresponding to the boot stage with the common module and the smallest level in the current boot stage.

[0161] As an optional embodiment, the function query information includes a function number in a preset mapping table to which the function belongs;

[0162] Among them, the function numbers between various preset mapping tables are independent of each other.

[0163] As an optional embodiment, the first action module is specifically used for:

[0164] In the Nth level booting stage of the multi-level booting system, each function to be executed in the current booting stage is executed;

[0165] The functions to be executed also include non-jump type functions, and the non-jump type functions are located in the firmware corresponding to the current boot stage.

[0166] As an optional embodiment, the computer system where the multi-stage startup system is located includes a system on chip.

[0167] As an optional embodiment, each level of booting stage of the multi-level booting system includes a boot read-only memory as a first level booting stage, a boot loader as a second level booting stage, and a runtime as a third level booting stage;

[0168] Among them, there is a first group of common modules between the first-level boot stage, the second-level boot stage and the third-level boot stage; and there is a second group of common modules between the second-level boot stage and the third-level boot stage.

[0169] As an optional embodiment, the first group of common modules includes a C language standard library, a universal asynchronous receiver / transmitter driver, a timer driver, an encryption driver, a flash memory driver, and a true random number generator driver.

[0170] As an optional embodiment, the management device of the multi-stage startup system further includes:

[0171] The third action module is used to load the image file of the firmware of the next level boot stage from the storage device after the initialization work of the current boot stage is completed;

[0172] The fourth action module is used to verify and decrypt the image file of the next-level boot stage;

[0173] The fifth action module is used to load the verified and decrypted image file of the next-level boot stage into the memory space so as to carry out the next-level boot stage.

[0174] As an optional embodiment, the management device of the multi-stage startup system further includes:

[0175] A sixth action module is used to test the function to be tested pointed to by the function test command in response to the received function test command after the multi-stage startup system is started up;

[0176] The seventh action module is used to output the test result of the function to be tested.

[0177] As an optional embodiment, the sixth action module includes:

[0178] A registration module, for registering the function to be tested pointed to by the function test command into the test framework in response to the received function test command;

[0179] The execution module is used to execute the function to be tested registered to the test framework and obtain the test result of the function to be tested.

[0180] As an optional embodiment, the function to be tested includes a jump type function;

[0181] The jump type function is used to search for the target function address in the preset memory space corresponding to the current boot stage according to the function query information it has, and use the function in the target function address as the function it actually executes;

[0182] The target function address belongs to the memory space where the firmware of other booting stages different from the current booting stage is located.

[0183] As an optional embodiment, the function to be tested includes a non-jump type function;

[0184] The non-jump type functions are located in the firmware corresponding to the current boot stage.

[0185] As an optional embodiment, the management device of the multi-stage startup system further includes:

[0186] A classification module, for responding to a function test end instruction, classifying each test result according to the boot phase of the function to be tested;

[0187] An eighth action module is used to control the prompter to prompt each classified test result and its corresponding test time;

[0188] The ninth action module is used to control the memory to store the classified test results and record the test time corresponding to each test result.

[0189] For an introduction to the management device of the multi-stage startup system provided by the embodiment of the present invention, please refer to the embodiment of the management method of the multi-stage startup system described above, and the embodiment of the present invention will not be described in detail here.

[0190] Please refer to Fig. 9 , Fig. 9 A schematic diagram of the structure of a management device of a multi-stage startup system provided by the present invention, wherein the management device of the multi-stage startup system comprises:

[0191] A memory 91, used for storing computer programs;

[0192] The processor 92 is used to implement the steps of the multi-stage startup system management method in the above-mentioned embodiment when executing the computer program.

[0193] For an introduction to the management device of the multi-stage startup system provided by the embodiment of the present invention, please refer to the embodiment of the management method of the multi-stage startup system described above, and the embodiment of the present invention will not be described in detail here.

[0194] The present invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the management method of the multi-stage startup system in the aforementioned embodiment.

[0195] For an introduction to the computer program product provided by the embodiment of the present invention, please refer to the aforementioned embodiment of the management method of the multi-stage startup system, and the embodiment of the present invention will not be described in detail here.

[0196] Please refer to Fig.10 , Fig.10 This is a schematic diagram of the structure of a computer-readable storage medium provided by the present invention. A computer program 102 is stored on the computer-readable storage medium 101. When the computer program 102 is executed by the processor, the steps of the management method of the multi-level startup system in the aforementioned embodiment are implemented.

[0197] For an introduction to the computer-readable storage medium provided in the embodiment of the present invention, please refer to the aforementioned embodiment of the management method of the multi-stage startup system, and the embodiment of the present invention will not be described in detail here.

[0198] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same and similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should also be noted that in this specification, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such process, method, article or equipment. In the absence of more restrictions, the elements defined by the sentence "including one..." do not exclude the existence of other identical elements in the process, method, article or equipment including the element.

[0199] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A management method for a multi-stage startup system, characterized in that: include: In the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a non-public module, the function to be executed is loaded from the firmware corresponding to the Nth level booting stage and executed; wherein N is any one of 1 to M, M is the total number of levels of the multi-level booting system, and the non-public module refers to: a functional module that needs to be executed in the single-level booting stage; In the Nth level boot stage of the multi-level boot system, if the function to be executed belongs to a common module, the function to be executed is loaded and executed from the firmware corresponding to the relevant boot stage with the smallest level of the function to be executed; wherein, the common module refers to: a functional module that needs to be executed by at least two levels of boot stages, and the relevant boot stage refers to: each level of boot stages that needs to execute the function to be executed.

2. The management method of the multi-stage startup system according to claim 1, characterized in that: In the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a common module, loading the function to be executed from the firmware corresponding to the relevant booting stage with the smallest level of the function to be executed and executing the function to be executed includes: In the Nth level booting stage of the multi-level booting system, each function to be executed in the current booting stage is executed; Among them, the function to be executed includes a jump type function, which is used to search for a target function address in a preset memory space corresponding to the current boot stage according to its own function query information, and use the function in the target function address as the function actually executed by itself.

3. The management method of the multi-stage startup system according to claim 2, characterized in that: The jump type function is specifically used for: Based on the function query information it possesses, it determines the target function address corresponding to the function query information from a preset mapping table in a preset memory space corresponding to the current boot stage, and uses the function in the target function address as the function it actually executes; The preset mapping table refers to a mapping table between query information and target function addresses.

4. The management method of the multi-stage startup system according to claim 3, characterized in that: The preset memory space corresponding to the current booting stage includes a first sub-memory space and a second sub-memory space; The determining, based on the function query information possessed by itself, from a preset mapping table in a preset memory space corresponding to the current boot stage, a target function address corresponding to the function query information comprises: The method determines, based on the function query information possessed by the method, a target function address corresponding to the function query information from a preset mapping table in the first sub-memory space; If the target function address cannot be determined from the preset mapping table in the first sub-memory space, the target function address corresponding to the function query information is determined from the preset mapping table in the second sub-memory space.

5. The management method of the multi-stage startup system according to claim 3, characterized in that: The preset mapping table and the functions in each target function address in the preset mapping table are all located in the firmware corresponding to the boot stage with a common module and the smallest level in the current boot stage.

6. The management method of the multi-stage startup system according to claim 5, characterized in that: The function query information includes the function number in the preset mapping table to which the function belongs; Among them, the function numbers between various preset mapping tables are independent of each other.

7. The management method of the multi-stage startup system according to claim 2, characterized in that: In the Nth level booting stage of the multi-level booting system, if the function to be executed belongs to a non-public module, loading the function to be executed from the firmware corresponding to the Nth level booting stage and executing the function includes: In the Nth level booting stage of the multi-level booting system, each function to be executed in the current booting stage is executed; The to-be-executed function also includes a non-jump type function, and the non-jump type function is located in the firmware corresponding to the current boot stage.

8. The management method of the multi-stage startup system according to claim 1, characterized in that: The computer system where the multi-stage startup system is located includes a system on chip.

9. The management method of the multi-stage startup system according to claim 8, characterized in that: Each level of booting stage of the multi-level booting system includes a boot read-only memory as a first level booting stage, a boot loader as a second level booting stage, and a runtime as a third level booting stage; Among them, there is a first group of common modules between the first-level boot stage, the second-level boot stage and the third-level boot stage; and there is a second group of common modules between the second-level boot stage and the third-level boot stage.

10. The management method of the multi-stage startup system according to claim 9, characterized in that: The first group of common modules includes a C language standard library, a universal asynchronous receiver / transmitter driver, a timer driver, an encryption driver, a flash memory driver, and a true random number generator driver.

11. The management method of the multi-stage startup system according to claim 1, characterized in that: The management method of the multi-stage startup system also includes: After the initialization work of the current boot stage is completed, the image file of the firmware of the next boot stage is loaded from the storage device; Verify and decrypt the image file of the next-level boot stage; The verified and decrypted image file of the next-level boot stage is loaded into the memory space to carry out the next-level boot stage.

12. The management method of a multi-stage startup system according to any one of claims 1 to 11, characterized in that: The management method of the multi-stage startup system also includes: After the multi-stage startup system is started, in response to the received function test command, testing the function to be tested pointed to by the function test command; Output the test results of the function to be tested.

13. The management method of the multi-stage startup system according to claim 12, characterized in that: In response to the received function test command, testing the function to be tested pointed to by the function test command includes: In response to the received function test command, registering the function to be tested pointed to by the function test command into the test framework; Execute the function to be tested registered to the test framework and obtain the test result of the function to be tested.

14. The management method of the multi-stage startup system according to claim 13, characterized in that: The function to be tested includes a jump type function; The jump type function is used to search for a target function address in a preset memory space corresponding to the current boot stage according to the function query information it possesses, and use the function in the target function address as the function it actually executes; The target function address belongs to a memory space where firmware of other booting stages different from the current booting stage is located.

15. The management method of the multi-stage startup system according to claim 14, characterized in that: The function to be tested includes a non-jump type function; The non-jump type function is located in the firmware corresponding to the current boot stage.

16. The management method of the multi-stage startup system according to claim 14, characterized in that: The management method of the multi-stage startup system also includes: In response to the function test end instruction, classify each test result according to the boot phase of the function to be tested; Control the prompter to prompt each classified test result and its corresponding test time; The control memory stores each of the classified test results and records the test time corresponding to each of the test results.

17. A management device for a multi-stage startup system, characterized in that: include: The first action module is used for loading and executing the function to be executed from the firmware corresponding to the Nth level booting stage if the function to be executed belongs to a non-public module in the Nth level booting stage of the multi-level booting system; wherein N is any one of 1 to M, M is the total number of levels of the multi-level booting system, and the non-public module refers to: a functional module that needs to be executed in a single-level booting stage; The second action module is used to load and execute the function to be executed from the firmware corresponding to the relevant boot stage with the smallest level of the function to be executed during the Nth level boot stage of the multi-level startup system, if the function to be executed belongs to a common module; wherein the common module refers to: a functional module that needs to be executed by at least two levels of boot stages, and the relevant boot stage refers to: each level of boot stages that needs to execute the function to be executed.

18. A management device for a multi-stage startup system, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the multi-stage startup system management method as claimed in any one of claims 1 to 16 when executing the computer program.

19. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the method for managing a multi-stage startup system according to any one of claims 1 to 16 are implemented.

20. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the management method of the multi-stage startup system according to any one of claims 1 to 16 are implemented.

Images