CN117472455A - Startup method and device based on embedded equipment - Google Patents
Startup method and device based on embedded equipment Download PDFInfo
- Publication number
- CN117472455A CN117472455A CN202311526703.3A CN202311526703A CN117472455A CN 117472455 A CN117472455 A CN 117472455A CN 202311526703 A CN202311526703 A CN 202311526703A CN 117472455 A CN117472455 A CN 117472455A
- Authority
- CN
- China
- Prior art keywords
- file
- compressed file
- compressed
- size
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 104
- 230000006837 decompression Effects 0.000 claims description 35
- 238000007906 compression Methods 0.000 claims description 20
- 230000006835 compression Effects 0.000 claims description 19
- 238000012795 verification Methods 0.000 claims description 6
- 230000008569 process Effects 0.000 description 17
- 238000004891 communication Methods 0.000 description 8
- 238000004590 computer program Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4406—Loading of operating system
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention provides a startup method and device based on embedded equipment, electronic equipment and a computer storage medium, wherein the startup method and device comprises the following steps: powering on the embedded equipment, wherein the embedded equipment stores compressed files; in the starting stage, the compressed file is initially decompressed to obtain the size and offset address of the compressed file; at the kernel stage, decompressing the compressed file according to the size and offset address of the compressed file obtained at the starting stage to obtain file data; and starting and running file data. Therefore, the time consumption for loading the compressed files into the random access memory after the files are compressed is reduced, meanwhile, the compressed files are decompressed respectively in the starting and kernel phases, so that the storage space of the read-only memory can be saved when the compressed files are stored in the kernel phase, the starting time after the compressed files are decompressed can be saved, the starting time is optimized, and the problem that the starting time of the existing embedded equipment adopting the split type storage scheme is too long is solved.
Description
Technical Field
The present invention relates to the field of communications devices and Linux systems, and in particular, to a startup method and apparatus based on an embedded device, an electronic device, and a computer storage medium.
Background
With the advent of the age of networks, communications, multimedia, and information appliances, embedded systems have been applied on a large scale, and various new devices almost all use embedded systems, among which Linux systems are the most commonly used. In the Linux system, most of the modes are bootloader+kernel+rootfs, wherein the bootloader is uboot and is responsible for initializing hardware and setting a software environment, then kernel is loaded and operated, and after kernel is operated, rootfs is unloaded, so that the Linux system operates normally.
When the capacity requirements of the embedded device on the ROM (read only memory) and the RAM (random access memory) are high, in order to reduce the cost, a split storage (split memory) scheme is generally adopted, that is, the memory of the device is divided into a plurality of levels, each level has different performance and characteristics, so that a proper memory level is selected according to different application scenarios and requirements to provide efficient computing and storage capability. Currently, in a common split storage scheme, the memory is generally divided into three levels, i.e., an L1 cache, a main memory and an auxiliary memory. The L1 cache has higher access speed but smaller capacity; the main memory can store more data, but the access speed is slower; the secondary memory is typically an external storage device that has a larger capacity but slower access speed.
Therefore, when loading a large file, the existing split storage scheme takes too long, so that the overall starting time of the embedded device is influenced, and the use experience of a user is poor.
Disclosure of Invention
The invention aims to provide a startup method based on embedded equipment, which at least solves the problem that the startup time of the existing embedded equipment adopting a separate storage scheme is too long.
In order to solve the technical problems, the invention provides a startup method based on embedded equipment, which comprises the following steps:
powering on the embedded equipment, wherein the embedded equipment stores compressed files;
in the starting stage, the compressed file is initially decompressed to obtain the size and offset address of the compressed file;
at the kernel stage, decompressing the compressed file according to the size and offset address of the compressed file obtained at the starting stage to obtain file data;
and starting and running file data.
Optionally, in the method for starting up an embedded device, the method for obtaining the compressed file includes:
acquiring a large file;
compressing the large file by using a file compression tool to obtain a compression package;
the compressed package is signed to obtain a compressed file.
Optionally, in the method for starting up an embedded device, in the starting up stage, the method for initially decompressing the compressed file to obtain the size and offset address of the compressed file includes:
acquiring the approximate position of a data structure body for decoupling shared memory information in a compressed file;
the data structure at the approximate location of the compressed file is decompressed to obtain the size and offset address of the compressed file.
Optionally, in the method for booting an embedded device, the method for decompressing the data structure body at the approximate location of the compressed file to obtain the size and offset address of the compressed file includes:
initializing the bottom hardware device and stack, and starting loading mode;
judging the starting-up mode to enter a corresponding starting-up mode;
the compressed file is loaded and the data structure at the approximate location of the compressed file is decompressed to obtain the size and offset address of the compressed file.
Optionally, in the method for booting an embedded device, the method for decompressing the data structure body at the approximate location of the compressed file to obtain the size and offset address of the compressed file includes:
acquiring the size of a data structure body and positioning the data structure body at the approximate position of a compressed file;
decompressing the compressed file with the data size matched with the size of the data structure body at the approximate position of the compressed file to obtain decompressed data;
if the size of the decompressed data exceeds the size of the data structure, intercepting the data matched with the size of the data structure from the decompressed data, and assigning the intercepted data to the data structure to obtain the decompressed data structure;
the size and offset address of the compressed file are read from the decompressed data structure.
Optionally, in the method for starting up an embedded device, the method for decompressing the compressed file according to the size and offset address of the compressed file obtained in the starting up stage in the kernel stage to obtain file data includes:
loading a compressed file;
verifying the signature of the compressed file;
and if the verification is passed, decompressing the compressed file to obtain file data.
Optionally, in the startup method based on the embedded device, before decompressing the compressed file, the method for decompressing the compressed file according to the size and the offset address of the compressed file obtained in the startup stage in the kernel stage to obtain the file data further includes:
judging whether the loaded file is a compressed file or not;
if the compressed file is judged, decompressing the compressed file;
if the non-compressed file is judged, the normal loading flow is executed for the non-compressed file.
Optionally, in the method for starting up based on the embedded device, the method for judging whether the loaded file is a compressed file includes:
when loading a file, first three bytes of the file are loaded;
judging whether the first three bytes are 1F, 8B and 08 respectively;
if the first three bytes are 1F, 8B and 08 respectively, the file is judged to be a compressed file, otherwise, the file is not a compressed file.
Optionally, in the method for booting based on an embedded device, the method for verifying the signature of the compressed file includes:
storing the loaded compressed file in an idle memory in a continuous address mode;
and verifying the compressed file by using a security authentication tool.
Optionally, in the method for booting based on an embedded device, the method for decompressing the compressed file includes:
according to the use condition of the compressed file, the compressed file is decompressed partially or completely by using a file decompression tool, wherein the method for decompressing by using the file decompression tool comprises the following steps:
setting a CHUNK value and opening a compressed file;
reading data in [ CHUNK ] from the compressed file;
decompressing in [ CHUNK ] to obtain decompressed file data;
judging whether the size of the file data is smaller than a CHUNK value or not;
if the size of the file data is not smaller than the CHUNK value, writing the file data into out [ CHUNK ];
and judging whether the readable size of the compressed file is smaller than 0, if so, closing the compressed file, otherwise, reading the data in [ CHUNK ] from the compressed file again.
In order to solve the technical problem, the invention also provides a startup device based on the embedded device, which is used for realizing the startup method based on the embedded device, comprising the following steps:
the power-on module is used for powering on the embedded equipment, and the embedded equipment stores compressed files;
the compression module is used for compressing the large file to obtain a compressed file;
the decompression module comprises a preliminary decompression unit and a complete decompression unit; the initial decompression unit is used for initially decompressing the compressed file in the starting stage to obtain the size and offset address of the compressed file; the complete decompression unit is used for decompressing the compressed file according to the size and offset address of the compressed file obtained in the starting stage in the kernel stage to obtain file data;
and the starting module is used for starting and running the file data.
In order to solve the technical problem, the invention also provides electronic equipment, which comprises a memory, a processor and an executable program which is stored in the memory and can be run by the processor; the processor, when running the executable program, performs the embedded device-based boot method as set forth in any one of the preceding claims.
To solve the above technical problem, the present invention also provides a computer storage medium storing an executable program; the executable program, when executed, implements the embedded device-based boot method as described in any of the above.
The invention provides a startup method and a startup device based on embedded equipment, electronic equipment and a computer storage medium, wherein the startup method and the startup device based on the embedded equipment comprise the following steps: powering on the embedded equipment, wherein the embedded equipment stores compressed files; in the starting stage, the compressed file is initially decompressed to obtain the size and offset address of the compressed file; at the kernel stage, decompressing the compressed file according to the size and offset address of the compressed file obtained at the starting stage to obtain file data; and starting and running file data. By initially decompressing the compressed file in the startup phase and decompressing the compressed file in the kernel phase, the time consumption for loading the compressed file into the random access memory after the file is compressed can be reduced, and meanwhile, the storage space of the read-only memory can be saved when the compressed file is stored in the kernel phase due to the fact that the compressed file is decompressed in the startup phase and the kernel phase respectively, and then the startup time of the compressed file after decompression can be saved, so that the startup time is optimized, and the problem that the startup time of the existing embedded device adopting the split storage scheme is too long is solved.
Drawings
Fig. 1 is a flowchart of a boot method based on an embedded device according to the present embodiment;
FIG. 2 is a flowchart of a preliminary decompression of a compressed file at a startup stage according to the present embodiment;
FIG. 3 is a flowchart of decompressing a compressed file at the kernel stage according to the present embodiment;
fig. 4 is a boot flow chart of the embedded device according to the present embodiment;
FIG. 5 is a schematic diagram of a process for decompressing a modem at the kernel stage according to the present embodiment;
fig. 6 is a schematic structural diagram of a boot device based on an embedded device according to the present embodiment.
Detailed Description
The method for starting up the embedded device according to the present invention is described in further detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the drawings are in a very simplified form and are all to a non-precise scale, merely for convenience and clarity in aiding in the description of embodiments of the invention. Furthermore, the structures shown in the drawings are often part of actual structures. In particular, the drawings are shown with different emphasis instead being placed upon illustrating the various embodiments.
It is noted that "first", "second", etc. in the description and claims of the present invention and the accompanying drawings are used to distinguish similar objects so as to describe embodiments of the present invention, and not to describe a specific order or sequence, it should be understood that the structures so used may be interchanged under appropriate circumstances. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
The embodiment provides a startup method based on embedded equipment, as shown in fig. 1, including:
s1, powering on embedded equipment, wherein the embedded equipment stores compressed files;
s2, in a starting (uboot) stage, performing preliminary decompression on the compressed file to obtain the size and offset address of the compressed file;
s3, decompressing the compressed file according to the size and offset address of the compressed file obtained in the starting stage in a kernel stage to obtain file data;
s4, starting and operating the file data.
According to the startup method based on the embedded device, the compressed file is initially decompressed in the startup phase, and the compressed file is decompressed in the kernel phase, so that time consumption for loading the compressed file into the random access memory after the file is compressed can be reduced, meanwhile, the compressed file is respectively decompressed in the startup phase and the kernel phase, so that the storage space of the read-only memory can be saved when the compressed file is stored in the kernel phase, further, the startup time after the compressed file is decompressed can be saved, the startup time is optimized, and the problem that the startup time of the existing embedded device adopting the split storage scheme is too long is solved.
Considering that in the practical application process, a file with a small number of uses and a large disk space is generally selected as a compression object, for example, kernel. Img, ramdisk, modem. Img, etc., in this embodiment, the method for obtaining the compressed file includes: firstly, acquiring large files, namely files with less using times and more occupied disk space; then, compressing the large file by using a file compression tool to obtain a compressed package; finally, the compressed package is signed to obtain a compressed file.
Specifically, the file compression tool adopted in the embodiment is gzip, which is a command for compressing and decompressing files, which is frequently used in a Linux system, and is convenient and easy to use. The gzip command is statistically 60% -70% compressed to the text file. In this embodiment, to ensure consistency of compression results, the compression tool employs gzip version 1.6.
In addition, there are two ways of compressing files that are currently in common use: one is compression-before-signature, the other is signature-before-compression. Since the first method searches for a download tool (research download) and the signature verification process does not include decompression, the object requiring signature for the compressed package is a compressed package, and the object requiring signature in the second method is a complete package, in order to avoid modification of the download tool, the embodiment adopts the first method, that is, the method of compressing before signing, to compress the large file. And, in this embodiment, both the location of the OTA upgrade package and the location of the normal package are after the signature, so the compression action is equally effective for the OTA upgrade.
Further, in this embodiment, step S2, in the start-up phase, the method for initially decompressing the compressed file to obtain the size and offset address of the compressed file includes:
s21, the approximate position of the data structure body for decoupling the shared memory information in the compressed file is obtained.
The shared memory information is typically provided by the communication processor, including the size and offset address of each file of the communication processor. Therefore, in the startup phase, the present embodiment needs to acquire the approximate location of the data structure for decoupling the shared memory information of the application processor or the communication processor, so as to decompress the data structure. Taking the modem file as an example, the data structure is located at the header of the modem file, so that in the startup phase, a part of the data structure needs to be fetched from the header of the modem file for decoupling the shared memory information of the application processor or the communication processor.
S22, decompressing the data structure body at the approximate position of the compressed file to obtain the size and the offset address of the compressed file.
Since it is difficult to obtain the original data at a specific location of the compressed file after the large file is compressed, the location is not changed, and the size of the data structure is known, so the size of the data to be decompressed is also constant.
Specifically, in the present embodiment, the method for decompressing the data structure body at the approximate location of the compressed file includes: firstly, acquiring the size of a data structure body and the approximate position of the data structure body in a compressed file; then, decompressing the compressed file with the data size matched with the size of the data structure body at the approximate position of the compressed file to obtain decompressed data; then, judging the size of the decompressed data, if the size of the decompressed data exceeds the size of the data structure, intercepting the data matched with the size of the data structure from the decompressed data, and assigning the intercepted data to the data structure to obtain the decompressed data structure; finally, the size and offset address of the compressed file are read from the decompressed data structure.
In the actual application process, as shown in fig. 2, taking a modem file as an example, the process of performing preliminary decompression on a compressed file in the uboot stage generally includes: firstly, initializing a hardware device and a stack at the bottom layer, and starting a loading mode; then judging the starting mode to enter a corresponding starting mode; then, loading the modem compressed file, and decompressing header information (a data structure body at a rough position) of the modem compressed file to obtain the size and offset address of the compressed file; then, loading kernel, transferring modem information (including the size and offset address of the compressed file), creating cmdline and loading CP2; finally, jump to kernel and end uboot phase.
Further, in this embodiment, step S3, in the kernel stage, according to the size and offset address of the compressed file obtained in the starting stage, decompresses the compressed file to obtain file data, where the method includes:
s31, loading the compressed file.
S32, verifying the signature of the compressed file.
Specifically, in this embodiment, a secure authentication tool is used to sign a compressed file, in this embodiment, secure boot is specifically used to sign a compressed file, and a secure boot verification object needs to be stored in a memory first in a continuous address manner, so the method for sign verification provided in this embodiment includes: firstly, storing the loaded compressed file in an idle memory in a continuous address mode; and then signing the compressed file by utilizing the secureboot. The idle memory can be used for placing the compressed file when the compressed file is not loaded, and can store data after the compressed file runs, so that the use efficiency of the memory is improved.
And S33, if the verification is passed, decompressing the compressed file to obtain file data.
Specifically, in this embodiment, according to the usage situation of the compressed file, the compressed file is partially decompressed or completely decompressed by using the file decompression tool, and in this embodiment, zlib is selected as the file decompression tool. As shown in fig. 3, the method for decompressing the compressed file includes: firstly, setting a CHUNK value and opening a compressed file; then, reading the data in [ CHUNK ] from the compressed file; then decompressing in [ CHUNK ] to obtain decompressed file data, wherein in the actual decompression process, the size of the decompressed file data can be CHUNK value or the decompressed file data can be decompressed to the tail of in [ CHUNK ]; then, judging whether the size of the file data is smaller than a CHUNK value; if the size of the file data is not smaller than the CHUNK value, writing the file data into out [ CHUNK ]; if the size of the file data is smaller than the CHUNK value, returning to the previous step, and decompressing in [ CHUNK ]; and finally, judging whether the readable size of the compressed file is smaller than 0, if so, closing the compressed file, otherwise, reading the data in [ CHUNK ] from the compressed file again.
Preferably, considering that when a file is loaded, the file may be directly loaded for an uncompressed file, in this embodiment, before the compressed file is decompressed, it is necessary to determine whether the loaded file is a compressed file. If the compressed file is judged, decompressing the compressed file; if the non-compressed file is determined, a normal loading procedure is executed on the non-compressed file, where the normal loading procedure is well known to those skilled in the art, and the disclosure is omitted herein.
The embodiment also provides a specific method for judging whether the file is an uncompressed file, which comprises the following steps: when loading a file, first three bytes of the file are loaded; judging whether the first three bytes are 1F, 8B and 08 (which are marks of the compressed file) respectively; if the first three bytes are 1F, 8B and 08 respectively, the file is judged to be a compressed file, otherwise, the file is not a compressed file. Therefore, the compressed file and the uncompressed file can be distinguished when the file is loaded, and the time consumption for subsequent decompression is saved.
In the following, taking a modem file as an example, the effect of the boot method based on the embedded device provided in the application on saving the boot time is specifically described.
It should be noted that, the startup method based on the embedded device provided in this embodiment may be implemented not only on the modem, but also in the file loading process with larger volumes and fewer operation times. In addition, for different embedded devices, as long as the embedded device is a small memory, an embedded device with a modem, or an embedded device capable of compressing partitions, the startup method based on the embedded device provided by the application can be adopted.
In this embodiment, the ROM of the embedded device uses Nand flash memory, and the RAM uses DDR.
Since the block control and data reading of Nand flash memory are performed by the main chip, large files such as kernel. Img occupy a lot of starting time during a single line in the uboot stage, and occupy a part of processor resources after kernel is started (loading modem. Img is at this stage). Therefore, the embodiment compresses the large files to obtain the modem compressed file, so as to achieve better optimization effect and save storage space.
Specifically, in this embodiment, the modem compressed file includes large files such as modem. Bin, dm_dsp, ltea_dsp, and nvite. In addition, in order to decouple the shared memory of the application processor or the communication processor, the present embodiment writes information such as the size and offset address of the modem file in the header data structure of the modem file. That is, when the modem compressed file is decompressed by using the boot method provided in the present embodiment, the header of the modem file needs to be decompressed in the uboot stage, and the modem compressed file needs to be decompressed in the kernel stage. The specific decompression process is described above, and is not described in detail in this application.
In general, the code file is read from the ROM to the RAM only once at a specific stage, and the code file is decompressed and placed into a specific memory address at the time of reading. As shown in FIG. 4, the modem loading position is after kernel start, so that the process of adding zlib support in kernel and adding decompression after loading the modem compressed file can complete modem compression start.
As shown in fig. 5, the process of decompressing the modem in the kernel phase generally includes: the modem compressed file is read to a ROM data space, and then the modem compressed file is placed in an idle memory of a RAM, and the modem code file space is not used at the moment; and checking the signature of the modem compressed file, if the signature is successful, decompressing the modem compressed file, wherein the modem code file space is used, and the modem is started successfully and operates normally.
By comparing the sizes of the files before and after compression, it is known that the present embodiment uses gzip with a compression ratio of 60% for modem. Bin, 25% for DM_DSP, 24% for LTEA_DSP, and 11% for nvite, wherein the lower the compression ratio, the better the compression effect. The modem is compressed and started by using the starting method provided by the embodiment, so that 8.6MB of Flash storage space is saved.
In addition, in this embodiment, the zlib decompression tool is adopted, which takes several milliseconds to complete decompression, and can be ignored (the modem decompression time in the memory is far less than the modem transmission time on the Nand flash memory). The read speed of the Nand flash memory is about 4.2MB/s, and the boot method provided by the embodiment can save about 2s of boot time theoretically under the assumption of the same loading speed. By comparing the boot log file loaded by the non-compressed modem in the example with the boot log file of the compressed modem, the whole process of loading and verifying the related files of the modem can save 2s of time in the process of compressing and decompressing the modem, so that the time consumption of starting can be effectively reduced.
In addition, this embodiment further provides a boot device based on an embedded device, which is configured to implement the boot method based on an embedded device as described above, as shown in fig. 6, where the boot device based on an embedded device includes: the power-on module is used for powering on the embedded equipment, and the embedded equipment stores compressed files; the compression module is used for compressing the large file to obtain a compressed file; the decompression module comprises a preliminary decompression unit and a complete decompression unit; the initial decompression unit is used for initially decompressing the compressed file in the starting stage to obtain the size and offset address of the compressed file; the complete decompression unit is used for decompressing the compressed file according to the size and offset address of the compressed file obtained in the starting stage in the kernel stage to obtain file data; and the starting module is used for starting and running the file data.
In the practical application process, the power-on module, the compression module, the decompression module and the starting module are in communication connection according to the interaction relation of the data signals, and through the description of the above embodiments, a person skilled in the art can clearly understand that, for convenience and brevity of description, only the division of the above functional modules is used for illustration, in the practical application, the above functional allocation can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. The specific working processes of the above-described systems, devices and units may refer to the corresponding processes in the foregoing method embodiments, which are not described herein.
The embodiment also provides an electronic device, including a memory, a processor, and an executable program stored on the memory and capable of being executed by the processor; the processor, when running the executable program, performs the embedded device-based boot method as described above.
And, the present embodiment also provides a computer storage medium storing an executable program; when the executable program is executed, the startup method based on the embedded device is realized.
Of course, the present embodiment also provides a method comprising a computer program product for causing the electronic device to carry out the possible design of any one of the above-mentioned method embodiments when said computer program product is run on a terminal.
The embodiment of the application further provides a chip, and the chip is coupled to the memory and is used for executing the computer program stored in the memory, so that the electronic device executes the method possibly designed by any one of the above method embodiments.
In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the difference from other embodiments, so that the same similar parts of each embodiment are referred to each other.
The method and device for starting up based on embedded equipment, electronic equipment and computer storage medium provided by the embodiment comprise the following steps: powering on the embedded equipment, wherein the embedded equipment stores compressed files; in the starting stage, the compressed file is initially decompressed to obtain the size and offset address of the compressed file; at the kernel stage, decompressing the compressed file according to the size and offset address of the compressed file obtained at the starting stage to obtain file data; and starting and running file data. By initially decompressing the compressed file in the startup phase and decompressing the compressed file in the kernel phase, the time consumption for loading the compressed file into the random access memory after the file is compressed can be reduced, and meanwhile, the storage space of the read-only memory can be saved when the compressed file is stored in the kernel phase due to the fact that the compressed file is decompressed in the startup phase and the kernel phase respectively, and then the startup time of the compressed file after decompression can be saved, so that the startup time is optimized, and the problem that the startup time of the existing embedded device adopting the split storage scheme is too long is solved.
The above description is only illustrative of the preferred embodiments of the present invention and is not intended to limit the scope of the present invention, and any alterations and modifications made by those skilled in the art based on the above disclosure shall fall within the scope of the appended claims.
Claims (13)
1. A method for booting a device based on an embedded device, comprising:
powering on the embedded equipment, wherein the embedded equipment stores compressed files;
in the starting stage, the compressed file is initially decompressed to obtain the size and offset address of the compressed file;
at the kernel stage, decompressing the compressed file according to the size and offset address of the compressed file obtained at the starting stage to obtain file data;
and starting and running file data.
2. The method for booting a device based on an embedded device of claim 1, wherein the method for obtaining the compressed file includes:
acquiring a large file;
compressing the large file by using a file compression tool to obtain a compression package;
the compressed package is signed to obtain a compressed file.
3. The method for booting a device based on an embedded device of claim 1 wherein the method for initially decompressing the compressed file to obtain the size and offset address of the compressed file includes:
acquiring the approximate position of a data structure body for decoupling shared memory information in a compressed file;
the data structure at the approximate location of the compressed file is decompressed to obtain the size and offset address of the compressed file.
4. A method of booting a device based on an embedded device of claim 3 wherein the method of decompressing a data structure at an approximate location of a compressed file to obtain a size and offset address of the compressed file comprises:
initializing the bottom hardware device and stack, and starting loading mode;
judging the starting-up mode to enter a corresponding starting-up mode;
the compressed file is loaded and the data structure at the approximate location of the compressed file is decompressed to obtain the size and offset address of the compressed file.
5. The embedded device-based boot method of claim 4, wherein decompressing the data structure at the approximate location of the compressed file to obtain the size and offset address of the compressed file comprises:
acquiring the size of a data structure body and positioning the data structure body at the approximate position of a compressed file;
decompressing the compressed file with the data size matched with the size of the data structure body at the approximate position of the compressed file to obtain decompressed data;
if the size of the decompressed data exceeds the size of the data structure, intercepting the data matched with the size of the data structure from the decompressed data, and assigning the intercepted data to the data structure to obtain the decompressed data structure;
the size and offset address of the compressed file are read from the decompressed data structure.
6. The method for booting a device based on an embedded device of claim 1 wherein the method for decompressing the compressed file to obtain the file data in the kernel stage according to the size and offset address of the compressed file obtained in the boot stage includes:
loading a compressed file;
verifying the signature of the compressed file;
and if the verification is passed, decompressing the compressed file to obtain file data.
7. The method for booting a device based on an embedded device of claim 6 wherein the method for decompressing the compressed file to obtain the file data in the kernel phase according to the size and offset address of the compressed file obtained in the boot phase further comprises:
judging whether the loaded file is a compressed file or not;
if the compressed file is judged, decompressing the compressed file;
if the non-compressed file is judged, the normal loading flow is executed for the non-compressed file.
8. The method for booting a device based on an embedded device of claim 7 wherein the method for determining whether the loaded file is a compressed file includes:
when loading a file, first three bytes of the file are loaded;
judging whether the first three bytes are 1F, 8B and 08 respectively;
if the first three bytes are 1F, 8B and 08 respectively, the file is judged to be a compressed file, otherwise, the file is not a compressed file.
9. The embedded device-based boot method of claim 6, wherein the method of verifying the signature of the compressed file comprises:
storing the loaded compressed file in an idle memory in a continuous address mode;
and verifying the compressed file by using a security authentication tool.
10. The embedded device-based boot method of claim 6, wherein the method of decompressing the compressed file comprises:
according to the use condition of the compressed file, the compressed file is decompressed partially or completely by using a file decompression tool, wherein the method for decompressing by using the file decompression tool comprises the following steps:
setting a CHUNK value and opening a compressed file;
reading data in [ CHUNK ] from the compressed file;
decompressing in [ CHUNK ] to obtain decompressed file data;
judging whether the size of the file data is smaller than a CHUNK value or not;
if the size of the file data is not smaller than the CHUNK value, writing the file data into out [ CHUNK ];
and judging whether the readable size of the compressed file is smaller than 0, if so, closing the compressed file, otherwise, reading the data in [ CHUNK ] from the compressed file again.
11. An embedded device-based boot device for implementing the embedded device-based boot method according to any one of claims 1 to 10, comprising:
the power-on module is used for powering on the embedded equipment, and the embedded equipment stores compressed files;
the compression module is used for compressing the large file to obtain a compressed file;
the decompression module comprises a preliminary decompression unit and a complete decompression unit; the initial decompression unit is used for initially decompressing the compressed file in the starting stage to obtain the size and offset address of the compressed file; the complete decompression unit is used for decompressing the compressed file according to the size and offset address of the compressed file obtained in the starting stage in the kernel stage to obtain file data;
and the starting module is used for starting and running the file data.
12. An electronic device comprising a memory, a processor, and an executable program stored on the memory and executable by the processor; the processor, when executing the executable program, performs the embedded device-based boot method of any one of claims 1 to 10.
13. A computer storage medium, wherein the computer storage medium stores an executable program; the executable program, when executed, implements the embedded device-based boot method of any one of claims 1-10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311526703.3A CN117472455A (en) | 2023-11-15 | 2023-11-15 | Startup method and device based on embedded equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311526703.3A CN117472455A (en) | 2023-11-15 | 2023-11-15 | Startup method and device based on embedded equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117472455A true CN117472455A (en) | 2024-01-30 |
Family
ID=89637800
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311526703.3A Pending CN117472455A (en) | 2023-11-15 | 2023-11-15 | Startup method and device based on embedded equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117472455A (en) |
-
2023
- 2023-11-15 CN CN202311526703.3A patent/CN117472455A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8732446B2 (en) | Selectively compressing blocks of a bootable snapshot image during booting | |
| US7610479B2 (en) | Computing device method that presents as a single file system operating system components in both executable and non-executable memory | |
| US8719810B2 (en) | Program upgrade system and method for over the air-capable mobile terminal | |
| US20100235617A1 (en) | System recovery method and embedded system with automatic recovery function | |
| EP2555110A1 (en) | Smart mobile phone system and boot method thereof | |
| CN115098190A (en) | Method, device, terminal and storage medium for improving starting speed of SSD (solid State disk) system | |
| US20110246759A1 (en) | Method for boosting an electronic device with multiple processing units, and electronic device for implementing the same | |
| US7900197B2 (en) | Program initiation methods and embedded systems utilizing the same | |
| US20070283130A1 (en) | Compact Storage Of Program Code On Mobile Terminals | |
| US8423730B2 (en) | Method and apparatus for supporting diverse memory access schemes | |
| US20150089486A1 (en) | Method of Firmware Upgrade | |
| CN117472455A (en) | Startup method and device based on embedded equipment | |
| CN113396391A (en) | Method and device for starting application program, electronic equipment and storage medium | |
| CN111694600B (en) | Mirror image file design, chip operation method, system, device and medium | |
| EP1710697A1 (en) | Method and apparatus for executing application in system having NAND flash memory | |
| KR20070108646A (en) | Method and terminal for managing of compression binary file | |
| KR100626517B1 (en) | Method for downloading for a operating system program in a mobile communication terminal | |
| US20070288661A1 (en) | Method and media for reducing executable storage requirements in wireless environment | |
| CN101482825A (en) | Self-starting module and its implementing method, single board and its self-starting method | |
| CN111176689A (en) | Information processing method and electronic device | |
| KR100636518B1 (en) | Method for upgrade of firmware in mobile telecommunication terminal | |
| RU2390823C2 (en) | Compact storage of program code on mobile terminals | |
| EP1672487A1 (en) | Method and means for an efficient memory usage | |
| CN110018852B (en) | System secondary boot method, device and storage medium | |
| CN110928582B (en) | Information processing apparatus and method of configuring target device of information processing apparatus |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |