Image deployment method and storage

Abstract

The embodiment of the present application provides a mirror deployment method and memory, which relates to the field of computer technology. The method includes: the main boot loader detects the memory type of the memory and sends the memory type to the auxiliary boot loader; the auxiliary boot loader obtains configuration information from the database program based on the memory type, obtains corresponding kernel image information based on the configuration information, and loads the kernel image information; the auxiliary boot loader sends the memory type to the kernel program; the kernel program obtains configuration information in the device tree binary object for superposition based on the memory type, obtains the address of the memory based on the configuration information, and indicates the root program Root loading system based on the address of the memory; the root program loads the system based on the instruction of the kernel program. The method provided by the embodiment of the present application can reduce deployment costs.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a mirror deployment method and a memory. Background Art

[0002] In order to meet the differentiated needs of different industry customer groups, System on Chip (SOC) manufacturers need to provide deployment support for different types of storage chips. Among them, the above storage chips will contain multiple images, such as Primary Bootloader, Secondary Bootloader, Kernel, DTBO and RootFS. In actual applications, each type of storage chip will have images with different contents. Maintaining different images for each of the above storage chips will result in high maintenance and deployment costs, which will have an impact on the enterprise. Summary of the invention

[0003] The embodiments of the present application provide an image deployment method and a storage device to provide a way to deploy images, which can reduce the cost of an enterprise.

[0004] In a first aspect, an embodiment of the present application provides an image deployment method, which is applied to a memory, wherein the memory includes a universal image, and the universal image includes a primary boot loader Primary Bootloader, a secondary boot loader Secondary Bootloader, a device tree binary object for superposition, a kernel program Kernel, and a root program Root, including:

[0005] The primary bootloader detects a memory type of the memory and sends the memory type to the secondary bootloader;

[0006] The secondary bootloader obtains configuration information from the device tree binary object for overlay based on the memory type, obtains corresponding kernel image information based on the configuration information, and loads the kernel image information;

[0007] The secondary bootloader sends the memory type to the kernel program Kernel;

[0008] The kernel program Kernel obtains configuration information in the device tree binary object for overlay based on the memory type, obtains the address of the memory based on the configuration information, and instructs the root program Root to load the system based on the address of the memory;

[0009] The root program Root loads the system based on the instruction of the kernel program Kernel.

[0010] In the embodiment of the present application, by constructing a universal image in the memory, the system on chip can load the universal image when loading, without deploying multiple images in the memory, thereby reducing the cost of image deployment for the enterprise.

[0011] In one possible implementation, the memory types include: multi-chip package MCP, embedded multi-chip package eMCP and multi-chip package uMCP based on universal flash memory storage.

[0012] In one possible implementation manner, configuration information of multiple types of memories is pre-stored in the device tree binary object for overlay.

[0013] In one possible implementation, the root program Root loading the system based on the instruction of the kernel program Kernel includes:

[0014] The root program Root creates a device node based on the memory type;

[0015] The root program Root starts a preparation service based on the device node;

[0016] The root program Root loads the mount point included in the file system table fstab.

[0017] In one possible implementation, after the root program Root loads the mount point included in the file system table fstab, the method further includes:

[0018] If it is detected that the loading point is unloaded, the preparation service is closed.

[0019] In one possible implementation manner, the universal image is obtained by writing a universal image set into the memory.

[0020] In one possible implementation, the universal image set includes a partition image and an intermediate image, the partition image includes a file system map, the intermediate image does not include a file system map, and the intermediate image includes multiple logical blocks; wherein the file system map is used to represent the file system format.

[0021] In one possible implementation manner, each of the logic blocks has the same size, and the size of each of the logic blocks is determined by the capacity of the memory.

[0022] In a second aspect, an embodiment of the present application provides an image deployment device, which is applied to a memory, wherein the memory includes a universal image, and the universal image includes a primary boot loader Primary Bootloader, a secondary boot loader Secondary Bootloader, a device tree binary object for superposition, a kernel program Kernel, and a root program Root, including:

[0023] A detection module, used for the primary bootloader to detect the memory type of the memory and send the memory type to the secondary bootloader;

[0024] A first loading module, used for the secondary bootloader to obtain configuration information from the device tree binary object for overlay based on the memory type, obtain corresponding kernel image information based on the configuration information, and load the kernel image information;

[0025] A sending module, used for the secondary bootloader to send the memory type to the kernel program Kernel;

[0026] an indication module, used for the kernel program Kernel to obtain configuration information in the device tree binary object for overlay based on the memory type, obtain the address of the memory based on the configuration information, and indicate the root program Root to load the system based on the address of the memory;

[0027] The second loading module is used for the root program Root to load the system based on the instruction of the kernel program Kernel.

[0028] In one possible implementation, the memory types include: multi-chip package MCP, embedded multi-chip package eMCP and multi-chip package uMCP based on universal flash memory storage.

[0029] In one possible implementation manner, configuration information of multiple types of memories is pre-stored in the device tree binary object for overlay.

[0030] In one possible implementation, the second loading module is further used to

[0031] The root program Root creates a device node based on the memory type;

[0032] The root program Root starts a preparation service based on the device node;

[0033] The root program Root loads the mount point included in the file system table fstab.

[0034] In one possible implementation, the image deployment device further includes:

[0035] The closing module is used to close the preparation service if it is detected that the loading point is unloaded.

[0036] In one possible implementation manner, the universal image is obtained by writing a universal image set into the memory.

[0037] In one possible implementation, the universal image set includes a partition image and an intermediate image, the partition image includes a file system map, the intermediate image does not include a file system map, and the intermediate image includes multiple logical blocks; wherein the file system map is used to represent the file system format.

[0038] In one possible implementation manner, each of the logic blocks has the same size, and the size of each of the logic blocks is determined by the capacity of the memory.

[0039] In a third aspect, an embodiment of the present application provides a memory, the memory is used to store computer program code, the computer program code includes instructions, the memory includes a universal image, the universal image includes a primary boot loader Primary Bootloader, a secondary boot loader Secondary Bootloader, a device tree binary object for superposition, a kernel program Kernel and a root program Root, when the memory reads the instructions, so that the memory performs the following steps:

[0040] The primary bootloader detects a memory type of the memory and sends the memory type to the secondary bootloader;

[0041] The secondary bootloader obtains configuration information from the device tree binary object for overlay based on the memory type, obtains corresponding kernel image information based on the configuration information, and loads the kernel image information;

[0042] The secondary bootloader sends the memory type to the kernel program Kernel;

[0043] The kernel program Kernel obtains configuration information in the device tree binary object for overlay based on the memory type, obtains the address of the memory based on the configuration information, and instructs the root program Root to load the system based on the address of the memory;

[0044] The root program Root loads the system based on the instruction of the kernel program Kernel.

[0045] In one possible implementation, the memory types include: multi-chip package MCP, embedded multi-chip package eMCP and multi-chip package uMCP based on universal flash memory storage.

[0046] In one possible implementation manner, configuration information of multiple types of memories is pre-stored in the device tree binary object for overlay.

[0047] In one possible implementation, when the instruction is executed by the memory, the step of causing the memory to execute the root program Root to load the system based on the instruction of the kernel program Kernel includes:

[0048] The root program Root creates a device node based on the memory type;

[0049] The root program Root starts a preparation service based on the device node;

[0050] The root program Root loads the mount point included in the file system table fstab.

[0051] In one possible implementation, when the instruction is executed by the memory, after the memory executes the step of the root program Root loading the mount point included in the file system table fstab, it further executes the following steps:

[0052] If it is detected that the loading point is unloaded, the preparation service is closed.

[0053] In one possible implementation manner, the universal image is obtained by writing a universal image set into the memory.

[0054] In one possible implementation, the universal image set includes a partition image and an intermediate image, the partition image includes a file system map, the intermediate image does not include a file system map, and the intermediate image includes multiple logical blocks; wherein the file system map is used to represent the file system format.

[0055] In one possible implementation manner, each of the logic blocks has the same size, and the size of each of the logic blocks is determined by the capacity of the memory.

[0056] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer-readable storage medium is run on a computer, the computer executes the method described in the first aspect.

[0057] In a fifth aspect, an embodiment of the present application provides a computer program, which, when executed by a computer, is used to execute the method described in the first aspect.

[0058] In one possible design, the program in the fifth aspect may be stored in whole or in part on a storage medium packaged together with the processor, or may be stored in whole or in part on a memory not packaged together with the processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 A schematic diagram of a process for image deployment provided in an embodiment of the present application;

[0060] Figure 2 A schematic diagram of a universal image set provided in an embodiment of the present application;

[0061] Figure 3 A schematic diagram of partition image generation provided in an embodiment of the present application;

[0062] Figure 4 A schematic diagram of generating an intermediate image provided in an embodiment of the present application;

[0063] Figure 5 A schematic diagram of the image writing process provided in an embodiment of the present application;

[0064] Figure 6 Provide a schematic diagram of the image deployment process for the embodiment of the present application;

[0065] Figure 7 A schematic diagram of the structure of the image deployment device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0066] The technical solution in the embodiment of the present application will be described below in conjunction with the drawings in the embodiment of the present application. In the description of the embodiment of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0067] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0068] In order to meet the differentiated needs of customer groups in different industries, System on Chip (SOC) manufacturers need to provide deployment support for different types of storage chips. Among them, the above storage chips will contain multiple images, such as the primary boot loader (Primary Bootloader), the secondary boot loader (Secondary Bootloader), the kernel program (Kernel), the device tree binary object for superposition, and the root file system (RootFS) and other images. In actual applications, each type of storage chip will have images with different contents. Maintaining different images for each of the above storage chips will result in high maintenance and deployment costs, which will have an impact on the enterprise.

[0069] Based on the above problems, an embodiment of the present application proposes a mirror deployment method.

[0070] Now combined Figure 1-Figure 6 The mirror image deployment method provided in the embodiment of the present application is described.

[0071] like Figure 1 As shown, it is a flow chart of an embodiment of the image deployment method provided in the embodiment of the present application, including:

[0072] Step 101: Build a universal image set.

[0073] Specifically, the above-mentioned universal image set may include two types of images, for example, a partitioned image (PartitionedImage) and an intermediate image (Intermediate Image). Among them, the above-mentioned partitioned image may be an image that has been generated in a complete file system format. For example, the partition image may include a file system map (FS Maps). The above-mentioned intermediate image may be an image in an intermediate state, and the intermediate image is represented by a logical block. For example, the intermediate image may include multiple logical blocks, and the intermediate image also does not have a specific file system format.

[0074] Now combined Figure 2 , the above-mentioned general image set is explained. Figure 2As shown, the universal image combination 200 may include one or more partition images 201, and / or an intermediate image 202. Partition image 201 may include a first partition label 2011 and a file system map 2012. Intermediate image 202 may include a second partition label 2021. The first partition label 2011 may be used to identify the identity of partition image 201, the file system map 2012 may be predefined by a user, and the file system map 2012 may include file system type information of each partition. The second partition label 2021 may be used to identify the identity of intermediate image 202.

[0075] Next, the generation process of the partition image 101 and the intermediate image 102 is further introduced.

[0076] Now combined Figure 3 The generation process of the partition image 201 is described below. Figure 3 As shown, the input file 300 and the file system map 2012 can be input into the partition image generator 301, thereby generating the corresponding partition image 201. The input file 300 may include a GUID partition table (GUID Partitioned Table, GPT) file, a primary boot loader binary file (Primary Bootloader Binary), a secondary boot loader binary file (Secondary Bootloader Binary), a device tree binary file for overlay (DTBO Binary), a kernel image (Kernel Image), a root file system directory file (Root FS directory), and other mount points directory files (Other mount points directory).

[0077] Next, combine Figure 4 The generation process of the intermediate image 202 is described below. Figure 4 As shown, the size of the input file 300 can be counted first, and the intermediate image 202 can be generated based on the input file 300. The intermediate image 202 exists in the form of a logical block. For example, the intermediate image 202 can be composed of multiple logical blocks, and each logical block has the same size. That is, each logical block can be regarded as a sub-intermediate image. In a specific implementation, the size of each of the above logical blocks can be determined by the capacity of the memory. For example, the mapping relationship between the memory capacity and the logical block size can be preset, so that after the current memory capacity is obtained, the current logical block size can be determined. Table 1 is a mapping table of memory capacity and logical block size.

[0078] Table 1

[0079] Memory capacity Logical block size 512Mbits 16KB 1Gbits 128KB 2Gbits 128KB …

[0080] It is understandable that the above-mentioned values ​​of memory capacity and logic block size are merely exemplary and do not constitute limitations on the embodiments of the present application. In some embodiments, they may also be other values.

[0081] Step 102: Write the universal image set into the memory.

[0082] Specifically, after the general image set is generated, the general image set can be written into the memory. The writing process can include the following sub-steps:

[0083] Step 1021, obtaining the type of memory.

[0084] Specifically, after obtaining the above-mentioned universal image set, the type of memory can be obtained, where the type of memory can include multi-chip package (Multi-Chip Package, MCP), embedded multi-chip package (EmbeddedMulti-Chip Package, eMCP) and multi-chip package based on universal flash storage (Universe Flash StorageBased Multi-Chip Package, uMCP).

[0085] Step 1022: determine the image to be written based on the type of memory.

[0086] Specifically, after the type of memory is obtained, the image to be written can be determined in the general image set based on the type of memory. Exemplarily, if the type of memory is MCP, a partition image that supports an unsorted block image system (UBIFS) or a memory technology device (MTD) can be selected, and the partition image that supports UBIFS or MTD can be written into MCP. Among them, whether the partition image supports UBIFS or MTD can be determined by FS Maps. For example, FS Maps can carry UBIFS or MTD logos, and the UBIFS logo can be used to characterize that the partition image supports UBIFS, and the MTD logo can be used to characterize that the partition image supports MTD. eMCP or uMCP supports partition images in other file system formats other than UBIFS and MTD. That is to say, if the type of memory is eMCP or uMCP, a partition image that does not support UBIFS or MTD can be selected, and a partition image that does not support UBIFS or MTD can be written into eMCP or uMCP. Among them, the above process of writing the image into MCP, eMCP or uMCP can refer to step 1023, which will not be repeated here.

[0087] Furthermore, if the corresponding partition image cannot be selected after determining the type of the memory, an intermediate image can be selected. Exemplarily, if the type of the memory is MCP, and the universal image set does not exist a partition image that supports UBIFS or MTD, at this time, an intermediate image can be selected, and the intermediate image can be written into MCP. If the type of the memory is eMCP or uMCP, and the universal image set does not exist a partition image that does not support UBIFS or MTD, at this time, an intermediate image can be selected, and the intermediate image can be written into eMCP or uMCP. Among them, the above process of writing the image into MCP, eMCP or uMCP can refer to step 1023, which will not be repeated here.

[0088] Step 1023, writing the determined image into the corresponding memory.

[0089] Specifically, if the determined image is a partition image, it can be directly written into the corresponding memory. Exemplarily, if the memory is of MCP type, the partition image supporting UBIFS or MTD can be written into MCP; if the memory is of eMCP type, the partition image not supporting UBIFS or MTD can be written into eMCP; if the memory is of uMCP type, the partition image not supporting UBIFS or MTD can be written into uMCP.

[0090] If the image is determined to be an intermediate image, you can follow the steps below: Figure 5Write according to the process shown.

[0091] Figure 5 The process of writing the intermediate image to the storage includes:

[0092] Step 10231, detect the partition type.

[0093] Specifically, first, the partition type may be detected, wherein the partition type may include a root partition (Root), a data partition (Data), a common partition, and a logical volume manager partition (LVM).

[0094] If the partition type is a root partition or a data partition, step 10231a can be further executed.

[0095] If the partition type is a non-root partition or a non-data partition, step 10231b may be further executed.

[0096] Step 10231a, detect the memory type.

[0097] Specifically, after detecting that the partition type is a root partition or a data partition, the memory type may be further detected.

[0098] If the memory type is MCP, the MCP memory can be written in the MTD format, and the writing task is terminated after writing.

[0099] If the memory type is non-MCP (for example, eMCP or uMCP), the eMCP or uMCP memory may be written in RAW format, and the writing task is terminated after the writing.

[0100] Step 10232, determine whether the partition type is a common partition.

[0101] Specifically, after determining that the partition type is a non-root partition or a non-data partition, it may be further determined whether the partition type is a common partition.

[0102] If the partition type is a normal partition, step 10232a can be further executed.

[0103] If the partition type is a non-ordinary partition (for example, LVM), step 10233 can be further executed.

[0104] Step 10232a, detect the memory type.

[0105] Specifically, after detecting that the partition type is a common partition, the memory type may be further detected.

[0106] If the memory type is MCP, the MCP memory can be written in the MTD+UBIFS format, and the writing task is terminated after writing.

[0107] If the memory type is non-MCP (for example, eMCP or uMCP), the eMCP or uMCP memory may be written in the actual partition format, and the writing task is terminated after the writing.

[0108] Step 10233, detect the memory type.

[0109] Specifically, after detecting that the partition type is an LVM partition, the storage type may be further detected.

[0110] If the memory type is MCP, the MCP memory can be written in the MTD+UBIFS format, and the writing task is terminated after writing.

[0111] If the memory type is non-MCP (for example, eMCP or uMCP), the eMCP or uMCP memory may be written in the actual partition format, and the writing task is terminated after the writing.

[0112] Step 103: deploy the image in the storage.

[0113] Specifically, after the image is written into the memory, the image can be obtained, and then the image can be deployed in the system on chip. For example, the image can be deployed when the system on chip is running. For the specific deployment process, please refer to Figure 6 .

[0114] Figure 6 The deployment process for the above image includes:

[0115] Step 1031, the main boot loader detects the memory type.

[0116] Specifically, the main boot loader may be a program in the image, for example, a first program. The image may be obtained by writing a universal image set into a memory. The main boot loader may detect the type of memory currently connected. The memory type may include MCP, eMCP or uMCP.

[0117] Step 1032 , the primary boot loader sends the detected memory type to the secondary boot loader.

[0118] Specifically, after the primary boot loader detects the memory type, the memory type may be sent to the secondary boot loader, wherein the secondary boot loader may also be another program in the image, for example, a second program.

[0119] Step 1033, the auxiliary boot loader reads the configuration information in the database program based on the memory type, obtains the kernel image information based on the configuration information, loads the kernel image information into the memory, and sends the memory type to the kernel program.

[0120] Specifically, when the auxiliary boot loader receives the memory type sent by the primary boot loader, the configuration information corresponding to the memory type can be read on the database program (DTBO), thereby obtaining the corresponding root directory ( / Root) information. It is understandable that the above configuration information corresponding to the memory type can be pre-stored in the database (DTBO). Then, the kernel image information (for example, kernel.img) can be read under the root directory partition. Since the above-mentioned MCP, eMCP or uMCP and other memories are external memories, the above-mentioned images can be loaded into the memory. For example, the above-mentioned kernel image information can be loaded into the memory. Then, the memory type can be sent to the kernel.

[0121] Step 1034, the kernel program obtains the memory address.

[0122] Specifically, the kernel program may also be a program in the image, such as a third program. When the kernel program receives the memory type sent by the auxiliary boot loader, it can first find the configuration information corresponding to the memory type in the database (DTBO) according to the memory type, and can find the corresponding root directory ( / Root) information in the above configuration information. The root directory ( / Root) information is used to characterize the address corresponding to the memory. For example, MCP can correspond to / Root1, eMCP can correspond to / Root2, and uMCP can correspond to / Root3. Then, the kernel program can find the root program according to the above address corresponding to the memory, and can instruct the root (Root) program to start the system.

[0123] Step 1035, the root program starts the system.

[0124] Specifically, the root program can also be a program in the image, such as the fourth program. When the root program receives the instruction from the kernel program, the root program can create a corresponding device node (dev node) according to the memory type, and can start the corresponding preparation service according to the device node. Then, the root program can also load the mount point (mount point) present in the file system configuration table (fstab), thereby completing the startup of the system. It can be understood that after the above-mentioned mount point is unloaded, the corresponding preparation service can be closed.

[0125] In an embodiment of the present application, a user can generate a universal image for different types of memories (such as MCP, eMCP, and uMCP) in advance, and write the universal image into the above-mentioned different types of memories. Since different types of memories currently have different images, the system on chip needs to maintain multiple images of different types of memories. This leads to higher maintenance and deployment costs. By generating a universal image for different types of memories, the deployment of the images by the memories can be simplified.

[0126] Figure 7 This is a structural diagram of an embodiment of the image deployment device of the present application, such as Figure 7 As shown, the above-mentioned image deployment device 70 is applied to a memory, and the memory contains a universal image, and the universal image includes a primary boot loader Primary Bootloader, a secondary boot loader Secondary Bootloader, a device tree binary object for superposition, a kernel program Kernel and a root program Root, and may include: a detection module 71, a first loading module 72, a sending module 73, an indication module 74 and a second loading module 75; wherein,

[0127] A detection module 71, configured for the primary bootloader to detect a memory type of the memory and send the memory type to a secondary bootloader;

[0128] A first loading module 72, configured for the secondary bootloader to obtain configuration information from the device tree binary object for overlay based on the memory type, obtain corresponding kernel image information based on the configuration information, and load the kernel image information;

[0129] A sending module 73, configured for the secondary bootloader to send the memory type to the kernel program Kernel;

[0130] An indication module 74, configured for the kernel program Kernel to obtain configuration information in the device tree binary object for overlay based on the memory type, obtain an address of the memory based on the configuration information, and indicate the root program Root to load the system based on the address of the memory;

[0131] The second loading module 75 is used for the root program Root to load the system based on the instruction of the kernel program Kernel.

[0132] In one possible implementation, the memory types include: multi-chip package MCP, embedded multi-chip package eMCP and multi-chip package uMCP based on universal flash memory storage.

[0133] In one possible implementation manner, configuration information of multiple types of memories is pre-stored in the device tree binary object for overlay.

[0134] In one possible implementation, the second loading module 75 is further used to

[0135] The root program Root creates a device node based on the memory type;

[0136] The root program Root starts a preparation service based on the device node;

[0137] The root program Root loads the mount point included in the file system table fstab.

[0138] In one possible implementation, the image deployment device further includes:

[0139] The closing module 76 is used to close the preparation service if it is detected that the loading point is unloaded.

[0140] In one possible implementation manner, the universal image is obtained by writing a universal image set into the memory.

[0141] In one possible implementation, the universal image set includes a partition image and an intermediate image, the partition image includes a file system map, the intermediate image does not include a file system map, and the intermediate image includes multiple logical blocks; wherein the file system map is used to represent the file system format.

[0142] In one possible implementation manner, each of the logic blocks has the same size, and the size of each of the logic blocks is determined by the capacity of the memory.

[0143] The embodiment of the present application further provides a memory, the memory is used to store computer program code, the computer program code includes instructions, the memory includes a universal image, the universal image includes a primary boot loader Primary Bootloader, a secondary boot loader Secondary Bootloader, a device tree binary object for superposition, a kernel program Kernel and a root program Root, when the memory reads the instructions, so that the memory performs the following steps:

[0144] The primary bootloader detects a memory type of the memory and sends the memory type to the secondary bootloader;

[0145] The secondary bootloader obtains configuration information from the device tree binary object for overlay based on the memory type, obtains corresponding kernel image information based on the configuration information, and loads the kernel image information;

[0146] The secondary bootloader sends the memory type to the kernel program Kernel;

[0147] The kernel program Kernel obtains configuration information in the device tree binary object for overlay based on the memory type, obtains the address of the memory based on the configuration information, and instructs the root program Root to load the system based on the address of the memory;

[0148] The root program Root loads the system based on the instruction of the kernel program Kernel.

[0149] In one possible implementation, the memory types include: multi-chip package MCP, embedded multi-chip package eMCP and multi-chip package uMCP based on universal flash memory storage.

[0150] In one possible implementation manner, configuration information of multiple types of memories is pre-stored in the device tree binary object for overlay.

[0151] In one possible implementation, when the instruction is executed by the memory, the step of causing the memory to execute the root program Root to load the system based on the instruction of the kernel program Kernel includes:

[0152] The root program Root creates a device node based on the memory type;

[0153] The root program Root starts a preparation service based on the device node;

[0154] The root program Root loads the mount point included in the file system table fstab.

[0155] In one possible implementation, when the instruction is executed by the memory, after the memory executes the step of the root program Root loading the mount point included in the file system table fstab, it further executes the following steps:

[0156] If it is detected that the loading point is unloaded, the preparation service is closed.

[0157] In one possible implementation manner, the universal image is obtained by writing a universal image set into the memory.

[0158] In one possible implementation, the universal image set includes a partition image and an intermediate image, the partition image includes a file system map, the intermediate image does not include a file system map, and the intermediate image includes multiple logical blocks; wherein the file system map is used to represent the file system format.

[0159] In one possible implementation manner, each of the logic blocks has the same size, and the size of each of the logic blocks is determined by the capacity of the memory.

[0160] Through the description of the above implementation methods, technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device and unit described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0161] Each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0162] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as flash memory, mobile hard disk, read-only memory, random access memory, disk or optical disk.

[0163] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A mirror deployment method, applied to a storage device, characterized in that: The memory includes a universal image, and the universal image includes a primary boot loader program Primary Bootloader, a secondary boot loader program Secondary Bootloader, a device tree binary object for superposition, a kernel program Kernel, and a root program Root. The method includes: The primary bootloader detects a memory type of the memory and sends the memory type to the secondary bootloader; The secondary bootloader obtains configuration information from the device tree binary object for overlay based on the memory type, obtains corresponding kernel image information based on the configuration information, and loads the kernel image information; The secondary bootloader sends the memory type to the kernel program Kernel; The kernel program Kernel obtains configuration information in the device tree binary object for overlay based on the memory type, obtains the address of the memory based on the configuration information, and instructs the root program Root to load the system based on the address of the memory; The root program Root loads the system based on the instruction of the kernel program Kernel; The root program Root loads the system based on the instruction of the kernel program Kernel, including: The root program Root creates a device node based on the memory type; The root program Root starts a preparation service based on the device node; The root program Root loads the mount point included in the file system table fstab.

2. The method according to claim 1, characterized in that: The memory types include: multi-chip package MCP, embedded multi-chip package eMCP and multi-chip package uMCP based on universal flash memory storage.

3. The method according to claim 1, characterized in that The device tree binary object for superposition pre-stores configuration information of multiple types of memories.

4. The method according to claim 1, characterized in that After the root program Root loads the mount point included in the file system table fstab, the method further includes: If it is detected that the loading point is unloaded, the preparation service is closed.

5. The method according to any one of claims 1 to 4, characterized in that The general image is obtained by writing a general image set into the memory.

6. The method according to claim 5, characterized in that The universal image set includes a partition image and an intermediate image, the partition image includes a file system map, the intermediate image does not include a file system map, and the intermediate image includes multiple logical blocks; wherein the file system map is used to represent a file system format.

7. The method according to claim 6, characterized in that Each of the logic blocks has the same size, and the size of each of the logic blocks is determined by the capacity of the memory.

8. A memory, characterized in that: Used to perform the method according to any one of claims 1 to 7.

Images