Program quick starting method and device of Linux system, equipment and medium

Abstract

The invention discloses a method, a device and equipment for quickly starting a program of a Linux system and a medium, and the method comprises the following steps: after initializing an SoC chip and a dram memory, loading a binary file from a storage module to the dram memory, decompressing to obtain a quick-start application program and a kernel code corresponding to the Linux system, and performing kernel initialization based on the kernel code; all the drives loaded by the dram memory are divided into a first drive and a second drive, the first drive is initialized, the quick-start application program is operated, the second drive is initialized, the first drive is a necessary drive before the quick-start application program is operated, and the second drive is the remaining drive except the first drive in all the drives. According to the method, before the quick-start application is started, only the necessary drive is initialized, and the unnecessary drive is delayed to be initialized, so that the starting process of the quick-start application is prevented from being blocked, and the starting of the application program of the embedded Linux system can be effectively accelerated.

Description

Technical Field

[0001] The present application relates to, but is not limited to, the field of embedded system technology, and in particular to a method, apparatus, device, and medium for quickly starting a program in a Linux system. Background Art

[0002] The process of starting an application on an embedded Linux system includes a driver initialization stage. Currently, the embedded Linux system will initialize all registered drivers in the system during the driver initialization stage, resulting in the embedded Linux system having to wait until all registered drivers are initialized before starting the main application. Since the registered drivers include some temporarily unused peripheral drivers, unnecessary startup delays are caused, which postpones the startup time of the application and cannot meet the fast startup requirements of the embedded Linux system application. Summary of the Invention

[0003] The embodiments of the present application provide a method, apparatus, device and medium for quickly starting a program in a Linux system, which can effectively speed up the startup of an application program in an embedded Linux system.

[0004] In a first aspect, an embodiment of the present application provides a method for quickly starting a program in a Linux system, which is applied to a control chip of the Linux system, the control chip including a CROM memory, an SRAM memory, a SoC chip, and a DRAM memory, the control chip being communicatively connected to a storage module, the storage module belonging to the Linux system, the method comprising:

[0005] When the control chip is powered on, the chip curing program in the CROM memory is run to load the SPL program into the SRAM memory;

[0006] Run the SPL program in the SRAM memory to initialize the SoC chip and the DRAM memory, read a binary file from the storage module, and load the binary file into the DRAM memory;

[0007] Decompressing the binary file in the DRAM memory to obtain a quick start application and kernel code corresponding to the Linux system, and performing kernel initialization based on the kernel code;

[0008] All drivers loaded into the DRAM memory are divided into a first driver and a second driver, the first driver is initialized, the quick start application is run, and the second driver is initialized, wherein the first driver is a necessary driver before the quick start application is run, and the second driver is the remaining driver among all the drivers except the first driver.

[0009] In some embodiments, the binary file includes a dtb file, the dtb file is associated with a device tree, and reading the binary file from the storage module and loading the binary file into the dram memory includes:

[0010] Determine a first device node and a second device node from the device tree, wherein the first device node is a device node with no reference in the device tree, and the second device node is a device node in the device tree that is currently unavailable;

[0011] The first device node and the second device node in the device tree are deleted.

[0012] In some embodiments, the binary file includes a kernel compressed file, the kernel compressed file corresponds to the first source file, and before reading the binary file from the storage module, the method further includes:

[0013] Tailoring a first function file from the first source file, wherein the first function file is a function file in the first source file other than the function file that meets the basic requirements of the Linux system;

[0014] determining a first target compression algorithm from a plurality of candidate compression algorithms based on a first loading duration and a first compression duration of the cropped first source file;

[0015] The cropped first source file is compressed based on the first target compression algorithm to obtain the kernel compressed file.

[0016] In some embodiments, the binary file includes a ramfs compressed file, the ramfs compressed file corresponds to a second source file, and before reading the binary file from the storage module, the method further includes:

[0017] trimming the dynamic libraries other than the shared libraries associated with the C library in the second source file, and removing the executable program symbol information corresponding to the quick-start application in the second source file;

[0018] Adjusting the quick start application to be a static link;

[0019] Determining a second target compression algorithm from a plurality of candidate compression algorithms based on a second loading duration and a second compression duration of the cropped second source file;

[0020] The cropped second source file is compressed based on the second target compression algorithm to obtain the ramfs compressed file.

[0021] In some embodiments, before reading the binary file from the storage module and loading the binary file into the DRAM memory, the method further includes:

[0022] Determining the quick start application and all dependencies associated with the quick start application from the storage module;

[0023] All the dependencies and the quick start application are packaged and compressed into the ramfs compressed file.

[0024] In some embodiments, before initializing the first driver, running the quick start application, and initializing the second driver, the method further includes:

[0025] Encapsulate the first driver into the first-stage driver class, and encapsulate the second driver into the second-stage driver class;

[0026] By compiling the first-stage driver class into the first field, compiling the second-stage driver class into the second field, and associating user requirements with the second field, the startup script is adjusted, wherein the execution order of the first field in the startup script is before the third field corresponding to the quick-start application, and the second field is after the third field.

[0027] In some embodiments, the second-stage driver class includes multiple second drivers, different second drivers correspond to different user needs, initializing the first driver, running the quick start application, and initializing the second driver include:

[0028] Run the first field in the startup script to initialize the first driver;

[0029] Run the third field to run the quick start application;

[0030] When a reference user requirement for running the quick start application is received, the second field is run, a second driver corresponding to the user requirement corresponding to the reference user requirement is determined as a target driver, and the target driver is initialized.

[0031] In a second aspect, an embodiment of the present application provides a control device comprising at least one control processor and a memory for communicating with the at least one control processor; the memory stores instructions that can be executed by the at least one control processor, and the instructions are executed by the at least one control processor so that the at least one control processor can execute the program quick startup method of the Linux system as described in the first aspect.

[0032] In a third aspect, an embodiment of the present application further provides an electronic device comprising the control device of the second aspect.

[0033] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the method for quickly starting a program in a Linux system as described in the first aspect.

[0034] The embodiment of the present application provides a method, device, equipment and medium for quickly starting a program in a Linux system. The method includes: when the control chip is powered on, running the chip curing program in the CROM memory to load the SPL program into the SRAM memory; running the SPL program in the SRAM memory to initialize the SoC chip and the DRAM memory, reading a binary file from the storage module, and loading the binary file into the DRAM memory; decompressing the binary file in the DRAM memory to obtain the quick start application and kernel code corresponding to the Linux system, and performing kernel initialization based on the kernel code; dividing all drivers loaded in the DRAM memory into a first driver and a second driver, initializing the first driver, running the quick start application, and initializing the second driver, wherein the first driver is a necessary driver before the quick start application runs, and the second driver is the remaining driver in all the drivers except the first driver. According to the solution provided in the embodiment of the present application, a mechanism for initializing the driver in stages is introduced. Only necessary drivers are initialized before starting the quick start application, and non-essential drivers are initialized later to avoid blocking the startup process of the quick start application, which can effectively speed up the startup of the application of the embedded Linux system. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a flowchart of the steps of a method for quickly starting a program in a Linux system provided by an embodiment of the present application;

[0036] Figure 2 This is a structural diagram of a control device provided in another embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0038] It is understood that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and the like in the specification, claims, or accompanying drawings are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0039] The process of starting an application on an embedded Linux system includes a driver initialization stage. Currently, the embedded Linux system will initialize all registered drivers in the system during the driver initialization stage, resulting in the embedded Linux system having to wait until all registered drivers are initialized before starting the main application. Since the registered drivers include some temporarily unused peripheral drivers, unnecessary startup delays are caused, which postpones the startup time of the application and cannot meet the fast startup requirements of the embedded Linux system application.

[0040] To solve the above-mentioned problems, the embodiment of the present application provides a method, device, equipment and medium for quickly starting a program in a Linux system. The method includes: when the control chip is powered on, running the chip curing program in the CROM memory to load the SPL program into the SRAM memory; running the SPL program in the SRAM memory to initialize the SoC chip and the DRAM memory, reading a binary file from the storage module, and loading the binary file into the DRAM memory; decompressing the binary file in the DRAM memory to obtain the quick start application and kernel code corresponding to the Linux system, and performing kernel initialization based on the kernel code; dividing all drivers loaded in the DRAM memory into a first driver and a second driver, initializing the first driver, running the quick start application, and initializing the second driver, wherein the first driver is a necessary driver before the quick start application runs, and the second driver is the remaining driver in all the drivers except the first driver. According to the solution provided in the embodiment of the present application, a mechanism for initializing the driver in stages is introduced. Only necessary drivers are initialized before starting the quick start application, and non-essential drivers are initialized later to avoid blocking the startup process of the quick start application, which can effectively speed up the startup of the application of the embedded Linux system.

[0041] The embodiments of the present application are further described below with reference to the accompanying drawings.

[0042] refer to Figure 1 , Figure 1This is a flowchart of the steps of a method for quickly starting a program in a Linux system provided by an embodiment of the present application. The embodiment of the present application provides a method for quickly starting a program in a Linux system. The method is applied to a control chip of the Linux system. The control chip includes a CROM memory, an SRAM memory, a SoC chip, and a DRAM memory. The control chip is communicatively connected with a storage module, and the storage module belongs to the Linux system. The method includes but is not limited to the following steps:

[0043] Step S10, when the control chip is powered on, the chip curing program in the CROM memory is run to load the SPL program into the SRAM memory;

[0044] Step S20, running the SPL program in the SRAM memory to initialize the SoC chip and the DRAM memory, reading the binary file from the storage module, and loading the binary file into the DRAM memory;

[0045] Step S30: decompress the binary file in the DRAM memory to obtain the quick start application and kernel code corresponding to the Linux system, and perform kernel initialization based on the kernel code;

[0046] In step S40, all drivers loaded into the DRAM memory are divided into a first driver and a second driver, the first driver is initialized, the quick start application is run, and the second driver is initialized, wherein the first driver is a necessary driver before the quick start application is run, and the second driver is the remaining driver among all drivers except the first driver.

[0047] Specifically, the quick start application is a program for starting the Linux system in this embodiment.

[0048] It can be understood that the Linux system program quick startup method of this embodiment omits the u-boot stage compared to the traditional operating system startup method. The u-boot stage involves operations such as displaying the system startup logo and sound broadcasting. If the actual application scenario of the quick startup application is simply to boot the operating system, omitting the u-boot stage can reduce the storage space occupied by the u-boot executable program itself. At the same time, it can also avoid the time consumption of reading the u-boot binary file from the storage medium to the memory, thereby reducing the overall system startup time.

[0049] It is understandable that the current embedded Linux system will initialize all registered drivers in the system during the driver initialization phase, resulting in the embedded Linux system having to wait for all registered drivers to be initialized before starting the main application. Since the registered drivers include some temporarily unused peripheral drivers, unnecessary startup delays are caused, which delays the startup time of the application and cannot meet the fast startup requirements of the embedded Linux system application. Based on this, after the control chip is powered on, the chip curing program in the CROM memory is run to load the SPL program into the SRAM memory, and the SPL program is run in the SRAM memory to initialize the SoC chip and the DRAM memory, read the binary file from the storage module, and load the binary file into the DRAM memory, then decompress the binary file in the DRAM memory to obtain the quick start application and kernel code corresponding to the Linux system, perform kernel initialization based on the kernel code, and after completing the kernel initialization, this application introduces a mechanism for initializing the driver in stages, first dividing all the drivers loaded in the DRAM memory into the first driver and the second driver, and then In the embodiment, the first driver is a necessary driver before the quick-start application is run, and the second driver is the remaining driver except the first driver in all drivers. After the division is completed, in actual application, only the necessary driver (i.e., the first driver) is initialized before starting the quick-start application, and the initialization of the unnecessary driver (i.e., the second driver) is delayed. After waiting for the quick-start application to run, the second driver is initialized, which can effectively avoid blocking the startup process of the quick-start application. In this way, this embodiment omits the u-boot stage of system startup and uses a staged driver initialization mechanism to accelerate the startup of the embedded Linux system application, thereby meeting the fast startup requirements of the embedded Linux system application.

[0050] In addition, in some embodiments, the binary file includes a dtb file, and the dtb file is associated with a device tree. Figure 1 The process of reading the binary file from the storage module and loading the binary file into the DRAM memory in step S20 includes but is not limited to the following steps:

[0051] Step S21, determining a first device node and a second device node from the dtb file, wherein the first device node is a device node that has no reference in the device tree, and the second device node is a device node that is currently unavailable in the device tree;

[0052] Step S22: Delete the first device node and the second device node in the device tree.

[0053] In addition, in some embodiments, the binary file includes a kernel compressed file, and the kernel compressed file corresponds to the first source file. Figure 1Before reading the binary file from the storage module and loading the binary file into the DRAM memory in step S20, the method for quickly starting a program in a Linux system provided by the embodiment of the present application includes but is not limited to the following steps:

[0054] Step S51, cutting out a first function file from a first source file, wherein the first function file is a function file in the first source file other than the function file that meets the basic requirements of the Linux system;

[0055] Step S52, determining a first target compression algorithm from a plurality of candidate compression algorithms based on the first loading duration and the first compression duration of the cropped first source file;

[0056] Step S53: compressing the cropped first source file based on the first target compression algorithm to obtain a kernel compressed file.

[0057] In addition, in some embodiments, the binary file includes a ramfs compressed file, and the ramfs compressed file corresponds to a second source file. Figure 1 Before reading the binary file from the storage module and loading the binary file into the DRAM memory in step S20, the method for quickly starting a program in a Linux system provided by the embodiment of the present application includes but is not limited to the following steps:

[0058] Step S54, trimming the dynamic libraries in the second source file except the shared libraries associated with the C library, and removing the executable program symbol information corresponding to the quick start application in the second source file;

[0059] Step S55, adjusting the quick start application to a static link;

[0060] Step S56, determining a second target compression algorithm from a plurality of candidate compression algorithms based on the second loading duration and the second compression duration of the cropped second source file;

[0061] Step S57: compress the cropped second source file based on the second target compression algorithm to obtain a ramfs compressed file.

[0062] It can be understood that in order to achieve fast startup of the Linux system, this embodiment minimizes the file size of the loaded binary files (including dtb files, kernel compressed files and ramfs compressed files). Specifically, for the dtb file, the dtb file is a device tree associated with the SoC chip. This embodiment determines the first device node and the second device node from the device tree, deletes the first device node and the second device node in the device tree, wherein the first device node is a device node with no reference in the device tree, and the second device node is a device node in the device tree whose status is currently unavailable (i.e., the status is "disabled"). The first device node and the second device node correspond to unnecessary kernel functions that are not directly related to system startup, effectively speeding up the startup of the quick-start application of the embedded Linux system. For kernel compressed files, the first functional files (such as debug, trace, network modules, redundant file system modules, etc.) other than those that meet the basic requirements of the Linux system in the first source file corresponding to the kernel compressed file are trimmed, that is, unnecessary kernel functions and unneeded modules that are not directly related to system startup can be trimmed. In addition, based on the first loading time and the first compression time of the trimmed first source file, a first target compression algorithm is determined from multiple candidate compression algorithms, and the trimmed first source file is compressed based on the first target compression algorithm to obtain a kernel compressed file, that is, a compression algorithm with a fast decompression speed is selected to implement the compression processing of the first source file, which can effectively reduce the self-decompression time of the kernel compressed file. For the ramfs compressed file, the dynamic libraries except the shared libraries associated with the C library in the second source file corresponding to the ramfs compressed file are cropped, busybox is cropped, non-essential commands are deleted, and the executable program symbol information corresponding to the quick-start application in the second source file is removed; the quick-start application is adjusted to a static link. In addition, based on the second loading time and the second compression time of the cropped second source file, a second target compression algorithm is determined from multiple candidate compression algorithms, and the cropped second source file is compressed based on the second target compression algorithm to obtain a ramfs compressed file, that is, a compression algorithm with a fast decompression speed is selected to implement the compression processing of the second source file, which can effectively reduce the self-decompression time of the ramfs compressed file.

[0063] Specifically, this embodiment does not limit the specific first target compression algorithm and second target compression algorithm, which may be a gzip algorithm or an lz4 algorithm.

[0064] Additionally, in some embodiments, when executing Figure 1Before reading the binary file from the storage module and loading the binary file into the DRAM memory in step S20, the method for quickly starting a program in a Linux system provided by the embodiment of the present application includes but is not limited to the following steps:

[0065] Step S58: determining the quick start application and all dependencies associated with the quick start application from the storage module;

[0066] Step S59: Package all dependencies and quick-start applications and compress them into a ramfs compressed file.

[0067] Understandably, in the existing process for launching Linux quick-start applications, the app's associated resource files, dependencies, and other binary files are stored in root files. This means that when running a quick-start application, the app's executable binary file must first be read from the storage module into memory. Simultaneously, to properly run the quick-start application, its dependent dynamic libraries and resource files must also be read from the storage module into memory. However, the existing read operations for loading the quick-start application and its associated resource files into memory are performed in multiple, dispersed batches, resulting in system overhead and affecting application startup time. Based on this, before loading the binary file into the DRAM memory, the embodiment of the present application determines the quick-start application and all dependencies associated with the quick-start application from the storage module, packages all dependencies and the quick-start application and compresses them into a ramfs compressed file, that is, a ramfs compressed file carries all the resources of the quick-start application. After subsequently loading the ramfs compressed file into the DRAM memory, all resources that depend on the quick-start application are loaded into the memory at one time, which can greatly reduce the system overhead consumed by the operations of obtaining and loading the quick-start application and dependencies from the storage module in multiple batches and in a dispersed manner, effectively improve the loading efficiency of the quick-start application, and thus achieve the purpose of starting the application faster.

[0068] Additionally, in some embodiments, when executing Figure 1 Before initializing the first driver, running the quick start application, and initializing the second driver in step S40, the method for quickly starting a program in a Linux system provided by the embodiment of the present application includes but is not limited to the following steps:

[0069] Step S61, encapsulating the first driver into the first stage driver class, and encapsulating the second driver into the second stage driver class;

[0070] Step S62, by compiling the first-stage driver class into the first field, compiling the second-stage driver class into the second field, and associating the user requirements with the second field to adjust the startup script, wherein the execution order of the first field in the startup script is before the third field corresponding to the quick-start application, and the second field is after the third field.

[0071] It can be understood that after classifying the necessary first driver and unnecessary second driver corresponding to the quick start application, and before executing the staged driver initialization, this embodiment adjusts the startup script based on the first driver and the second driver, so that the staged driver initialization operation can be executed after running the adjusted startup script. Specifically, the specific operations of adjusting the startup script in this embodiment include: encapsulating the first driver into the first stage driver class, and encapsulating the second driver into the second stage driver class; by compiling the first stage driver class into the first field (init segment) and the second stage driver class into the second field (defer_init), the user demand is associated with the second field, wherein the execution order of the first field in the startup script is before the third field corresponding to the quick start application, and the second field is after the third field. In this way, after running the adjusted startup script, the staged driver initialization operation can be executed in the execution order of the first field->third field->second field.

[0072] In some embodiments, the second stage driver class includes multiple second drivers, and different second drivers correspond to different user needs. Figure 1 Step S40 shown includes but is not limited to the following steps:

[0073] Step S41, running the first field in the startup script to initialize the first driver;

[0074] Step S42, running the third field, running the quick start application;

[0075] Step S43 , when a reference user requirement is received from the quick start application, the second field is executed, the second driver corresponding to the user requirement corresponding to the reference user requirement is determined as a target driver, and the target driver is initialized.

[0076] Specifically, since the second driver of this embodiment is associated with user demand, the second driver can be executed as needed after the quick start application is run and is triggered by the user.

[0077] Specifically, the number and specific types of the first drive and the second drive of this embodiment are determined according to actual conditions and are not limited here.

[0078] It is understandable that, referring to the description of the above embodiment, the staged driver initialization steps include: running the first field in the startup script to initialize the first driver, running the third field to run the quick-start application, and in the case where the driver class in the second stage includes multiple second drivers, upon receiving a reference user demand from running the quick-start application, running the second field, determining the second driver corresponding to the user demand corresponding to the reference user demand as the target driver, and initializing the target driver. This can optimize the startup speed of the Linux system's quick-start application, avoid non-critical drivers blocking the quick-start application, and after starting the quick-start application, can dynamically adapt to the scenario and initialize the driver on demand, saving memory and CPU.

[0079] In addition, this embodiment also accelerates the system startup speed by increasing the drive operating frequency of the storage module, such as increasing the SPI frequency, and reducing the kernel console log output level (for example, reducing the kernel loglevel to 4).

[0080] like Figure 2 As shown, Figure 2 : is a structural diagram of a control device provided in one embodiment of the present application. The present invention also provides a control device 200, comprising:

[0081] The processor 210 may be implemented as a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is configured to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0082] The memory 220 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 220 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 220, and the processor 210 calls and executes the program fast startup method of the Linux system in the embodiments of this application;

[0083] Input / output interface 230, used to implement information input and output;

[0084] Communication interface 240, used to implement communication interaction between the apparatus and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0085] bus 250 , which transmits information between the various components of the device (e.g., processor 210 , memory 220 , input / output interface 230 , and communication interface 240 );

[0086] The processor 210 , the memory 220 , the input / output interface 230 and the communication interface 240 are connected to each other in communication within the device via the bus 250 .

[0087] In addition, an embodiment of the present application further provides an electronic device, including the control device 200 of the above embodiment.

[0088] In addition, an embodiment of the present application further provides a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is executed by a processor, the computer program implements the above-mentioned method for quickly starting a program in the Linux system.

[0089] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory optionally includes a memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of the above-mentioned networks include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof. The device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and are located in one place, or may be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment.

[0090] Those skilled in the art will appreciate that all or some of the steps and systems in the method disclosed above can be implemented as software, firmware, hardware, and appropriate combinations thereof. Some physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, and the computer-readable medium can include computer storage media (or non-transitory media) and communication media (or temporary media). As known to those skilled in the art, the term computer storage media is included in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data) and is volatile and non-volatile, removable, and non-removable. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disks (DVD), or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage, or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0091] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above implementation. Those skilled in the art can also make various equivalent modifications or substitutions under the shared conditions that do not violate the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A method for quickly starting a program in a Linux system, characterized in that: A control chip applied to a Linux system, the control chip including a CROM memory, an SRAM memory, a SoC chip, and a DRAM memory, the control chip being communicatively connected to a storage module, the storage module belonging to the Linux system, the method comprising: When the control chip is powered on, the chip curing program in the CROM memory is run to load the SPL program into the SRAM memory; Run the SPL program in the SRAM memory to initialize the SoC chip and the DRAM memory, read a binary file from the storage module, and load the binary file into the DRAM memory; Decompressing the binary file in the DRAM memory to obtain a quick start application and kernel code corresponding to the Linux system, and performing kernel initialization based on the kernel code; All drivers loaded into the DRAM memory are divided into a first driver and a second driver, the first driver is initialized, the quick start application is run, and the second driver is initialized, wherein the first driver is a necessary driver before the quick start application is run, and the second driver is the remaining driver among all the drivers except the first driver.

2. The method for quickly starting a program in a Linux system according to claim 1, wherein: The binary file includes a dtb file, the dtb file is associated with a device tree, and the binary file is read from the storage module and loaded into the dram memory, including: Determine a first device node and a second device node from the device tree, wherein the first device node is a device node with no reference in the device tree, and the second device node is a device node in the device tree that is currently unavailable; The first device node and the second device node in the device tree are deleted.

3. The method for quickly starting a program in a Linux system according to claim 2, wherein: The binary file includes a kernel compressed file, and the kernel compressed file corresponds to a first source file. Before reading the binary file from the storage module, the method further includes: Tailoring a first function file from the first source file, wherein the first function file is a function file in the first source file other than the function file that meets the basic requirements of the Linux system; determining a first target compression algorithm from a plurality of candidate compression algorithms based on a first loading duration and a first compression duration of the cropped first source file; The cropped first source file is compressed based on the first target compression algorithm to obtain the kernel compressed file.

4. The method for quickly starting a program in a Linux system according to claim 1, wherein: The binary file includes a ramfs compressed file, and the ramfs compressed file corresponds to a second source file. Before reading the binary file from the storage module, the method further includes: trimming the dynamic libraries other than the shared libraries associated with the C library in the second source file, and removing the executable program symbol information corresponding to the quick-start application in the second source file; Adjusting the quick start application to be a static link; Determining a second target compression algorithm from a plurality of candidate compression algorithms based on a second loading duration and a second compression duration of the cropped second source file; The cropped second source file is compressed based on the second target compression algorithm to obtain the ramfs compressed file.

5. The method for quickly starting a program in a Linux system according to claim 4, wherein: Before reading the binary file from the storage module and loading the binary file into the DRAM memory, the method further includes: Determining the quick start application and all dependencies associated with the quick start application from the storage module; All the dependencies and the quick start application are packaged and compressed into the ramfs compressed file.

6. The method for quickly starting a program in a Linux system according to claim 1, wherein: Before initializing the first driver, running the quick start application, and initializing the second driver, the method further includes: Encapsulate the first driver into the first-stage driver class, and encapsulate the second driver into the second-stage driver class; By compiling the first-stage driver class into the first field, compiling the second-stage driver class into the second field, and associating user requirements with the second field, the startup script is adjusted, wherein the execution order of the first field in the startup script is before the third field corresponding to the quick-start application, and the second field is after the third field.

7. The method for quickly starting a program in a Linux system according to claim 6, wherein: The second-stage driver class includes a plurality of second drivers, and different second drivers correspond to different user needs. Initializing the first driver, running the quick start application, and initializing the second driver include: Run the first field in the startup script to initialize the first driver; Run the third field to run the quick start application; When a reference user requirement for running the quick start application is received, the second field is run, a second driver corresponding to the user requirement corresponding to the reference user requirement is determined as a target driver, and the target driver is initialized.

8. A control device, characterized in that: The method comprises at least one control processor and a memory for communicating with the at least one control processor; the memory stores instructions executable by the at least one control processor, and the instructions are executed by the at least one control processor to enable the at least one control processor to execute the program rapid startup method for a Linux system as described in any one of claims 1 to 7.

9. An electronic device, characterized in that: Comprising the control device according to claim 8.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method for quickly starting a program in a Linux system according to any one of claims 1 to 7.

Images