A multi-core architecture software and hardware cooperative fast booting method
By parallel processing of loading descriptors and hardware modules under a multi-core architecture, the problem of low firmware loading and decompression efficiency in multi-core architecture is solved, achieving fast boot and efficient resource utilization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- EEASY TECH CO LTD
- Filing Date
- 2022-09-13
- Publication Date
- 2026-06-26
AI Technical Summary
In existing technologies, the firmware optimization effect of auxiliary cores/hardware decompression modules in multi-core architectures is not good, especially when multiple compressed firmwares are loaded and decompressed, resulting in prolonged startup time and insufficient resource utilization.
It adopts a multi-core architecture, where the CPU generates the load descriptor and the auxiliary core controls the loading hardware module and hardware decompression module to execute the loading and decompression programs of the compressed firmware in parallel. The loading and decompression are completed directly through the hardware module, freeing up CPU and auxiliary core resources.
It greatly speeds up boot time, improves resource utilization, reduces the complexity of auxiliary core software design, and optimizes firmware loading and decompression processes.
Smart Images
Figure CN115640055B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of firmware boot optimization technology, and in particular to a method for fast booting through hardware and software collaboration in a multi-core architecture. Background Technology
[0002] Boot speed is a critical and unavoidable issue in embedded system development and optimization, with firmware loading speed being the bottleneck for optimization. A common approach is to compress the firmware and store it on a medium, then load and decompress the compressed firmware before runtime. Currently, there are roughly two optimization methods for the loading and decompression of compressed firmware:
[0003] The first approach involves adding a secondary core / hardware decompression module to the SOC system. The CPU loads the compressed firmware, and then instructs the secondary core / hardware decompression module to decompress it. Once decompression is complete, a completion command is sent to the CPU, indicating that the compressed firmware has been decompressed. The CPU can then run the decompressed firmware or continue loading the next compressed firmware, repeating the CPU loading task and the secondary core / hardware decompression module decompression task in parallel. For example, the fast boot method and system disclosed in CN113885949A uses this first optimization method.
[0004] While the first optimization method can achieve parallel loading and decompression of compressed firmware and speed up the startup speed to some extent, it requires waiting for all compressed firmware to be loaded and decompressed before the firmware can run, which delays the running time. Furthermore, the parallel loading and decompression by the CPU and auxiliary core / hardware decompression module cannot completely free up CPU resources, since there is still the CPU operation of loading compressed firmware.
[0005] The second method involves adding a secondary core to the SOC system. This secondary core handles the loading and decompression of the compressed firmware. Once decompression is complete, a completion command is sent to the CPU, indicating that the compressed firmware has been decompressed and the CPU can then run the decompressed firmware.
[0006] The second optimization method requires the auxiliary core to implement the functions of loading and decompressing compressed firmware. On the one hand, this increases the complexity of the auxiliary core software design, and on the other hand, the performance of the auxiliary core is generally not high. Adding these functions may backfire due to the large amount of auxiliary core resources being occupied. Furthermore, it does not take advantage of the parallelism of loading and decompression, so this optimization method may not achieve the desired optimization effect. Summary of the Invention
[0007] To address the aforementioned issues, this invention proposes a multi-core architecture hardware and software collaborative fast boot method, which mainly solves the problem of poor firmware optimization results achieved by using auxiliary cores / hardware decompression modules in existing technologies.
[0008] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:
[0009] A multi-core architecture hardware and software collaborative fast boot method includes the following steps: The CPU generates corresponding load descriptors based on preset rules for the storage address and loading address of compressed firmware. Each load descriptor is bound to a unique compressed firmware, and the corresponding storage address and loading address. A secondary core determines whether all load descriptors are ready; if so, it sends the first load descriptor to the loading hardware module. The loading hardware module starts a loading program for the compressed firmware corresponding to the load descriptor. After the compressed firmware is loaded, a decompression descriptor is generated, bound to a unique compressed firmware and the corresponding decompression address. The decompression descriptor is then sent to a hardware decompression module. The hardware decompression module starts a decompression program for the compressed firmware corresponding to the decompression descriptor, generating decompressed firmware. The secondary core determines whether the decompressed firmware is successfully generated; if so, the CPU starts a running program for the decompressed firmware. During the execution of the running program, the loading program and the decompression program are run in parallel for the next compressed firmware corresponding to the load descriptor.
[0010] In some implementations, the hardware decompression module returns to the loading hardware module without any feedback instruction.
[0011] In some implementations, each of the compressed firmware is divided into at least two associated compressed firmware frames according to a preset unit size, and each compressed firmware frame is bound to a unique load descriptor C. N D n Wherein, the loading descriptor C N D n Represents the nth compressed firmware frame of the Nth compressed firmware, where N≥1 and n≥1.
[0012] In some implementations, after the load descriptor is delivered to the loading hardware module, the loading hardware module loads the compressed firmware frame into the loading address according to the storage address bound to the load descriptor, thereby completing the loading process.
[0013] In some implementations, after the decompression descriptor is sent to the hardware decompression module, the hardware decompression module extracts the compressed firmware frame from the load address and starts the decompression program, and the generated decompressed firmware frame is stored in the decompression address.
[0014] In some implementations, the auxiliary core determines whether all the decompressed firmware frames associated with the current decompressed firmware have been successfully decompressed. If so, the CPU jumps to the decompression address corresponding to the first decompressed firmware frame and starts the running program.
[0015] In some implementations, the auxiliary core determines whether all the decompressed firmware frames associated with the current decompressed firmware have been successfully decompressed. If not, the auxiliary core sends a first trigger command to the loading hardware module. The first trigger command is used to trigger the loading hardware module to start the loading program for the next compressed firmware frame associated with the current compressed firmware.
[0016] In some implementations, if all decompressed firmware frames associated with the current decompressed firmware are successfully decompressed, the process further includes the auxiliary core determining whether all decompressed firmware frames have been successfully decompressed; if so, the auxiliary core terminates all currently running processes.
[0017] In some implementations, if all decompressed firmware frames associated with the current decompressed firmware are successfully decompressed, the process further includes the auxiliary core determining whether all decompressed firmware frames have been successfully decompressed. If not, the auxiliary core sends a second trigger command to the loading hardware module, the second trigger command being used to trigger the loading hardware module to start the loading program for the next compressed firmware.
[0018] The beneficial effects of this invention are as follows: the CPU generates a corresponding loading descriptor based on the compressed firmware, the auxiliary core controls the loading hardware module and the hardware decompression module to start the loading and decompression programs for the bound compressed firmware based on the loading descriptor, and finally the CPU starts the running program for the decompressed firmware. That is, the running program runs in parallel with the loading and decompression programs. The loading and decompression of the compressed firmware are completed directly by the hardware module, which releases the resources of the CPU and the auxiliary core and greatly speeds up the boot time. Attached Figure Description
[0019] Figure 1 This is a flowchart of the multi-core architecture hardware and software collaborative fast boot method disclosed in Embodiment 1 or 2 of the present invention;
[0020] Figure 2 This is a flowchart of the multi-core architecture hardware and software collaborative fast boot method disclosed in Embodiment 2 of the present invention;
[0021] Figure 3 This is a flowchart illustrating the parallelization of the loading and decompression processes as disclosed in Embodiment 2 of the present invention. Detailed Implementation
[0022] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the content of this invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to this invention are shown in the accompanying drawings, not all of them.
[0023] Example 1
[0024] This invention discloses a method for fast boot-up using a multi-core architecture with coordinated hardware and software, such as... Figure 1 As shown, it includes the following steps:
[0025] S1, the CPU generates corresponding load descriptors according to the preset rules of the storage address and load address of the compressed firmware; each load descriptor is bound to a unique compressed firmware, as well as the storage address and load address of the compressed firmware.
[0026] S2, the auxiliary core determines whether all load descriptors are ready. If so, the first load descriptor is sent to the load hardware module.
[0027] S3, the hardware module starts the loading program for the compressed firmware corresponding to the loading descriptor. After the compressed firmware is loaded, a decompression descriptor is generated. The decompression descriptor is bound to a unique compressed firmware and the decompression address corresponding to the compressed firmware. The decompression descriptor is then sent to the hardware decompression module.
[0028] S4, the hardware decompression module starts the decompression program for the compressed firmware corresponding to the decompression descriptor and generates decompressed firmware;
[0029] S5, the auxiliary core determines whether the decompressed firmware has been successfully generated. If so, the CPU starts the program to run the decompressed firmware.
[0030] S6, during the execution of the program, runs the loader and decompression program in parallel for the compressed firmware corresponding to the next load descriptor.
[0031] In this embodiment, the CPU generates a corresponding load descriptor based on the compressed firmware. The auxiliary core controls the loading hardware module and hardware decompression module to start the loading and decompression programs for the bound compressed firmware based on the load descriptor. Finally, the CPU starts the running program for the decompressed firmware. That is, the running program runs in parallel with the loading and decompression programs. The loading and decompression of the compressed firmware are completed directly by the hardware module, which releases the resources of the CPU and auxiliary core and greatly speeds up the boot time.
[0032] It should be noted that the initial startup of the aforementioned compressed firmware has a certain order, such as using a compressed firmware sequence table. Therefore, the load descriptor and decompression descriptor in this example should also have a certain order and be uniquely identified. Furthermore, the aforementioned "delivery" action and communication instructions to notify the CPU to start the running program are preferably issued by the auxiliary core to reduce the computational burden on the loading hardware module and the hardware decompression module.
[0033] Example 2
[0034] Based on Embodiment 1, this invention provides yet another method for rapid boot-up using a multi-core architecture with coordinated hardware and software, such as... Figure 1 and 2 As shown, it includes the following steps:
[0035] S1, the CPU generates corresponding load descriptors according to the preset rules of the storage address and load address of the compressed firmware; each load descriptor is bound to a unique compressed firmware, as well as the storage address and load address of the compressed firmware.
[0036] In step S1, the storage address refers to the storage location of the compressed firmware on the storage medium, and the load address refers to the storage location where the compressed firmware is transferred to memory. In this step, the generation of all load descriptors for the compressed firmware is completed on the CPU. The time spent generating the load descriptor is much less than the time spent loading and decompressing the compressed firmware on the CPU, thus improving efficiency.
[0037] The preset rules mentioned above can be either regular incrementing or decrementing rules, or other mapping rules.
[0038] Furthermore, in step S1, each compressed firmware is divided into at least two associated compressed firmware frames according to a preset unit size, and each compressed firmware frame is bound to a unique load descriptor C. N D n Among them, loading descriptor C N D n Represents the nth compressed firmware frame of the Nth compressed firmware, where N≥1 and n≥1.
[0039] In one example, taking a fast-boot system using Linux (CPU-ARM) + RTOS (secondary core-MCU) as an example, the system needs to run three compressed firmwares: linux / ramfs / ax, which occupy space in AMB, BMB, and CMB respectively. The default unit size is 4KB, so the Linux firmware is divided into X parts, with its load descriptors numbered C1D1, C1D2...C1D... XThere are a total of X load descriptors. The number of segments and generation method for the three compressed firmwares ramfs / ax are the same as those for Linux firmware. Therefore, each load descriptor C N D n Each is bound to a storage address, a load address, and a set of 4KB compressed firmware frames.
[0040] S2, the auxiliary core determines whether all load descriptors are ready. If so, the first load descriptor is sent to the load hardware module.
[0041] In step S2, when the load descriptors C1D1-C3D of the three firmware files linux / ramfs / ax are loaded... n Once all processes are completed and successfully received by the secondary core, it proves that the CPU has finished its preparations and the secondary core can control the loading of the program.
[0042] S3, the hardware module starts the loading program for the compressed firmware corresponding to the loading descriptor. After the compressed firmware is loaded, a decompression descriptor is generated. The decompression descriptor is bound to a unique compressed firmware and the decompression address corresponding to the compressed firmware. The decompression descriptor is then sent to the hardware decompression module.
[0043] In step S3, after the load descriptor is delivered to the loading hardware module, the loading hardware module copies the compressed firmware frame to the loading address according to the storage address bound to the load descriptor, thus completing the loading process.
[0044] S4, the hardware decompression module starts the decompression program for the compressed firmware corresponding to the decompression descriptor and generates decompressed firmware;
[0045] In step S4, after the decompression descriptor is sent to the hardware decompression module, the hardware decompression module extracts the compressed firmware frame from the load address and starts the decompression program. The generated decompressed firmware frame is stored in the decompression address.
[0046] In step S4, the parallelism between the loading and decompression programs can take various forms. In one optional example, the hardware decompression module returns to the loading hardware module without feedback instructions. Therefore, the loading hardware module does not need to wait for the hardware decompression module to complete the decompression of the previous compressed firmware frame before loading the next compressed firmware frame. In other words, the loading of the loading hardware module is not affected by the hardware decompression module, thereby realizing the parallelization of compressed firmware frame loading / decompression, achieving simultaneous loading and decompression, improving resource utilization, and saving overall time compared to serial loading and decompression.
[0047] S5, the auxiliary core determines whether the decompressed firmware has been successfully generated. If so, the CPU starts the program to run the decompressed firmware.
[0048] In step S5, the standard for "the auxiliary core to determine whether the decompressed firmware has been successfully generated" is: the auxiliary core determines whether all decompressed firmware frames associated with the current decompressed firmware have been successfully decompressed. If so, the CPU jumps to the decompression address corresponding to the decompressed firmware frame and starts the running program. If not, the auxiliary core sends a first trigger command to the loading hardware module. The first trigger command is used to trigger the loading hardware module to start the loading program for the next compressed firmware frame associated with the current compressed firmware.
[0049] For example, a Linux compressed firmware consists of X compressed firmware frames. If all X compressed firmware frames are decompressed, generating the corresponding number of decompressed firmware frames, then the CPU jumps to the decompression address corresponding to the decompressed firmware frame, which is the address of the decompressed Linux program. The CPU then runs the Linux program, i.e., the CPU runs firmware C1. Conversely, if not all decompressed firmware frames are obtained, the firmware is incomplete and cannot run. For example, if the Linux compressed firmware program has completed X-1 (i.e., D...) decompression... X-1 The decompression of the Xth (i.e., D) compressed firmware frame is incomplete, but the last decompressed firmware frame is still missing. Therefore, the auxiliary core sends a first trigger command to the loading hardware module to initiate the decompression of the Xth (i.e., D) frame. X Loading and decompressing 10 compressed firmware frames, i.e., loading descriptor C1D X The data is sent to the loading hardware module, which then re-runs the loading program and returns to step S3. With the aim of loading and decompressing the Xth compressed firmware frame, the loading and decompression programs of S3-S5 are re-run.
[0050] S6, during the execution of the program, runs the loader and decompression program in parallel for the compressed firmware corresponding to the next load descriptor.
[0051] In step S6, the execution of firmware N is parallel to the loading and decompression of firmware N+1. There is an explicit calling rule between the firmwares: firmware N-1 will run when it runs, and firmware N will run when it runs; therefore, firmware N-1 can run on the CPU without waiting for firmware N / N+1 to finish loading / decompressing. This speeds up the start-up time of firmware N-1 and fully utilizes the downtime of firmware N-1's execution to trigger the loading and decompression of firmware N / N+1 using a secondary core.
[0052] In step S6, if all decompressed firmware frames associated with the current decompressed firmware are successfully decompressed, the auxiliary core further determines whether all decompressed firmware frames are successfully decompressed. If so, the auxiliary core terminates all currently running processes. If not, the auxiliary core sends a second trigger command to the loading hardware module. The second trigger command is used to trigger the loading hardware module to start the loading program for the next compressed firmware.
[0053] In step S6, still using Linux compressed firmware as an example, if all X compressed firmware frames of the Linux compressed firmware are decompressed, the CPU runs the Linux program (firmware C1). At the same time, the auxiliary core sends a second trigger command to the loading hardware module to start the loading and decompression of the second compressed firmware, namely the ramfs compressed firmware, and loads its descriptors C2D1-C2D. n The data is sent to the loading hardware module, which then re-runs the loading program, returning to step S3. With the goal of loading and decompressing the second compressed firmware, the loading and decompression programs S3-S5 are re-runned. Figure 3 .
[0054] The secondary core does not implement a complete set of code for loading / decompressing compressed firmware; it only needs to implement the interface for triggering the loading / decompression of compressed firmware based on the descriptor. This reduces the complexity of the secondary core's software design and its code space. Furthermore, by using hardware to implement the loading and decompression of compressed firmware, the secondary core's resources are freed up, allowing it to perform many other tasks.
[0055] The above embodiments are merely illustrative of the technical concept and features of the present invention, and are intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly. They should not be construed as limiting the scope of protection of the present invention. All equivalent changes or modifications made based on the essence of the content of the present invention should be covered within the scope of protection of the present invention.
Claims
1. A method for rapid boot-up using multi-core architecture hardware and software collaboration, characterized in that, Includes the following steps: The CPU generates corresponding load descriptors based on preset rules for the storage address and load address of the compressed firmware; each load descriptor is bound to a unique compressed firmware, as well as the storage address and load address corresponding to the compressed firmware. The auxiliary core determines whether all the load descriptors are ready. If so, the first load descriptor is sent to the loading hardware module. The loading hardware module starts a loading program for the compressed firmware corresponding to the loading descriptor. After the compressed firmware is loaded, a decompression descriptor is generated. The decompression descriptor is bound to a unique compressed firmware and the decompression address corresponding to the compressed firmware. The decompression descriptor is then sent to the hardware decompression module. The hardware decompression module starts the decompression program for the compressed firmware corresponding to the decompression descriptor and generates decompressed firmware; The auxiliary core determines whether the decompressed firmware has been successfully generated. If so, the CPU starts the running program for the decompressed firmware. During the execution of the running program, the loading program and the decompression program are run in parallel for the compressed firmware corresponding to the next loading descriptor.
2. The multi-core architecture hardware and software collaborative fast boot method as described in claim 1, characterized in that, The hardware decompression module returned to the loading hardware module without any feedback instruction.
3. The multi-core architecture hardware and software collaborative fast boot method as described in claim 1, characterized in that, Each of the compressed firmware units is divided into at least two associated compressed firmware frames according to a preset unit size, and each compressed firmware frame is bound to a unique load descriptor C. N D n Wherein, the loading descriptor C N D n Represents the nth compressed firmware frame of the Nth compressed firmware, where N≥1 and n≥1.
4. The multi-core architecture hardware and software collaborative fast boot method as described in claim 3, characterized in that, After the load descriptor is sent to the loading hardware module, the loading hardware module loads the compressed firmware frame into the loading address according to the storage address bound to the load descriptor, thus completing the loading process.
5. The multi-core architecture hardware and software collaborative fast boot method as described in claim 3, characterized in that, After the decompression descriptor is sent to the hardware decompression module, the hardware decompression module extracts the compressed firmware frame from the loading address and starts the decompression program, and the generated decompressed firmware frame is stored in the decompression address.
6. The multi-core architecture hardware and software collaborative fast boot method as described in claim 5, characterized in that, The auxiliary core determines whether all the decompressed firmware frames associated with the current decompressed firmware have been successfully decompressed. If so, the CPU jumps to the decompression address corresponding to the first decompressed firmware frame and starts the running program.
7. The multi-core architecture hardware and software collaborative fast boot method as described in claim 3, characterized in that, The auxiliary core determines whether all the decompressed firmware frames associated with the current decompressed firmware have been successfully decompressed. If not, the auxiliary core sends a first trigger command to the loading hardware module. The first trigger command is used to trigger the loading hardware module to start the loading program for the next compressed firmware frame associated with the current compressed firmware.
8. The multi-core architecture hardware and software collaborative fast boot method as described in claim 7, characterized in that, If all decompressed firmware frames associated with the current decompressed firmware are successfully decompressed, the process further includes the auxiliary core determining whether all decompressed firmware frames have been successfully decompressed. If so, the auxiliary core terminates all currently running processes.
9. The multi-core architecture hardware and software collaborative fast boot method as described in claim 7, characterized in that, If all decompressed firmware frames associated with the current decompressed firmware are successfully decompressed, the process further includes the auxiliary core determining whether all decompressed firmware frames have been successfully decompressed. If not, the auxiliary core sends a second trigger command to the loading hardware module. The second trigger command is used to trigger the loading hardware module to start the loading program for the next compressed firmware.