Method and apparatus for dynamically loading a boot application under u-boot

Abstract

The application discloses a method and device for dynamically loading and starting an application program under U-Boot, and relates to the technical field of embedded systems. The method comprises the following steps: collecting source file information of an application program which needs to be loaded in U-Boot; obtaining reference information of global variables and calling information of functions in the source file, and processing the referenced global variables and the called functions to obtain a position-independent code file; compiling the aforementioned position-independent code file to generate a position-independent executable binary file; modifying the aforementioned position-independent executable binary file to obtain a final position-independent executable binary file; and loading the final position-independent executable binary file in U-Boot to guide the application program to start. The application can significantly reduce the demand for memory capacity during the loading of the application program, and reduce the cost of the embedded device.

Description

Technical Field

[0001] This invention relates to the field of embedded systems technology, and in particular to a method and apparatus for dynamically loading and launching applications under U-Boot. Background Technology

[0002] U-Boot (Universal Boot Loader, also known as UBoot) is a boot loader primarily used for embedded systems. Its main function is to boot the operating system kernel. U-Boot supports various computer operating systems. It runs before the operating system kernel; after the kernel starts, applications run on top of it. During the boot process, U-Boot also initializes various hardware drivers—such as memory controllers, synchronous queue serial interfaces, and serial peripheral interfaces.

[0003] Currently, embedded devices with display capabilities typically need to load images (such as boot images) during the device startup phase for display. This requires U-boot to have the ability to dynamically load applications. However, traditional U-boot cannot load dynamic link libraries and applications. Therefore, existing technologies provide a solution to implement dynamic loader functionality in U-Boot: it compiles the programs and data that need to be loaded and executed under U-Boot into dynamic link libraries. When the application and data requiring dynamic linking are loaded by the operating system, the aforementioned dynamic loader locates and loads the necessary dynamic link library files. However, the above solution requires building a loader similar to an operating system to achieve dynamic loading of applications and data, which significantly increases the complexity and code size of U-boot.

[0004] On the other hand, due to manufacturing cost considerations, embedded devices are generally not configured with large memory capacity, while high-definition image data storage often requires a large amount of data, and limited memory capacity may not be able to meet display requirements.

[0005] On the other hand, embedded devices with display capabilities also require upgrades (replacing old programs and / or configuration data with new ones). Existing embedded device upgrade solutions in the industry can be summarized into three types: The first solution compiles all applications that need to be loaded and executed in the U-Boot environment into U-Boot, loading them together with the U-Boot core, which then handles the startup. This solution has the following drawbacks: device upgrades are usually partial, meaning only some applications and / or configuration data are upgraded, while infrastructure programs and related configuration data typically remain unchanged. This solution compiles and loads all applications and configuration data, failing to separate upgrade-independent objects from upgrade-dependent objects, resulting in significant waste of system resources; furthermore, loading them together with the U-Boot core places high demands on the embedded device's memory capacity. The second solution compiles the U-Boot core and the applications and data that need to be loaded and executed in the U-Boot environment separately. This first approach achieves independence (standalone) between the U-Boot core and the applications and configuration data that need to be loaded and executed within the U-Boot environment. Compared to the first approach, it allows upgrading only the applications and configuration data without upgrading the U-Boot core. However, it has the following drawbacks: a fixed link address must be specified during compilation and linking; if the specifications or memory layout of the embedded device change, the corresponding applications and data need to be recompiled, making dynamic loading impossible. The third approach uses a dynamic loader within U-Boot to compile the applications and data that need to be loaded and executed within the U-Boot environment into dynamic link libraries, which are then loaded and executed by the aforementioned dynamic loader. This approach also achieves independence between the U-Boot core and the applications and configuration data that need to be loaded and executed within the U-Boot environment, and can dynamically load applications. However, building a dynamic loader significantly increases the complexity and code size of U-Boot. Furthermore, none of the above three approaches can achieve separation of applications and configuration data. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a method and apparatus for dynamically loading and launching applications under U-Boot. The application loading scheme under U-Boot provided by this invention can generate a location-independent executable binary file from the application source file. This binary file can be loaded and executed at any location, allowing the application to be placed and executed anywhere without recompilation. Furthermore, the location-independent executable binary file allows for the separation of the application and configuration data. This means that only the application and configuration data can be upgraded without upgrading the U-Boot source code itself, or only the configuration data can be upgraded without changing the application. The separation of the application and configuration data allows the application to load configuration data in segments as needed, significantly reducing the memory required during application loading and thus lowering the cost of embedded devices.

[0007] To achieve the above objectives, the present invention provides the following technical solution: A method for dynamically loading and launching applications under U-Boot includes the following steps: Collect source file information of applications that need to be loaded in U-Boot; Obtain reference information for global variables and function call information from the source file; process the referenced global variables and called functions to obtain a position-independent code file; compile the aforementioned position-independent code file to generate a position-independent executable binary file; The aforementioned position-independent executable binary file is corrected to obtain the final position-independent executable binary file; U-Boot loads the aforementioned final location-independent executable binary and boots the aforementioned application.

[0008] Furthermore, the way to handle referenced global variables and called functions is as follows: For global variables referenced in the source file, if the global variable is defined in the source file, the global variable is placed in the preset configuration data area; if the global variable is not defined in the source file, a placeholder is used in the source file to occupy the space, and the name of the global variable occupied by the placeholder is recorded. For function calls in the source file, when the calling function is a function defined in the source file, the relative offset address of the calling function and the called function is recorded so that absolute address calls can be corrected to relative address calls later; when the calling function is not a function defined in the source file, a placeholder is used in the source file to place the function name, and the name of the function placed by the placeholder is recorded.

[0009] Furthermore, when processing referenced global variables and called functions, the global variables that need to be placed are first processed to obtain a first code file. Then, based on the first code file, the functions that need to be placed are processed to obtain a second code file. The second code file is the aforementioned position-independent code file.

[0010] Furthermore, the steps to obtain the first code file include: For each referenced global variable, determine whether the global variable is a global variable defined in the source file; If the determination is yes, the global variable is placed in the configuration data area for storage; otherwise, the global variable is determined to be a global variable in the U-Boot source code to be referenced. Based on the position of the global variable in the source file, a placeholder is used in the source file to place the global variable to obtain a position-independent first code file; at the same time, the name of the global variable that needs to be placed is recorded using a string, and different strings are used for different global variables.

[0011] Furthermore, the steps to obtain the second code file include: For each function call, determine whether the called function is a function defined in the source file; If the determination is yes, record the relative offset address of the calling function and the called function; otherwise, determine that the calling function is a function in an external file that needs to be called, and use a placeholder to place the function according to its position in the source file to obtain a position-independent second code file; at the same time, use a string to record the name of the function that needs to be placed, and use different strings for different functions.

[0012] Furthermore, the steps to modify the aforementioned position-independent executable binary file to obtain the final position-independent executable binary file include: S301, Scan the U-Boot source code to obtain the address and name of the global variable, and record the address and name of the global variable in the preset global variable description table; S302, Scan the aforementioned location-independent executable binary files to obtain global variable placeholders and global variable names; S303, determine whether the global variable name in the aforementioned position-independent executable binary file is consistent with the name recorded in the aforementioned global variable description table; if they are consistent, proceed to step S304, otherwise return to step S302. S304, replace the address of the global variable with the same name with the corresponding placeholder; S305, Scan the U-Boot source code to obtain the address and name of the required function, and record the address and name of the required function in the preset function description table; S306, Scan the aforementioned location-independent executable binary files to obtain function placeholders and function names; S307, determine whether the function name in the aforementioned position-independent executable binary file is consistent with the name recorded in the aforementioned function description table; if they are consistent, proceed to step S308. S308, replace the address of the function with the same name with the corresponding placeholder; S309, Scan the generated position-independent executable binary to obtain the call point location where the calling function is a function in the source file; S310, in the aforementioned position-independent executable binary file, the relative address offset call is replaced with the absolute address offset call to generate the final position-independent executable binary file.

[0013] Furthermore, a pre-defined script scans location-independent executable binaries to obtain the necessary information.

[0014] Furthermore, when loading the aforementioned final location-independent executable binary in U-Boot, the configuration data is loaded in segments, as follows: Load configuration data into U-Boot; and load the aforementioned final location-independent executable binary into U-Boot; In U-Boot, launch the previously loaded executable binary and load the starting address of the configuration data; Obtain the instruction to load configuration data in segments. Based on the segmentation requirements of the configuration data in the instruction, the aforementioned executable binary file reads the configuration data in segments and performs the configuration. Determine if all configuration data has been read; If the determination is yes, the binary code execution is complete, and control is handed over to U-Boot; otherwise, the executable binary file continues to read the next segment of configuration data and perform configuration until all configuration data has been read.

[0015] The present invention also provides a device for dynamically loading and launching applications under U-Boot, comprising the following structure: The information collection module is used to collect source file information of applications that need to be loaded in U-Boot; The information processing module is used to obtain reference information of global variables and function call information in the source file, process the referenced global variables and called functions to obtain a position-independent code file; compile the aforementioned position-independent code file to generate a position-independent executable binary file; and correct the aforementioned position-independent executable binary file to obtain the final position-independent executable binary file. The loading module is used to load the aforementioned final location-independent executable binary in U-Boot and bootstrap the aforementioned application.

[0016] Furthermore, the information processing module includes a global variable processing submodule and a function call processing submodule; The global variable processing submodule is configured to: for global variables referenced in the source file, if the global variable is a global variable defined in the source file, place the global variable in the preset configuration data area; if the global variable is not a global variable defined in the source file, use a placeholder in the source file to place it, and record the name of the global variable placed by the placeholder. The function call processing submodule is configured to: for function calls in the source file, when the calling function is a function defined in the source file, record the relative offset address of the calling function and the called function so that the absolute address call can be corrected to the relative address call later; when the calling function is not a function defined in the source file, use a placeholder in the source file to place the function and record the name of the function placed by the placeholder.

[0017] Compared with existing technologies, this invention, by adopting the above technical solutions, has the following advantages and positive effects: The U-Boot application loading solution provided by this invention can generate a location-independent executable binary file from the application source file. This binary file can be loaded and executed at any location, allowing the application to be placed in any location for execution without recompiling. Furthermore, the location-independent executable binary file can separate the application and configuration data, enabling the application and configuration data to be upgraded without upgrading the U-Boot source program itself, or the configuration data to be upgraded without changing the application. The separation of the application and configuration data allows the application to load configuration data in segments as needed, which can significantly reduce the memory required during application loading, thereby reducing the cost of embedded devices. Attached Figure Description

[0018] Figure 1 A flowchart illustrating the processing of position-independent global variables provided in this embodiment of the invention.

[0019] Figure 2 A flowchart illustrating the processing of position-independent function calls provided in an embodiment of the present invention.

[0020] Figure 3 This is a flowchart illustrating the correction of position-independent executable binary files provided in an embodiment of the present invention.

[0021] Figure 4This is a flowchart illustrating the segmented loading configuration data configuration for applications under U-Boot provided in this embodiment of the invention. Implementation

[0022] The method and apparatus for dynamically loading and launching applications under U-Boot disclosed in this invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the technical features or combinations of technical features described in the following embodiments should not be considered isolated; they can be combined with each other to achieve better technical effects. In the accompanying drawings of the following embodiments, the same reference numerals appearing in each drawing represent the same features or components, which can be applied to different embodiments. Therefore, once an item is defined in one drawing, it does not need to be further discussed in subsequent drawings.

[0023] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings are merely for illustrative purposes and to aid those skilled in the art in understanding and reading the invention. They are not intended to limit the conditions under which the invention can be implemented. Any modifications to the structure, changes in proportions, or adjustments to size, provided they do not affect the effectiveness or purpose of the invention, should fall within the scope of the technical content disclosed in the invention. The scope of the preferred embodiments of the present invention includes other implementations, wherein functions may be performed not in the order stated or discussed, including substantially simultaneously or in reverse order, depending on the functions involved. This should be understood by those skilled in the art to which the embodiments of the present invention pertain.

[0024] Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and apparatus should be considered part of the specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values. Example

[0025] In this invention, source code refers to a collection of statements written by computer programmers according to the syntax rules of a programming language to implement certain functional operations. A source file is a file that stores the source code. Because source code itself is a string of text data, it is stored in one or more files in a computer system; the file storing the source code is the source file. Compilation refers to the process of converting source code into a program that a computer can execute (generating object code that a computer can recognize, or machine code). Compilation is done by a compiler. After compilation, the source code becomes binary code, and the file storing this binary code is an executable binary file (or binary executable file).

[0026] The universal bootloader U-Boot is the first program (software) executed before the operating system (OS) starts. After the embedded device powers on, U-Boot is loaded first, configuring and initializing the hardware. Following initialization, U-Boot executes commands in the order specified in its source code, loading the target executable files into memory for execution. The objects to be loaded and executed in the U-Boot environment include the application's executable file and related configuration data (such as various configuration parameters of the application). In the existing technologies described above, because the addresses of variables and functions accessed in the executable file are fixed, the program cannot execute correctly if the load address changes. This means that the executable file can only be loaded and run at a specified address, making it impossible to dynamically load applications and configuration data. Furthermore, using existing position-independent code (PIC) and dynamic libraries to dynamically load applications and configuration data increases the complexity and code size of U-Boot and cannot achieve separation of application and configuration data.

[0027] Based on the above-mentioned prior art, the present invention provides a low-cost method for dynamically loading and launching applications under U-Boot. The method includes the following steps.

[0028] The S100 collects source file information for applications that need to be loaded in U-Boot. The source files store the application's source code.

[0029] S200: Obtain reference information for global variables and function call information from the source file; process the referenced global variables and called functions to obtain a position-independent code file; compile the aforementioned position-independent code file to generate a position-independent executable binary file.

[0030] S300, the aforementioned position-independent executable binary file is corrected to obtain the final position-independent executable binary file.

[0031] S400 loads the aforementioned final location-independent executable binary in U-Boot and boots the aforementioned application.

[0032] This invention generates a position-independent executable binary file by processing global variables and function calls in the application source file. The position-independent executable binary file can be loaded and executed at any location.

[0033] Specifically, in step S200, for global variables referenced in the source file, the following processing is performed: when the global variable is a global variable defined in this source file, the global variable is placed in the preset configuration data area; when the global variable is not a global variable defined in this source file, a placeholder is used in this source file to occupy the space, and the name of the global variable occupied by the placeholder is recorded.

[0034] For function calls in the source file, the following processing is performed: When the calling function is a function defined in this source file, the relative offset address of the calling function and the called function is recorded so that absolute address calls can be corrected to relative address calls later; when the calling function is not a function defined in this source file, a placeholder is used in this source file to place the function name, and the name of the function placed by the placeholder is recorded.

[0035] As a preferred typical approach, when processing referenced global variables and called functions, the global variables that need to be placed can be processed first to obtain a first code file. Then, based on the first code file, the functions that need to be placed can be processed to obtain a second code file. At this time, the second code file obtained is the aforementioned position-independent code file.

[0036] See Figure 1 As shown, the specific steps to obtain the first code file are as follows: S201. For each referenced global variable, determine whether the global variable is a global variable defined in the source file; if yes, proceed to step S203; otherwise, proceed to step S205.

[0037] S203, place the global variable in the configuration data area for later compilation by the compiler.

[0038] S205 determines that the global variable is a global variable in the U-Boot source code to be referenced. Based on the global variable's position in the source file, a placeholder is used in that source file to create a position-independent first code file. Simultaneously, a string is used to record the name of the global variable that needs to be placed, so that the compiler can compile it later. Different global variables use different strings.

[0039] For global variables defined in the application source file, this invention places them in a preset configuration data area. The configuration data is retrieved from the aforementioned configuration data area (the storage address) during execution. For global variables in the U-Boot source program body referenced in the application source file, this invention first uses placeholders in the application source file to reserve the global variables in the U-Boot source program body that will be referenced. A string is used to record the name of the global variable corresponding to the placeholder (e.g., placeholder 0). (Because the compiler needs to know which global variable corresponds to placeholder 0 during compilation so that the actual storage address of the global variable can be used to replace the placeholder, a string is used to record the name of the global variable that the placeholder needs to reserve.) This allows the compiler to correctly compile and link the global variable addresses in the position-independent executable binary file.

[0040] See Figure 2 As shown, the specific steps to obtain the second code file are as follows: S202, For each called function, determine whether the called function is a function defined in the source file; if it is, execute step S204, otherwise execute step S206.

[0041] S204 records the relative offset addresses of the calling function and the called function, so that the compiler can compile it later.

[0042] S206 determines that the called function is located in an external file. Based on the function's position in the source file, a placeholder is used to store the function, resulting in a position-independent second code file. Simultaneously, a string is used to record the name of the placeholder function for later compilation by the compiler. Different functions use different strings.

[0043] For function calls in application source files, when the calling function is a function defined in the same source file, the relative offset address between the calling function and the called function needs to be recorded so that absolute address calls can be corrected to relative address calls later. However, when the calling function is a function call from another file, since it is not compiled with the U-boot source program, the addresses of these functions cannot be known during compilation. The proposed solution is to use placeholders in the source file to place the function names of the external files that need to be called, and use a string to record the name of the placeholder function so that it can be corrected to the actual function address of the called function later, ensuring that the function address can be called correctly.

[0044] After the above two processes, a position-independent code file is obtained. The compiler then compiles and links this position-independent code file to produce a corresponding position-independent executable binary file. However, in this position-independent executable binary file, references to global variables in other files are still placeholders and do not reference the actual addresses of the global variables; similarly, function calls within this file still use absolute addresses, and function calls to functions in other files are still placeholders rather than the actual addresses of those functions. Therefore, further modifications to the aforementioned position-independent executable binary file are required.

[0045] This invention performs scanning and correction based on information such as placeholders used in the aforementioned two processes, the recorded relative offset address, the name of the global variable corresponding to the recorded placeholder, and the name of the called function (calling a function in an external file) corresponding to the recorded placeholder. For the specific correction process, please refer to [link to relevant documentation]. Figure 3 As shown.

[0046] See Figure 3 As shown, the process of correcting the aforementioned position-independent executable binary file to obtain the final position-independent executable binary file includes the following steps.

[0047] S301, Scan the U-Boot source code to obtain the address and name of the global variable, and record the address and name of the global variable in the preset global variable description table.

[0048] S302, Scan the aforementioned location-independent executable binary files to obtain global variable placeholders and global variable names.

[0049] S303, determine whether the global variable name in the aforementioned position-independent executable binary file is consistent with the name recorded in the aforementioned global variable description table; if they are consistent, proceed to step S304, otherwise return to step S302.

[0050] S304, replace the address of the global variable with the same name with the corresponding placeholder.

[0051] S305, scan the U-Boot source code to obtain the address and name of the required function, and record the address and name of the required function in the preset function description table.

[0052] S306, Scan the aforementioned location-independent executable binary files to obtain function placeholders and function names.

[0053] S307, determine whether the function name in the aforementioned position-independent executable binary file is consistent with the name recorded in the aforementioned function description table; if they are consistent, proceed to step S308.

[0054] S308 replaces the address of a function with the same name with the corresponding placeholder.

[0055] S309, Scan the generated position-independent executable binary to obtain the call point location of the function that is a function in the source file.

[0056] S310, in the aforementioned position-independent executable binary file, the relative address offset call is replaced with the absolute address offset call to generate the final position-independent executable binary file.

[0057] Once the final location-independent executable binary for the application is generated, the executable binary can be loaded via U-Boot.

[0058] Preferably, when loading the aforementioned final location-independent executable binary in U-Boot, a segmented loading method for configuration data is used to save memory. See also Figure 4 As shown, the specific steps are as follows.

[0059] S401, load configuration data in U-Boot; and load the aforementioned final location-independent executable binary in U-Boot.

[0060] S402, In U-Boot, start the aforementioned loaded executable binary file and load the starting address of the configuration data.

[0061] S403, obtain the instruction to load configuration data in segments, and according to the configuration data segmentation requirements in the instruction, the aforementioned executable binary file reads the configuration data in segments and performs configuration.

[0062] S404 checks whether all configuration data has been read.

[0063] S405: If the determination is yes, the binary code execution is complete, and control is handed over to U-Boot; otherwise, return to step S403 to continue reading the next segment of configuration data from the executable binary file and configuring it, until all configuration data has been read.

[0064] The above-described embodiments provided by the present invention utilize the characteristic that position-independent executable binary files are not restricted by position during execution to separate the executable file of the application and the configuration data, so that the application can load the configuration data in segments when loading, thereby reducing the cost of embedded devices.

[0065] Another embodiment of the present invention also provides a device for dynamically loading and launching applications under U-Boot.

[0066] The device shown includes an information acquisition module, an information processing module, and a loading module.

[0067] The information collection module is used to collect source file information of applications that need to be loaded in U-Boot.

[0068] The information processing module is used to obtain reference information of global variables and function call information in the source file, process the referenced global variables and called functions to obtain a position-independent code file; compile the aforementioned position-independent code file to generate a position-independent executable binary file; and correct the aforementioned position-independent executable binary file to obtain the final position-independent executable binary file.

[0069] The loading module is used to load the aforementioned final location-independent executable binary file in U-Boot and guide the aforementioned application to start.

[0070] Specifically, the information processing module may include a global variable processing submodule and a function call processing submodule.

[0071] The global variable processing submodule is configured to: for global variables referenced in the source file, if the global variable is a global variable defined in the source file, place the global variable in the preset configuration data area; if the global variable is not a global variable defined in the source file, use a placeholder in the source file to occupy the space, and record the name of the global variable occupied by the placeholder.

[0072] The function call processing submodule is configured to: for function calls in the source file, when the calling function is a function defined in the source file, record the relative offset address of the calling function and the called function so that the absolute address call can be corrected to the relative address call later; when the calling function is not a function defined in the source file, use a placeholder in the source file to place the function and record the name of the function placed by the placeholder.

[0073] Preferably, when processing referenced global variables and called functions, the global variables that need to be placed are first processed to obtain a first code file, and then the functions that need to be placed are processed to obtain a second code file based on the first code file. The second code file is the aforementioned position-independent code file.

[0074] The information processing module further includes an executable file correction submodule, which is configured to perform the following steps: S301, Scan the U-Boot source code to obtain the address and name of the global variable, and record the address and name of the global variable in the preset global variable description table; S302, Scan the aforementioned location-independent executable binary files to obtain global variable placeholders and global variable names; S303, determine whether the global variable name in the aforementioned position-independent executable binary file is consistent with the name recorded in the aforementioned global variable description table; if they are consistent, proceed to step S304, otherwise return to step S302. S304, replace the address of the global variable with the same name with the corresponding placeholder; S305, Scan the U-Boot source code to obtain the address and name of the required function, and record the address and name of the required function in the preset function description table; S306, Scan the aforementioned location-independent executable binary files to obtain function placeholders and function names; S307, determine whether the function name in the aforementioned position-independent executable binary file is consistent with the name recorded in the aforementioned function description table; if they are consistent, proceed to step S308. S308, replace the address of the function with the same name with the corresponding placeholder; S309, Scan the generated position-independent executable binary to obtain the call point location where the calling function is a function in the source file; S310, in the aforementioned position-independent executable binary file, the relative address offset call is replaced with the absolute address offset call to generate the final position-independent executable binary file.

[0075] In this embodiment, there are two modes for loading the application: normal loading mode and segmented loading mode.

[0076] In normal loading mode, the loading module is configured to: load configuration data in U-Boot; and load the aforementioned final location-independent executable binary file in U-Boot; start the aforementioned loaded executable binary file in U-Boot, obtain configuration data, perform configuration according to the configuration data, and execute the aforementioned executable binary file.

[0077] In segmented loading mode, the loading module is configured to: load configuration data in U-Boot; and load the aforementioned final location-independent executable binary file in U-Boot; start the aforementioned loaded executable binary file in U-Boot and load the starting address of the configuration data; obtain instructions for segmented loading of configuration data, and according to the configuration data segmentation requirements in the instructions, the aforementioned executable binary file reads and configures the configuration data segment by segment; determine whether the configuration data has been completely read; if yes, the binary code execution is completed, and control is handed over to U-Boot; otherwise, the aforementioned executable binary file continues to read and configure the next segment of configuration data until all configuration data has been read.

[0078] Other technical features are described in the previous embodiments and will not be repeated here.

[0079] In the above description, the disclosure of this invention is not intended to limit itself to these aspects. Rather, within the scope of the objectives of this disclosure, components can be selectively and operationally combined in any number. Furthermore, terms such as “comprising,” “encompassing,” and “having” should be interpreted by default as inclusive or open-ended, rather than exclusive or closed, unless explicitly defined as such. All technical, scientific, or other terms are to be understood by those skilled in the art, unless defined as such. Public terms found in dictionaries should not be interpreted in the context of the relevant technical documents in an overly idealistic or impractical manner, unless explicitly defined as such in this disclosure. Any modifications or alterations made by those skilled in the art based on the foregoing disclosure are within the scope of the claims.

Claims

1. A method for dynamically loading a boot application under U-Boot, characterized in that Including the following steps: Collect source file information of applications that need to be loaded in U-Boot; Obtain reference information for global variables and function call information from the source file, and process the referenced global variables and called functions to obtain a position-independent code file; The aforementioned position-independent code files are compiled to generate position-independent executable binary files. The processing method is as follows: for global variables referenced in the source files, if the global variable is defined in the source file, it is placed in a preset configuration data area; if the global variable is not defined in the source file, a placeholder is used in the source file, and the name of the global variable occupied by the placeholder is recorded. For called functions in the source files, if the called function is defined in the source file, the relative offset address between the called function and the called function is recorded so that absolute address calls can be corrected to relative address calls later; if the called function is not defined in the source file, a placeholder is used in the source file, and the name of the function occupied by the placeholder is recorded. The aforementioned position-independent executable binary file is modified to obtain a final position-independent executable binary file, including the following steps: S301, scan the U-Boot source code to obtain the addresses and names of global variables, and record the addresses and names of the global variables in a preset global variable description table; S302, scan the aforementioned position-independent executable binary file to obtain the global variable placeholders and global variable names; S303, determine whether the global variable names in the aforementioned position-independent executable binary file are consistent with the names recorded in the aforementioned global variable description table; if they are consistent, proceed to step S304, otherwise return to step S302; S304, replace the addresses of global variables with consistent names with the corresponding placeholders; S305, scan the U-Boot source code to obtain... S306. Extract the address and name of the required function and record them in a preset function description table; S307. Scan the aforementioned position-independent executable binary file to obtain the function placeholders and function names; S308. Determine whether the function names in the aforementioned position-independent executable binary file are consistent with the names recorded in the aforementioned function description table; if they are consistent, proceed to step S309; ​​S301. Replace the address of the function with the same name with the corresponding placeholder; S302. Scan the generated position-independent executable binary file to obtain the call point location of the function in the source file; S313. Replace the absolute address offset call with a relative address offset call in the aforementioned position-independent executable binary file to generate the final position-independent executable binary file. U-Boot loads the aforementioned final location-independent executable binary and boots the aforementioned application.

2. The method according to claim 1, characterized in that, When processing referenced global variables and called functions, first, placeholder processing is performed on the global variables that need to be placed to obtain the first code file. Then, based on the first code file, placeholder processing is performed on the functions that need to be placed to obtain the second code file. The second code file is the aforementioned position-independent code file.

3. The method according to claim 2, characterized in that, The steps to obtain the first code file include: For each referenced global variable, determine whether the global variable is a global variable defined in the source file; If the determination is yes, the global variable is placed in the configuration data area for storage; otherwise, the global variable is determined to be a global variable in the U-Boot source code to be referenced. Based on the position of the global variable in the source file, a placeholder is used in the source file to place the global variable to obtain a position-independent first code file; at the same time, the name of the global variable that needs to be placed is recorded using a string, and different strings are used for different global variables.

4. The method according to claim 2, characterized in that, The steps to obtain the second code file include: For each function call, determine whether the called function is a function defined in the source file; If the determination is yes, record the relative offset address of the calling function and the called function; otherwise, determine that the calling function is a function in an external file that needs to be called, and use a placeholder to place the function according to its position in the source file to obtain a position-independent second code file; at the same time, use a string to record the name of the function that needs to be placed, and use different strings for different functions.

5. The method according to claim 1, characterized in that, The system uses a pre-defined script to scan location-independent executable binaries to obtain the necessary information.

6. The method according to claim 1, characterized in that, When loading the aforementioned final location-independent executable binary in U-Boot, the configuration data is loaded in segments, as follows: Load configuration data into U-Boot; and load the aforementioned final location-independent executable binary into U-Boot; In U-Boot, launch the previously loaded executable binary and load the starting address of the configuration data; Obtain the instruction to load configuration data in segments. Based on the segmentation requirements of the configuration data in the instruction, the aforementioned executable binary file reads the configuration data in segments and performs the configuration. Determine if all configuration data has been read; If the determination is yes, the binary code execution is complete, and control is handed over to U-Boot; otherwise, the executable binary file continues to read the next segment of configuration data and perform configuration until all configuration data has been read.

7. A device for dynamically loading and launching applications under U-Boot, characterized in that... include: The information collection module is used to collect source file information of applications that need to be loaded in U-Boot; The information processing module is used to obtain reference information of global variables and function call information in the source file, and to process the referenced global variables and called functions to obtain a position-independent code file. The aforementioned position-independent code files are compiled to generate position-independent executable binaries; The process involves modifying the aforementioned position-independent executable binary to obtain a final position-independent executable binary, including the following steps: S301, scanning the U-Boot source code to obtain the addresses and names of global variables, and recording the addresses and names of these global variables in a preset global variable description table; S302, scanning the aforementioned position-independent executable binary to obtain global variable placeholders and global variable names; S303, determining whether the global variable names in the aforementioned position-independent executable binary are consistent with the names recorded in the aforementioned global variable description table; if they are consistent, proceed to step S304; otherwise, return to step S302; S304, replacing the addresses of global variables with consistent names with the corresponding placeholders; S305, scanning the U-Boot source code. S306. Obtain the address and name of the required function and record the address and name of the required function in a preset function description table; S307. Scan the aforementioned position-independent executable binary file to obtain the function placeholders and function names therein; S308. Determine whether the function name in the aforementioned position-independent executable binary file is consistent with the name recorded in the aforementioned function description table; if consistent, proceed to step S309; ​​S301. Replace the address of the function with the same name with the corresponding placeholder; S302. Scan the generated position-independent executable binary file to obtain the call point position of the function in the source file; S313. Replace the absolute address offset call with a relative address offset call in the aforementioned position-independent executable binary file to generate the final position-independent executable binary file; The loading module is used to load the aforementioned final location-independent executable binary in U-Boot and bootstrap the aforementioned application. The information processing module includes a global variable processing submodule and a function call processing submodule; The global variable processing submodule is configured to: for global variables referenced in the source file, if the global variable is a global variable defined in the source file, place the global variable in the preset configuration data area; if the global variable is not a global variable defined in the source file, use a placeholder in the source file to place it, and record the name of the global variable placed by the placeholder. The function call processing submodule is configured to: for function calls in the source file, when the calling function is a function defined in the source file, record the relative offset address of the calling function and the called function so that the absolute address call can be corrected to the relative address call later; when the calling function is not a function defined in the source file, use a placeholder in the source file to place the function and record the name of the function placed by the placeholder.

Images