Link script self-moving decompression method and device of honnemo system

Abstract

This application discloses a method for self-moving and decompressing the linker script in the HarmonyOS system. The linker script file specifies the memory address to be loaded into a memory space with sufficient capacity and the highest operating efficiency for the segments to be moved; a global list is created based on the memory layout rules for each segment of each application in the linker script. A self-moving and self-decompressing program is implemented in the HarmonyOS system. When loading each segment of each application into the memory space of the embedded device, the HarmonyOS system first queries the pre-loaded global list for that segment. This application allows for more flexible and reasonable allocation of memory space for different segments of an application, which is beneficial for improving the operating efficiency of the application.

Description

Technical Field

[0001] This application relates to an embedded system, and more particularly to a method for self-relocation and decompression via a linker script in the HarmonyOS system. Background Technology

[0002] During embedded system development, the bootloader, kernel, file system, and applications are typically developed independently; the first three are all part of the operating system. After development, these components are integrated into a system image file, which is then burned into the embedded device's non-volatile memory—such as flash memory. When the embedded device powers on, the operating system code is loaded from non-volatile memory into memory during the boot phase. When an application needs to be run, the embedded system loads that application from non-volatile memory into memory or executes it in non-volatile memory using XIP (execute in place) mode.

[0003] Typically, embedded devices have multiple memory spaces for running application code, such as ITCM (instruction tightly-coupled memory), SRAM (static random-access memory), and PSRAM (pseudo-static random-access memory). The code execution efficiency is ITCM > SRAM > PSRAM, while the memory capacity is PSRAM > SRAM > ITCM. ITCM, in particular, has a very small space and can only hold a small amount of code.

[0004] Embedded system development utilizes a compiler, a linker, and a debugger. The linker is a program that links one or more object files, including libraries, generated by a compiler or assembler into a single executable file. Simply put, the linker merges one or more input files (object files) into a single output file (executable file). The linker typically uses a linker script. This script describes how to place the sections from the input files into the output file and controls the memory layout of these sections. Sometimes, the sections in the input files are called input sections, and the sections in the output files are called output sections.

[0005] A segment can be marked as loadable, meaning that its contents need to be loaded into memory before the output file is run. An empty segment is allocable, meaning that a region should be reserved in memory, but nothing needs to be loaded here (in some cases, this memory must be zeroed out). Segments that are neither loadable nor allocable typically contain some kind of debugging information.

[0006] Each loadable or allocable output segment has two addresses. The first is the VMA (Virtual Memory Area), and the second is the LMA (Load Memory Address). The virtual memory address is the link address. During program compilation, each object file is compiled from the source code, and finally, multiple object files are linked to generate an executable file. The link address indicates the location of each object file in the executable program. For example, an executable program (output file) a.out consists of three object files (input files) a1.0, a2.0, and a3.0; the order of these input files in the output file is determined by their link addresses. The load address indicates the address at which each segment of the executable file (application program) is loaded into memory for execution. In most cases, the link address and load address of each segment are the same, but they may also be different.

[0007] The standard process for launching applications in HarmonyOS involves a bootloader loading the application, either by reading it from non-volatile memory (NDRAM) into main memory or by running it in NDRAM using XIP (Extended Instruction Point) mode. The first instruction executed in an application is called the entry point. After loading an application, HarmonyOS enters its entry point. This execution method dictates that an application must run entirely within the same memory space. When an application has a large amount of code, it typically runs in a large but relatively inefficient memory space—such as PSRAM. This can lead to low code execution efficiency, especially for modules that require frequent calls or those that need to improve performance. Summary of the Invention

[0008] The technical problem this application aims to solve is how to enable the linker scripts of the HarmonyOS system to support self-relocation and decompression, so as to improve the running efficiency of applications in the HarmonyOS system.

[0009] To address the aforementioned technical problems, this application proposes a method for self-moving and decompressing the linker script of the HarmonyOS system, comprising the following steps: Step S1: When generating the system image file of the embedded device, data compression is performed on at least some segments of some applications to reduce their size. Step S2: The "segments of applications that need improved running efficiency" are referred to as the segments that need to be moved. In the linker script file, the memory address to be loaded for the segments that need to be moved is specified as a memory space with sufficient capacity and the highest running efficiency. A global list is created according to the memory layout rules of each segment of each application in the linker script. The global list stores the source address, destination address, source data size, and destination data size of the segments that need to be moved recorded in the linker script, and also stores the segments that need to be zeroed recorded in the linker script. The destination data size of the segments that need to be zeroed is 0. Step S3: A self-moving and self-decompressing program is implemented in the HarmonyOS system. Step S4: When loading each segment of each application into the memory space of the embedded device, the HarmonyOS system first queries the global list pre-loaded into memory for that segment. If the destination data size of the segment recorded in the global list is 0, the segment data is cleared to zero. If the source data size of the segment recorded in the global list is the same as the destination data size, the segment is copied from its source address in the global list to its destination address. If the source data size of the segment recorded in the global list is different from the destination data size, the segment data is first read from its source address in the global list, then the self-moving and self-decompressing program is called to decompress the read segment data, and finally the decompressed segment data is written to its destination address in the global list.

[0010] Furthermore, in step S1, the segment includes any one or more of the following: code segment, data segment, BSS segment, and read-only data segment.

[0011] Furthermore, in step S2, the embedded device has multiple memory spaces for running applications. The memory spaces are ordered from highest to lowest code execution efficiency as follows: Instruction Tightly Coupled Memory (ITCM) > Static Random Access Memory (SRAM) > Pseudo-Static Random Access Memory (PSRAM); and from largest to smallest memory space capacity as follows: PSRAM > SRAM > ITCM.

[0012] Furthermore, in step S2, the linker script specifies a virtual memory address (VMA) for each segment and also specifies a load memory address (LMA) for a segment using the AT keyword; if the linker script does not specify an LMA for a segment using the AT keyword, the linker defaults to the LMA being equivalent to the VMA for that segment.

[0013] Furthermore, in step S2, the segment that needs to be moved refers to the segment in the linker script where the LMA and VMA are inconsistent, as specified by the AT keyword.

[0014] Furthermore, in step S2, the segment that needs to be zeroed refers to a segment that will be zeroed when loaded into memory or a segment that is not loaded into memory.

[0015] Furthermore, in step S3, the self-moving and self-decompressing program is placed at the very beginning of the HarmonyOS system's startup position and cannot be moved or decompressed. It is used to perform self-moving and self-decompressing processing on the segments that need to be moved.

[0016] Further, in step S4, if the destination data size of the segment recorded in the global list is 0, it indicates that the segment needs to be zeroed out. If the source data size of the segment recorded in the global list is the same as the destination data size, it indicates that the segment needs to be moved and that the segment data has not been compressed. If the source data size of the segment recorded in the global list is different from the destination data size, it indicates that the segment needs to be moved and that the segment data has been compressed.

[0017] This application also proposes a device for self-moving and decompressing the linker script of the HarmonyOS system, including a compression unit, a setting and creation unit, an implementation unit, and a querying and processing unit. The compression unit is used to compress data from at least some segments of some applications when generating the system image file of the embedded device. The setting and creation unit is used to define "segments of applications that need improved operating efficiency" as segments to be moved, and to specify the loading memory address of the segments to be moved in the linker script file as a memory space with sufficient capacity and the highest operating efficiency; it creates a global list according to the memory layout rules of each segment of each application in the linker script; the global list stores the source address, destination address, source data size, and destination data size of the segments to be moved recorded in the linker script, and also stores the segments to be zeroed recorded in the linker script; the destination data size of the segments to be zeroed is 0. The implementation unit is used to implement a self-moving and self-decompressing program in the HarmonyOS system. The query and processing unit is used to, when loading each segment of each application into the memory of the embedded device, first query the global list pre-loaded into memory for that segment; if the destination data size of the segment recorded in the global list is 0, clear the segment data to zero; if the source data size of the segment recorded in the global list is the same as the destination data size, copy the segment from the source address of the segment recorded in the global list to the destination address of the segment; if the source data size of the segment recorded in the global list is different from the destination data size, first read the segment data from the source address of the segment recorded in the global list, then call the self-moving and self-decompressing program to decompress the read segment data, and then write the decompressed segment data to the destination address of the segment recorded in the global list.

[0018] The technical effects achieved by this application are: the self-moving and self-decompression of certain segments are implemented in the HarmonyOS system, which can more flexibly allocate the memory space loaded by different segments of the application, which is conducive to improving the running efficiency of the application. The self-decompression process improves the efficiency of self-moving and saves storage space. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the method for self-moving and decompressing the linker scripts of the HarmonyOS system proposed in this application.

[0020] Figure 2 This is a schematic diagram of the structure of the device for self-moving and decompressing the linker script of the HarmonyOS system proposed in this application.

[0021] The attached figures are labeled as follows: Compression Unit 1, Setting and Creation Unit 2, Implementation Unit 3, Query and Processing Unit 4. Detailed Implementation

[0022] Please see Figure 1 The method for self-moving and decompressing the linker scripts of the HarmonyOS system proposed in this application includes the following steps.

[0023] Step S1: When generating the system image file of the embedded device, data compression is performed on at least some segments of the application to reduce the size. The types of segments include, for example, code segments (text), data segments (data), BSS (block-started by symbol) segments, read-only data segments (rodata), etc., with code segments and data segments preferably being compressed. If certain segments are compressed, the amount of data read and written to those segments is reduced, while simultaneously saving space occupied in the non-volatile memory of the embedded device.

[0024] Step S2: The segments of the application whose performance needs improvement are designated as the segments to be moved. In the linker script file, the memory addresses for these segments are specified as memory spaces with higher performance efficiency. A global list is created based on the memory layout rules for each segment of each application in the linker script. This global list stores the source address, destination address, source data (original data before moving), and destination data (data after moving) of the segments to be moved, as well as the segments to be zeroed, as recorded in the linker script.

[0025] The linker script specifies a virtual memory address (VMA) for each segment, and optionally a load memory address (LMA) via the AT keyword. If the linker script does not specify an LMA for a segment via the AT keyword, the linker assumes that the LMA for that segment is equivalent to the VMA. If the linker script specifies an LMA for a segment via the AT keyword, the LMA can be different from the VMA.

[0026] The segments that need to be moved refer to those in the linker script where the LMA and VMA specified by the AT keyword are inconsistent. For example, if the linker script specifies that the VMA of a code segment is in PSRAM, and the segment does not use the AT keyword, then the LMA of that segment is equal to the VMA, and no self-moval operation is needed for that code segment. As another example, if the linker script specifies that the VMA of a code segment is in PSRAM, but in order to improve the running efficiency of that code segment and prepare to load it into the ITCM for execution, then the segment uses the AT keyword to specify the LMA in the ITCM. In this case, a self-moval operation is needed for that code segment, where a self-moval and self-decompression program copies the code segment from FLASH or PSRAM to the ITCM.

[0027] The segments that need to be zeroed out refer to segments that are zeroed out when loaded into memory or segments that are not loaded into memory at all. For example, the BSS segment stores uninitialized or initialized global or static variables; the BSS segment data is zeroed out when loaded. Similarly, if the linker script records a segment's type as NOLOAD (not loaded), that segment is not loaded into memory during application runtime. Therefore, BSS segments and NOLOAD segments are the segments that need to be zeroed out. The target data size of the "segments that need to be zeroed out" is 0.

[0028] Step S3: Implement a self-moving and self-decompressing program in the HarmonyOS system. The self-moving and self-decompressing program is placed at the very beginning of the HarmonyOS system's startup location and cannot be moved or decompressed. It is used to perform self-moving and self-decompressing processing on the "segments that need to be moved".

[0029] Step S4: When HarmonyOS loads each segment of each application into the memory space of the embedded device, it first queries the global list that has been pre-loaded into memory for that segment.

[0030] If the destination data size of the segment recorded in the global list is 0, it indicates that the segment needs to be cleared, and the data of the segment should be cleared.

[0031] If the source data size of the segment recorded in the global list is the same as the destination data size, it indicates that the segment needs to be moved and the segment data has not been compressed. Copy the segment from the source address of the segment recorded in the global list to the destination address of the segment.

[0032] If the source data size of the segment recorded in the global list differs from the destination data size, it indicates that the segment needs to be moved and that the segment data is compressed. First, the segment data is read from the source address recorded in the global list. Then, the self-moving and self-decompressing program is called to decompress the read segment data. Finally, the decompressed segment data is written to the destination address recorded in the global list. This process is the self-moving and self-decompressing described in this application.

[0033] The native linker script of HarmonyOS does not support self-movement and self-decompression. This application implements a self-movement and self-decompression program within HarmonyOS, which can flexibly run different segments of an application in different memory spaces. Suppose an application originally runs on PSRAM. Some code within this application (such as system scheduling, algorithms, and certain UI processing) needs to be processed quickly and is frequently called. If this code runs too slowly, it will affect system efficiency, so it is desirable for this part of the code to run at high speed. Since this code occupies relatively little space, one or more code segments or data segments can be run in the high-efficiency ITCM space. On one hand, this application sets the LMA of the application's "segments requiring improved running efficiency" to the ITCM space using the AT keyword in the linker script, enabling it to be loaded and run from the ITCM. On the other hand, this application uses the self-movement and self-decompression program implemented in HarmonyOS to self-move and self-decompress the application's "segments requiring improved running efficiency" before running the application. The self-relocation has two forms: one is running in XIP mode, which involves moving the code from non-volatile memory (e.g., FLASH) to ITCM; the other is running by loading it into PSRAM memory space, in which the HarmonyOS system first copies the code from FLASH to PSRAM, and then moves it from PSRAM to ITCM through the self-relocation and self-decompression program.

[0034] Compared to the native HarmonyOS system, which requires an application to run in the same memory space or non-volatile memory, this application addresses the issue of code efficiency. When certain code modules require rapid processing and are frequently called, such as an algorithm, if the original code design is inefficient, it may require significant manpower to optimize the algorithm or replace it with another solution, potentially increasing the code size and still not meeting the requirements. This application, however, does not require deep optimization of the original code or changes to the original framework design. By using the AT keyword in the linker script in conjunction with the self-moving and self-decompressing program added to HarmonyOS, code modules requiring rapid execution are moved to a more efficient address space (such as ITCM) before the application runs. This significantly improves code efficiency, meets practical requirements, and avoids changing the original code structure, increasing code size, or requiring additional manpower for optimization—making it simple and convenient.

[0035] Please see Figure 2 The device for self-moving and decompressing the linker script of the HarmonyOS system proposed in this application includes a compression unit 1, a setting and creation unit 2, an implementation unit 3, and a query and processing unit 4. Figure 2 The device shown corresponds to Figure 1 The method shown.

[0036] The compression unit 1 is used to compress data from at least a portion of a segment of an application program when generating a system image file for an embedded device.

[0037] The setting and creation unit 2 is used to designate "segments of applications that need improved operating efficiency" as segments that need to be moved, and to specify the memory address of the segments to be moved as a memory space with higher operating efficiency in the linker script file. A global list is created based on the memory layout rules for each segment of each application in the linker script. The global list stores the source address, destination address, source data size, and destination data size of the "segments that need to be moved" recorded in the linker script, and also stores the "segments that need to be zeroed" recorded in the linker script.

[0038] The implementation unit 3 is used to implement a self-moving and self-decompressing program in the HarmonyOS system.

[0039] The query and processing unit 4 is used to query the global list pre-loaded into memory for each segment of each application when loading each segment of the embedded device into the memory. If the destination data size of the segment recorded in the global list is 0, the segment data is cleared to zero. If the source data size of the segment recorded in the global list is the same as the destination data size, the segment is copied from the source address of the segment recorded in the global list to the destination address of the segment. If the source data size of the segment recorded in the global list is different from the destination data size, the segment data is first read from the source address of the segment recorded in the global list, then the self-moving and self-decompressing program is called to decompress the read segment data, and then the decompressed segment data is written to the destination address of the segment recorded in the global list. This process is the self-moving and self-decompressing described in this application.

[0040] In summary, this application can relocate code or data segments between different memory locations according to actual needs. For example, if certain code segments in an application are small in size but need to be executed repeatedly, a self-relocation operation can be used to move these segments from FLASH or PSRAM to ITCM before the application starts, which will greatly improve the execution efficiency of these segments. Simultaneously, the original code segments may be compressed; self-decompression is performed during the self-relocation process, reducing the amount of data moved and improving the efficiency of the self-relocation.

[0041] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for self-moving and decompressing linker scripts in the HarmonyOS system, characterized in that, Includes the following steps; Step S1: When generating the system image file of the embedded device, compress at least a portion of the application to reduce its size; Step S2: The "segments of the application that need improved performance" are referred to as the segments that need to be moved. In the linker script file, the memory address to be loaded for the segments that need to be moved is a memory space with sufficient capacity and the highest performance efficiency. A global list is created according to the memory layout rules of each segment of each application in the linker script. The global list stores the source address, destination address, source data size, and destination data size of the segments that need to be moved as recorded in the linker script. It also stores the segments that need to be zeroed as recorded in the linker script. The destination data size of the segments that need to be zeroed is 0. Step S3: Implement a self-moving and self-decompressing program in the HarmonyOS system; Step S4: When HarmonyOS loads each segment of each application into the memory space of the embedded device, it first queries the global list that has been pre-loaded into memory for that segment; If the destination data size of the segment recorded in the global list is 0, clear the data of that segment to zero; If the source data size of the segment recorded in the global list is the same as the destination data size, copy the segment from the source address of the segment recorded in the global list to the destination address of the segment; If the source data size of the segment recorded in the global list is different from the destination data size, the segment data is first read from the source address of the segment recorded in the global list, then the self-moving and self-decompressing program is called to decompress the read segment data, and then the decompressed segment data is written to the destination address of the segment recorded in the global list.

2. The method for self-moving and decompressing the linker script of the HarmonyOS system according to claim 1, characterized in that, In step S1, the segment includes any one or more of the following: code segment, data segment, BSS segment, and read-only data segment.

3. The method for self-moving and decompressing the linker scripts of the HarmonyOS system according to claim 1, characterized in that, In step S2, the embedded device has multiple memory spaces for running applications. The memory spaces are ordered from highest to lowest code execution efficiency as follows: Instruction Tightly Coupled Memory (ITCM) > Static Random Access Memory (SRAM) > Pseudo-Static Random Access Memory (PSRAM); and from largest to smallest memory space capacity as follows: PSRAM > SRAM > ITCM.

4. The method for self-moving and decompressing the linker script of the HarmonyOS system according to claim 1, characterized in that, In step S2, the linker script specifies a virtual memory address (VMA) for each segment and also specifies a load memory address (LMA) for a segment using the AT keyword. If the linker script does not specify an LMA for a segment using the AT keyword, the linker assumes that the LMA of that segment is equivalent to the VMA.

5. The method for self-moving and decompressing the linker script of the HarmonyOS system according to claim 4, characterized in that, In step S2, the segment that needs to be moved refers to the segment in the linker script where the LMA and VMA are inconsistent, as specified by the AT keyword.

6. The method for self-moving and decompressing the linker script of the HarmonyOS system according to claim 1, characterized in that, In step S2, the segment that needs to be zeroed refers to the segment that will be zeroed when loaded into memory or the segment that is not loaded into memory.

7. The method for self-moving and decompressing the linker script of the HarmonyOS system according to claim 1, characterized in that, In step S3, the self-moving and self-decompressing program is placed at the very beginning of the HarmonyOS system and cannot be moved or decompressed. It is used to perform self-moving and self-decompressing processing on the segments that need to be moved.

8. The method for self-moving and decompressing the linker script of the HarmonyOS system according to claim 1, characterized in that, In step S4, if the destination data size of the segment recorded in the global list is 0, it indicates that the segment needs to be cleared. If the source data size of the segment recorded in the global list is the same as the destination data size, it indicates that the segment needs to be moved and that the segment data has not been compressed. If the source data size of the segment recorded in the global list is different from the destination data size, it indicates that the segment needs to be moved and that the segment data has been compressed.

9. A device for self-moving and decompressing linker scripts in the HarmonyOS system, characterized in that, It includes a compression unit, a setup and creation unit, an implementation unit, and a query and processing unit; The compression unit is used to compress data from at least a portion of a segment of an application program when generating a system image file for an embedded device. The setting and creation unit is used to refer to "segments of applications that need improved operating efficiency" as segments that need to be moved. In the linker script file, it specifies the memory address to be loaded for the segments that need to be moved as a memory space with sufficient capacity and the highest operating efficiency. It creates a global list based on the memory layout rules for each segment of each application in the linker script. This global list stores the source address, destination address, source data size, and destination data size of the segments that need to be moved, as recorded in the linker script. It also stores segments that need to be zeroed out, with the destination data size of the segments that need to be zeroed out being 0. The implementation unit is used to implement a self-moving and self-decompressing program in the HarmonyOS system; The query and processing unit is used to, when loading each segment of each application into the memory of the embedded device, first query the global list pre-loaded into memory for that segment; if the destination data size of the segment recorded in the global list is 0, clear the segment data to zero; if the source data size of the segment recorded in the global list is the same as the destination data size, copy the segment from the source address of the segment recorded in the global list to the destination address of the segment; if the source data size of the segment recorded in the global list is different from the destination data size, first read the segment data from the source address of the segment recorded in the global list, then call the self-moving and self-decompressing program to decompress the read segment data, and then write the decompressed segment data to the destination address of the segment recorded in the global list.

Images