Implementation method and device of kernel mirror image unification, electronic equipment and storage medium

Abstract

The invention discloses a kernel mirror image unification implementation method and device, electronic equipment and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: determining kernel source codes and a cross compilation tool used by a plurality of target chips with unified kernel mirror images; setting modification modes and storage paths of public configuration items of all the target chips and modification modes and storage paths of private configuration items of all the target chips; determining the minimum system function supported by all the target chips, and cutting and configuring the kernel source code according to the minimum system function and the actual demand of each target chip to obtain a first kernel; configuring a device tree corresponding to each target chip according to a kernel device tree configuration design requirement; based on the code design requirements, kernel codes of the first kernel are processed, and a second kernel is obtained; and generating a kernel mirror image file based on the second kernel and the device tree of each target chip. Unification of kernel mirror images is realized, and applicability of the kernel mirror images is improved.

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and in particular, relates to a method, device, electronic device and storage medium for implementing kernel image unification. Background Art

[0002] Currently, kernel development needs to be customized and maintained according to the specific chip architecture and hardware platform used. Even under the same chip architecture, chip models from different chip manufacturers have different characteristics and optimization requirements. This customized kernel development method will lead to inconsistency in image files, increasing the workload of kernel development and maintenance. Summary of the invention

[0003] The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes a kernel image unification implementation method, device, electronic device and storage medium, which realizes the unification of kernel images and improves the applicability of kernel image construction.

[0004] In a first aspect, the present application provides a method for implementing kernel image unification, the method comprising:

[0005] Determine the unified baseline kernel source code and cross-compilation tools needed to be used by multiple target chips that are included in the kernel image;

[0006] Setting a modification mode and storage path of the public configuration items of all the target chips, and a modification mode and storage path of the private configuration items of each target chip;

[0007] Determine the minimum system function supported by all the target chips, and cut and configure the kernel source code according to the minimum system function and the actual requirements of each target chip to obtain a first kernel;

[0008] According to the unified kernel device tree configuration design requirements, the device tree corresponding to each of the target chips is configured;

[0009] Based on the unified code design requirements, the kernel code of the first kernel is processed to obtain a second kernel;

[0010] A kernel image file is generated based on the second kernel and the device tree of each of the target chips.

[0011] In the above technical solution, a unified baseline kernel source code and cross-compilation tool are determined, and the modification and storage methods of public and private configuration items are set to meet the needs of each target chip. The kernel source code is cut and configured according to the minimum system functions supported by all target chips and the actual needs of each target chip to generate the first kernel. According to the unified device tree configuration design requirements, the corresponding device tree is configured for each target chip, and based on the unified code design requirements, the first kernel code is processed to form the second kernel. Finally, the second kernel is combined with the device tree of each target chip to generate a unified kernel image suitable for all target chips, which realizes the unification of the kernel image and improves the applicability of the kernel image.

[0012] According to an embodiment of the present application, the first kernel is obtained by cutting and configuring the kernel source code according to the minimum system function and the actual requirements of each target chip, including:

[0013] According to the minimum system function, cutting the common configuration items of the kernel source code;

[0014] According to the actual requirements of each of the target chips, the private configuration items to be included in the kernel are configured;

[0015] According to the minimum system function, the hardware driver in the kernel source code is trimmed;

[0016] According to the actual requirements of each target chip, the hardware driver corresponding to each target chip is configured.

[0017] In the above technical solution, non-essential public configuration items and hardware drivers in the kernel source code are trimmed to match the minimum system functions, and corresponding private configuration items and drivers are configured to meet the actual needs of each target chip. This not only effectively reduces the kernel size and improves the kernel operation efficiency, but also enhances the portability and maintainability of the kernel, providing support for the unified implementation of kernel images.

[0018] According to an embodiment of the present application, configuring the device tree corresponding to each target chip according to the unified kernel device tree configuration design requirements includes:

[0019] Configure the public driver device tree;

[0020] According to the model of each target chip, a private driver device tree is configured;

[0021] The configuration of the private driver device tree is achieved by adding a compatible keyword.

[0022] In the above technical solution, the public driver device tree is first configured so that the public driver can be initialized and run normally on all target chips. The private driver device tree is customized according to the model of each target chip. In particular, the hardware compatibility and driver matching relationship are clearly specified by adding the compatible keyword, which improves the flexibility and scalability of the device tree, enhances the kernel's adaptability to different hardware platforms, and provides support for the unified implementation of kernel images.

[0023] According to an embodiment of the present application, the step of processing the kernel code of the first kernel based on the unified code design requirement to obtain the second kernel includes:

[0024] Modifying the common code of the first kernel using the native API function of the kernel source code;

[0025] The private code of the first kernel is modified according to the unified private code design requirements and the specific needs of each of the target chips.

[0026] In the above technical solution, the public code of the first kernel is modified by utilizing the native API function of the kernel source code, and at the same time, the unified private code design requirements are followed, and the private code is customized and modified according to the specific needs of each target chip, so as to optimize the second kernel, improve the consistency and maintainability of the kernel code, and then improve the adaptability and flexibility of the kernel, while reducing the difficulty of subsequent maintenance.

[0027] According to one embodiment of the present application, the method further includes:

[0028] Parse the kernel image file to obtain the kernel address and the corresponding device tree address;

[0029] The kernel is started according to the kernel address and the corresponding device tree address; or, when the default address of the kernel image file cannot meet the requirements of the target chip, the default address is modified using the value of the environment variable of the target chip, and then the kernel is started.

[0030] In the above technical solution, the addresses of the kernel and device tree are obtained by parsing the kernel image file, and the kernel is started using these addresses. If the default addresses do not meet the specific requirements of the target chip, the values ​​of the target chip environment variables are used to modify these addresses so that the kernel can start and run at the correct memory location, thereby improving the compatibility of the kernel image with different hardware platforms.

[0031] According to one embodiment of the present application, the kernel image file provides a watchdog interface and the target chip has a watchdog circuit, and the method further includes:

[0032] In the process of starting the kernel operation, manual dog feeding is adopted before the driver program of the watchdog timer is started, and automatic dog feeding is performed by starting the driver program of the watchdog timer.

[0033] In the above technical solution, the kernel image file provides a dog feeding interface and the target chip has a watchdog circuit. Before starting the kernel and loading the watchdog timer driver, a manual dog feeding method is adopted. After the watchdog timer driver is started, it automatically takes over the dog feeding task, reducing the risk of kernel restart caused by the triggering of the watchdog timer and improving the stability of the kernel operation.

[0034] In a second aspect, the present application provides a device for implementing kernel image unification, the device comprising:

[0035] A determination unit, used for determining a unified baseline kernel source code and a cross-compilation tool required to be used by multiple target chips included in the unified kernel image;

[0036] A setting unit, used to set a modification mode and storage path of the common configuration items of all the target chips, and a modification mode and storage path of the private configuration items of each target chip;

[0037] A kernel cutting and configuration unit, used for determining the minimum system function supported by all the target chips, cutting and configuring the kernel source code according to the minimum system function and the actual requirements of each target chip, to obtain a first kernel;

[0038] A device tree configuration unit, configured to configure the device tree corresponding to each of the target chips according to a unified kernel device tree configuration design requirement;

[0039] A code processing unit, configured to process the kernel code of the first kernel based on a unified code design requirement to obtain a second kernel;

[0040] A generating unit is used to generate a kernel image file based on the second kernel and the device tree of each of the target chips.

[0041] In the above technical scheme, the implementation device of the kernel image unification determines the unified baseline kernel source code and cross-compilation tool, and meets the needs of each target chip by setting the modification and storage method of public and private configuration items, and cuts and configures the kernel source code according to the minimum system functions supported by all target chips and the actual needs of each target chip to generate the first kernel. According to the unified device tree configuration design requirements, the corresponding device tree is configured for each target chip, and the first kernel code is processed based on the unified code design requirements to form the second kernel. Finally, the second kernel is combined with the device tree of each target chip to generate a unified kernel image suitable for all target chips, which realizes the unification of the kernel image and improves the applicability of the kernel image.

[0042] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method for implementing kernel image unification as described in the first aspect above is implemented.

[0043] In a fourth aspect, the present application provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the method for implementing kernel image unification as described in the first aspect above is implemented.

[0044] In a fifth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the method for unifying the kernel image as described in the first aspect above.

[0045] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0047] Figure 1 It is a flowchart of a method for implementing a unified kernel image provided by an embodiment of the present application;

[0048] Figure 2 This is a schematic diagram of the manual dog feeding process provided by an embodiment of the present application;

[0049] Figure 3 This is a schematic diagram of the automatic dog feeding process provided by an embodiment of the present application;

[0050] Figure 4 It is a structural diagram of a device for implementing a unified kernel image provided by an embodiment of the present application;

[0051] Figure 5 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0052] Description of reference numerals:

[0053] 400: a device for implementing a unified kernel image;

[0054] 401: determination unit; 402: setting unit; 403: kernel trimming and configuration unit;

[0055] 404: device tree configuration unit; 405: code processing unit; 406: generation unit;

[0056] 500: electronic equipment;

[0057] 501: processor; 502: memory. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of this application.

[0059] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0060] In conjunction with the accompanying drawings, the following detailed description is given of the kernel image unification implementation method, device, electronic device and storage medium provided by the embodiments of the present application through specific embodiments and their application scenarios.

[0061] The implementation method of kernel image unification provided in the embodiment of the present application may be executed by an electronic device or a functional module or functional entity in the electronic device that can implement the implementation method of kernel image unification. The electronic devices mentioned in the embodiment of the present application include but are not limited to mobile phones, tablet computers, computers, cameras, and wearable devices. The implementation method of kernel image unification provided in the embodiment of the present application is described below using an electronic device as an example of the execution subject.

[0062] Figure 1 1 is a flowchart of a method for implementing a unified kernel image provided by an embodiment of the present application. Figure 1 As shown, the implementation method of the kernel image unification includes: step 110, step 120, step 130, step 140, step 150 and step 160.

[0063] Step 110: Determine the unified baseline kernel source code and cross-compilation tools required for multiple target chips included in the unified kernel image.

[0064] Baseline refers to the state or version of a project or system at a specific point in its life cycle. A baseline is a starting point or reference point for further development or changes. It represents a collection of files, codes, configurations, or data that have been reviewed and approved and are considered stable and meet specific requirements at a certain point in time.

[0065] The unified baseline kernel source code is a set of kernel source code for a specific version of a general operating system. It contains basic drivers and functions that support multiple hardware platforms. Kernel image unification is achieved based on this kernel source code, providing a basis for the consistency and maintainability of kernel images.

[0066] Cross-compilation tools are a set of software tools, including compilers, assemblers, linkers, etc., which can compile code in one computer environment to run in another computer environment. Since the target chip usually does not have enough resources to directly compile the kernel or application, a cross-compilation tool is needed to compile code suitable for the target chip on the development host.

[0067] In some embodiments, kernel 5.10 is selected as the kernel source code of the unified baseline, and gcc-linaro-11.3.1 is selected as the cross-compilation tool.

[0068] Step 120: Setting the modification mode and storage path of the public configuration items of all the target chips, and the modification mode and storage path of the private configuration items of each target chip.

[0069] Common configuration items are a set of configuration information that are shared by multiple target chips and are used to define basic and common operating parameters.

[0070] The private configuration items are configuration information specific to each target chip. These configuration information are only valid for each target chip and are used to define its private operating parameters.

[0071] By setting the modification method and storage path, unified management of configuration items under a specific path is achieved. On the one hand, unified management of configuration items makes it easier to maintain and reuse configuration items of target chip configuration items. On the other hand, separating public configuration items from private configuration items separates the common functions of the kernel from the customized functions of specific target chips, improving the readability and manageability of the code.

[0072] In some embodiments, all target chip public configuration items are uniformly stored in the arch / arm64 / configs / defconfig path. After the public configuration items are modified through menuconfig, the following command needs to be used to save the changes when submitting:

[0073] make ARCH=arm64 savedefconfig

[0074] cp.config arch / arm64 / configs / defconfig

[0075] The private configuration items of each target chip are stored in the arch / arm64 / configs / directory and named in the format of "chip model.config" to distinguish public and private configurations. The naming rule of each configuration option in "chip model.config" is set to: "CONFIG_chip model_function name".

[0076] Step 130: determine the minimum system function supported by all the target chips, and cut and configure the kernel source code according to the minimum system function and the actual requirements of each target chip to obtain a first kernel.

[0077] Minimum system functions refer to the basic function set required for the operation of an operating system or embedded system, which may include system startup, memory management, basic process scheduling, device driver support, etc. These functions form the basis for the stable operation of the system. Customization or function expansion is carried out based on the minimum system functions and the actual requirements of each target chip to meet the needs of a specific hardware platform.

[0078] The actual requirements of each target chip refer to the kernel function set and configuration required by each target chip according to its specific application scenario, performance requirements, resource constraints (such as memory size, processor speed, peripheral interface, etc.) or customized functional requirements. These requirements determine how to retain, remove or modify when cutting and configuring on the basis of a unified kernel source code to generate a first kernel that meets the minimum system function requirements and adapts to the characteristics of each target chip.

[0079] Step 140: Configure the device tree corresponding to each target chip according to the unified kernel device tree configuration design requirements.

[0080] Device Tree is a data structure used to describe the composition and configuration of hardware, so that the operating system kernel (such as Linux) can understand and manage hardware devices.

[0081] The device tree corresponding to each target chip is configured according to the unified kernel device tree configuration design requirements, that is, different target chips generate device tree source files (Device Tree Source, DTS) based on standardized templates, so that the kernel can identify and initialize the hardware resources of each target chip, improve the kernel's hardware device compatibility, and simplify the development process.

[0082] Step 150: Based on the unified code design requirement, the kernel code of the first kernel is processed to obtain a second kernel.

[0083] Based on the unified code design requirements, the kernel code of the first kernel is processed. The processing here may include code review, refactoring, modularization, removal of unnecessary features or components, addition of new functions or driver support, etc. After the processing is completed, a second kernel that meets the code design requirements and meets the actual needs of each target chip is obtained, thereby improving the stability and compatibility of the kernel.

[0084] Step 160: Generate a kernel image file based on the second kernel and the device tree corresponding to each of the target chips.

[0085] The uniformly configured and customized kernel code (ie, the second kernel) is combined with the device tree configuration information corresponding to each target chip, and packaged to generate a kernel image file that can be run on the target chip.

[0086] Optionally, the kernel image file selects the kernel and the device tree associated with it and packages it using the Firmware Image Format (FIT) format. The feature of FIT is that it supports specifying any custom information and packaging any number of image files. FIT uses an image source file (ISF) to describe the image information to be packaged, and then uses mkimage to package and generate an image tree blob (ITB) image, where the ITB file uses the syntax rules of the device tree source file (DTS) and is directly parsed using the libfdt library and related tools. In the ITB file, FDT blob is the firmware header of the ITB, which is used to describe the information of each image; image0...imageN are the image files packaged in.

[0087] In the above technical solution, a unified baseline kernel source code and cross-compilation tool are determined, and the modification and storage methods of public and private configuration items are set to meet the needs of each target chip. The kernel source code is cut and configured according to the minimum system functions supported by all target chips and the actual needs of each target chip to generate the first kernel. According to the unified device tree configuration design requirements, the corresponding device tree is configured for each target chip, and based on the unified code design requirements, the first kernel code is processed to form the second kernel. Finally, the second kernel is combined with the device tree of each target chip to generate a unified kernel image suitable for all target chips, which realizes the unification of the kernel image and improves the applicability of the kernel image.

[0088] In one embodiment of the present application, the first kernel is obtained by cutting and configuring the kernel source code according to the minimum system function and the actual requirements of each target chip, including:

[0089] According to the minimum system function, cutting the common configuration items of the kernel source code;

[0090] According to the actual requirements of each of the target chips, the private configuration items to be included in the kernel are configured;

[0091] The hardware driver in the kernel source code is trimmed according to the minimum system function.

[0092] According to the actual requirements of each target chip, the hardware driver corresponding to each target chip is configured. It is understandable that the minimum system functions that all target chips need to support are analyzed and determined, such as process scheduling, memory management, interrupt processing, etc. Then, based on the minimum system functions, the common configuration items in the kernel source code are carefully reviewed, and the parts that do not belong to the minimum system function set are removed or disabled. This step reduces the size and complexity of the kernel on the basis that the kernel can meet the basic operating requirements of all target chips.

[0093] It is understandable that each target chip has its own private hardware configuration and peripheral requirements, so the kernel needs to configure corresponding private configuration items for them, which may include processor characteristics, memory layout, peripheral driver support, etc. In this step, it is necessary to analyze the specific requirements of each target chip in detail and add or modify the corresponding private configuration items in the kernel source code to ensure that the kernel can correctly identify and manage these hardware resources.

[0094] In the specific implementation, first, based on the requirements of the minimum system functions, the hardware drivers included in the kernel source code are reviewed and trimmed, and the hardware drivers that are not necessary for the minimum system functions are removed, thereby reducing the size of the kernel. For example, if a hardware device is not used on all target chips, the corresponding driver can be removed from the kernel. Then, according to the specific needs of each target chip, the corresponding hardware driver is selected and configured. This may include enabling specific driver options, adjusting driver parameters, or adding additional kernel support for certain special hardware functions. This step enables the kernel to include all the drivers required to run on specific hardware, improving the applicability of the kernel.

[0095] It should be noted that the size of the kernel needs to be considered when cutting and configuring based on the kernel source code. The maximum capacity of the kernel partition can be designed to be 64MB. To facilitate subsequent expansion, the current kernel size is agreed not to exceed 32MB; the current standard kernel size is about 9MB, and the private driver of each chip model in the kernel cannot exceed 3MB.

[0096] In some embodiments, the hardware driver in the kernel source code is tailored and configured according to the principle of "modularity first", that is, when designing and implementing the hardware driver, priority should be given to designing the driver as a loadable module rather than directly compiling it into the kernel.

[0097] Optionally, the hardware drivers are divided into mandatory drivers and optional drivers. The mandatory drivers are the hardware drivers required for kernel startup and basic operation, such as processor support, memory management, basic input and output system (BIOS), etc. The optional drivers are drivers for specific hardware or optional functions, such as drivers for certain peripherals or modules for specific functions. Among them, the optional drivers are cut and configured according to the principle of "modularization first", and the mandatory drivers need to be cut and configured according to the overall requirements of driver design. The overall requirements of driver design are shown in Table 1.

[0098] Table 1 Overall requirements for driver design

[0099]

[0100] In the above technical solution, non-essential public configuration items and hardware drivers in the kernel source code are trimmed to match the minimum system functions, and corresponding private configuration items and drivers are configured to meet the actual needs of each target chip. This not only effectively reduces the kernel size and improves the kernel operation efficiency, but also enhances the portability and maintainability of the kernel, providing support for the unified implementation of kernel images.

[0101] In one embodiment of the present application, configuring the device tree corresponding to each target chip according to the unified kernel device tree configuration design requirements includes:

[0102] Configure the public driver device tree;

[0103] According to the model of each target chip, a private driver device tree is configured;

[0104] The configuration of the private driver device tree is achieved by adding a compatible keyword.

[0105] Device Tree is a data structure used to describe hardware device information in the form of a text file. According to the unified kernel device tree configuration design requirements, the kernel can be initialized and device drivers loaded in a unified way on different hardware platforms.

[0106] Public drivers refer to hardware drivers that are suitable for multiple target chips. The public driver device tree contains the nodes and properties required by these drivers so that they can be initialized and run normally on all target chips.

[0107] A private driver is a driver program specific to a target chip and may need to access hardware features unique to a specific chip. For each target chip, you need to add or modify the corresponding node in the private driver device tree to include the specific configuration information required by the private driver. The compatible keyword is used in the device tree to specify the compatibility information of a device or node. By adding the compatible attribute to the private driver node in the device tree, you can specify which hardware platforms or specific chip models the node is compatible with.

[0108] In one embodiment, the General Purpose Input Output (GPIO) device tree is configured as follows:

[0109] gpio:

[0110] reg = <0xxxx>;

[0111] compatible="scm901,smchip-gpio";

[0112] status="disabled";

[0113] }

[0114] Among them, reg is the data register of gpio; compatible represents the compatibility attribute, which is used to bind the device and the driver; status is the device status attribute. "scm901,smchip-gpio" indicates that the GPIO controller is compatible with the "smchip" series GPIO device of the "scm901" model.

[0115] In the above technical solution, the public driver device tree is first configured so that the public driver can be initialized and run normally on all target chips. The private driver device tree is customized according to the model of each target chip. In particular, the hardware compatibility and driver matching relationship are clearly specified by adding the compatible keyword, which improves the flexibility and scalability of the device tree, enhances the kernel's adaptability to different hardware platforms, and provides support for the unified implementation of kernel images.

[0116] In one embodiment of the present application, the step of processing the kernel code of the first kernel based on the unified code design requirement to obtain the second kernel includes:

[0117] Modifying the common code of the first kernel using the native API function of the kernel source code;

[0118] The private code of the first kernel is modified according to the unified private code design requirements and the specific needs of each of the target chips.

[0119] In the process of optimizing the first kernel based on the unified code design requirements, the common code is modified using the native API function of the kernel source code, that is, the common code of the kernel is enhanced or adjusted through the interface and function provided by the kernel. The API function is an abstraction layer provided by the kernel, hiding the specific implementation details of the underlying hardware and the kernel, so that the upper-layer application or system can run more easily on different platforms and versions. In this way, the portability and maintainability of the kernel can be enhanced.

[0120] The kernel's private code is modified according to unified private code design requirements. These requirements may include coding standards, module division, interface definition, security standards, etc., which will help improve the readability, maintainability and scalability of the modified private code, thereby enhancing the portability and maintainability of the kernel.

[0121] In some embodiments, for the modification of public code of the kernel source code, customized changes are made by utilizing the kernel's native API of_machine_is_compatible function, where of_machine_is_compatible is a function in the Linux kernel used to test whether the root node of the device tree matches a given compatible value (compatible), identify and handle compatibility issues between different chips, and thus reduce the impact on other chip processes; for the addition and modification of private code of the kernel source code, the configuration of CONFIG_chip model_function name is used, and the submission information should follow the naming convention of "chip name: module name: description", such as "scm901:phy:add usb phy support" to clearly reflect the modified content and ownership.

[0122] In the above technical solution, the public code of the first kernel is modified by utilizing the native API function of the kernel source code, and at the same time, the unified private code design requirements are followed, and the private code is customized and modified according to the specific needs of each target chip, so as to optimize the second kernel, improve the consistency and maintainability of the kernel code, and then improve the adaptability and flexibility of the kernel, while reducing the difficulty of subsequent maintenance.

[0123] In one embodiment of the present application, the method further includes:

[0124] Parse the kernel image file to obtain the kernel address and the corresponding device tree address;

[0125] The kernel is started according to the kernel address and the corresponding device tree address; or, when the default address of the kernel image file cannot meet the requirements of the target chip, the default address is modified using the value of the environment variable of the target chip, and then the kernel is started.

[0126] It should be noted that the boot program (such as U-Boot) is responsible for parsing the kernel image file. During the parsing process, the boot program identifies and extracts the kernel entry address (i.e. kernel address) and the device tree address associated with it. The kernel loads itself into the memory of the target chip based on these addresses and uses the device tree information to initialize the hardware devices.

[0127] If the default addresses of the kernel image file do not meet the requirements of the target chip (for example, due to the memory layout or secure boot requirements of the hardware platform), these addresses need to be modified, which can be achieved by booting the environment variables of the target chip. The environment variables contain startup parameters and configuration options, that is, use environment variables to modify the loading addresses of the kernel and device tree, and then start the kernel.

[0128] In some embodiments, since the kernel image file (such as kernel.bin) is a file packaged in FIT format, this file cannot be changed after being signed by the regulatory department. If the default load and entry addresses in ITB cannot meet the requirements of the current platform, the values ​​of the environment variables kernel_addr_r, fdt_addr_r, and ramdk_addr_r are used to modify the corresponding addresses in ITB, and then the kernel is started.

[0129] In the above technical solution, the addresses of the kernel and device tree are obtained by parsing the kernel image file, and the kernel is started using these addresses. If the default addresses do not meet the specific requirements of the target chip, the values ​​of the target chip environment variables are used to modify these addresses so that the kernel can start and run at the correct memory location, thereby improving the compatibility of the kernel image with different hardware platforms.

[0130] In one embodiment of the present application, the kernel image file provides a watchdog interface and the target chip has a watchdog circuit, and the method further includes:

[0131] In the process of starting the kernel operation, manual dog feeding is adopted before the driver program of the watchdog timer is started, and automatic dog feeding is performed by starting the driver program of the watchdog timer.

[0132] The dog feeding interface is a communication mechanism between the kernel and the hardware watchdog circuit. Through the dog feeding interface, a signal is regularly sent to the watchdog circuit (i.e., the dog is fed) to indicate that the system kernel is running normally. If the watchdog circuit does not receive the dog feeding signal within the preset time, it will be considered that the kernel has no response and trigger a restart operation.

[0133] Before the watchdog timer driver is started, the manual dog feeding method is adopted. At this stage, the necessary drivers and services have not been loaded or initialized, so the automatic dog feeding mechanism cannot be relied on. After the watchdog timer driver is started, it will switch to the automatic dog feeding mode. At this time, the driver will take over the dog feeding task and send dog feeding signals to the watchdog circuit regularly according to the preset rules.

[0134] In some embodiments, the manual dog feeding stage and the automatic dog feeding stage are set as follows:

[0135] The first stage of manual feeding of dogs:

[0136] Figure 2 This is a schematic diagram of the manual dog feeding process provided by the embodiment of the present application. Figure 2 As shown in the figure, before starting the dog feeding timer, N manual dog feedings are inserted (with a flip every 300ms as the standard), where head.S is an assembly language source file, which usually contains the first few instructions executed when the kernel starts; dtb refers to the device tree binary file (Device TreeBlob), which stores hardware device information; wdt refers to the watchdog timer (Watchdog Timer), which is used to feed the dog at a predetermined time interval to ensure that the kernel continues to run.

[0137] The kernel provides a unified dog feeding interface to the outside world, and internally configures and operates GPIO according to the device tree source files of various manufacturers. The pseudo code is as follows:

[0138] (1) After the kernel parses the dtb, insert the logic of manually feeding the dog to obtain the configuration:

[0139] void start_kernel()

[0140] { ...

[0142] unflattern_device_tree(); / *Expand dts* /

[0143] wdt_config_get(); / *Get the wdt pin from dts for manual dog feeding* / ...

[0145] } ...

[0147] static u32 wdt_bit,wdt_pins;

[0148] static void__iomem*wdt_pins_base;

[0149] static bool manual_feed_dog=false;

[0150] void wdt_config_get();

[0151] {

[0152] struct device_node *np;

[0153] np=of_find_node_by_name(NULL,"wdt_pins"); ...

[0155] manual_feed_dog=of_property_read_bool(np,"reg");

[0156] of_property_read_u32(np,"reg",&wdt_pins);

[0157] of_property_read_u32(np,"bit",&wdt_bit);

[0158] wdt_pins_base=ioremap(wdt_pins,4); ...

[0160] }

[0161] (2) Provide a unified dog feeding interface to the outside world. If the device tree does not have manual dog feeding related configuration, the dog feeding operation will not be performed;

[0162] void feed_wdt()

[0163] {

[0164] if(manual_feed_dog==false)

[0165] return;

[0166] / *Feed the dog* /

[0167] }

[0168] Among them, the number of manual dog feeding and the specific time are set according to the actual scenario and application and added to the kernel initialization process.

[0169] The second stage of automatic dog feeding:

[0170] Figure 3 The following is a schematic diagram of the automatic dog feeding process provided by the embodiment of the present application. Figure 3 As shown, wdt_timer_init is the watchdog timer initialization function, which is used to complete the initialization of the watchdog timer; hrtimer refers to a high-resolution timer, which is used to periodically trigger the dog feeding operation; callback refers to a callback function called after the high-resolution timer expires.

[0171] (1) Set the timing period of the high-precision timer (hrtimer), the interval is defined as 300ms, and the life cycle is 3min;

[0172] (2) Access general purpose input and output (GPIO) pins through standard interfaces;

[0173] (3) Operate the gpio level flip in the hrtimer callback function;

[0174] (4) After 3 minutes, the kernel stops feeding the dog through the timer and provides a user-mode node, and the application takes over the feeding behavior;

[0175] The pseudo code is as follows:

[0176] struct gpiod wdt_gpiod;

[0177] static enum hrtimer_restart hrtimer_callback()

[0178] {

[0179] gpiod_set_value(level flip, wdt_gpiod);

[0180] return; / / Has it exceeded three minutes? Restart the timer: Stop the timer;

[0181] }

[0182] static int wdt_timer_init()

[0183] { ...

[0185] wdt_gpiod=devm_gpiod_get(); / *Get gpio* /

[0186] hrtimer->callback = hrtimer_callback; / *initialize hrtimer* /

[0187] hrtimer_init(300ms); ...

[0189] }

[0190] In the above technical solution, the kernel image file provides a dog feeding interface and the target chip has a watchdog circuit. Before starting the kernel and loading the watchdog timer driver, a manual dog feeding method is adopted. After the watchdog timer driver is started, it automatically takes over the dog feeding task, reducing the risk of kernel restart caused by the triggering of the watchdog timer and improving the stability of the kernel operation.

[0191] The implementation method of kernel image unification provided in the embodiment of the present application can be executed by a kernel image unification implementation device. In the embodiment of the present application, the kernel image unification implementation device executing the kernel image unification implementation method is taken as an example to illustrate the kernel image unification implementation device provided in the embodiment of the present application.

[0192] Figure 4 Schematic diagram of the structure of the implementation device of the kernel image unification provided by the embodiment of the present application. Figure 4 As shown, the kernel image unified implementation device 400 includes:

[0193] A determination unit 401 is used to determine a unified baseline kernel source code and a cross-compilation tool required to be used by multiple target chips that are included in the unified kernel image;

[0194] A setting unit 402, used to set a modification mode and storage path of the common configuration items of all the target chips, and a modification mode and storage path of the private configuration items of each target chip;

[0195] A kernel cutting and configuring unit 403 is used to determine the minimum system function supported by all the target chips, and cut and configure the kernel source code according to the minimum system function and the actual requirements of each target chip to obtain a first kernel;

[0196] The device tree configuration unit 404 is used to configure the device tree corresponding to each of the target chips according to the unified kernel device tree configuration design requirements;

[0197] A code processing unit 405, configured to process the kernel code of the first kernel based on a unified code design requirement to obtain a second kernel;

[0198] The generating unit 406 is configured to generate a kernel image file based on the second kernel and the device tree of each of the target chips.

[0199] Optionally, the kernel trimming and configuration unit 403 is used to:

[0200] According to the minimum system function, cutting the common configuration items of the kernel source code;

[0201] According to the actual requirements of each of the target chips, the private configuration items to be included in the kernel are configured;

[0202] According to the minimum system function, the hardware driver in the kernel source code is trimmed;

[0203] According to the actual requirements of each target chip, the hardware driver corresponding to each target chip is configured.

[0204] Optionally, the device tree configuration unit 404 is used to:

[0205] Configure the public driver device tree;

[0206] According to the model of each target chip, a private driver device tree is configured;

[0207] The configuration of the private driver device tree is achieved by adding a compatible keyword.

[0208] Optionally, the code processing unit 405 is used to:

[0209] Modifying the common code of the first kernel using the native API function of the kernel source code;

[0210] The private code of the first kernel is modified according to the unified private code design requirements and the specific needs of each of the target chips.

[0211] Optionally, the device further comprises:

[0212] A parsing unit, used for parsing the kernel image file to obtain a kernel address and a corresponding device tree address;

[0213] A startup unit is used to start the kernel operation according to the kernel address and the corresponding device tree address; or, when the default address of the kernel image file cannot meet the requirements of the target chip, start the kernel operation after modifying the default address using the value of the environment variable of the target chip.

[0214] Optionally, the kernel image file provides a watchdog interface and the target chip has a watchdog circuit, and the startup unit is further used for:

[0215] In the process of starting the kernel operation, manual dog feeding is adopted before the driver program of the watchdog timer is started, and automatic dog feeding is performed by starting the driver program of the watchdog timer.

[0216] In the above technical scheme, the implementation device of the kernel image unification determines the unified baseline kernel source code and cross-compilation tool, and meets the needs of each target chip by setting the modification and storage method of public and private configuration items, and cuts and configures the kernel source code according to the minimum system functions supported by all target chips and the actual needs of each target chip to generate the first kernel. According to the unified device tree configuration design requirements, the corresponding device tree is configured for each target chip, and the first kernel code is processed based on the unified code design requirements to form the second kernel. Finally, the second kernel is combined with the device tree of each target chip to generate a unified kernel image suitable for all target chips, which realizes the unification of the kernel image and improves the applicability of the kernel image.

[0217] The implementation device of the unified kernel image in the embodiment of the present application can be an electronic device, or a component in the electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal, or other devices other than the terminal. Exemplarily, the electronic device can be a mobile phone, a tablet computer, a laptop computer, a palmtop computer, a vehicle-mounted electronic device, a mobile Internet device (Mobile Internet Device, MID), an augmented reality (augmented reality, AR) / virtual reality (virtual reality, VR) device, a robot, a wearable device, an ultra-mobile personal computer (ultra-mobilepersonal computer, UMPC), a netbook or a personal digital assistant (personal digital assistant, PDA), etc., and can also be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (personal computer, PC), a television (television, TV), a teller machine or a self-service machine, etc., and the embodiment of the present application is not specifically limited.

[0218] The implementation device for the unified kernel image in the embodiment of the present application may be a device having an operating system. The operating system may be a Microsoft (Windows) operating system, an Android (Android) operating system, an IOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0219] The kernel image unification implementation device provided in the embodiment of the present application can implement each process implemented by the above-mentioned kernel image unification implementation method embodiment, and will not be described again here to avoid repetition.

[0220] In some embodiments, Figure 5 As shown, an embodiment of the present application also provides an electronic device 500, including a processor 501, a memory 502, and a computer program stored in the memory 502 and executable on the processor 501. When the program is executed by the processor 501, each process of the above-mentioned kernel image unified implementation method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0221] It should be noted that the electronic devices in the embodiments of the present application include the mobile electronic devices and non-mobile electronic devices mentioned above.

[0222] The embodiment of the present application also provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the various processes of the above-mentioned kernel image unification implementation method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0223] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0224] An embodiment of the present application also provides a computer program product, including a computer program, which implements the above-mentioned kernel image unification implementation method when executed by a processor.

[0225] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0226] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0227] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0228] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

[0229] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "illustrative embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0230] Although the embodiments of the present application have been shown and described, those skilled in the art will appreciate that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present application, and that the scope of the present application is defined by the claims and their equivalents.

Claims

1. A method for implementing kernel image unification, characterized in that: include: Determine the unified baseline kernel source code and cross-compilation tools needed to be used by multiple target chips that are included in the kernel image; Setting a modification mode and storage path of the public configuration items of all the target chips, and a modification mode and storage path of the private configuration items of each target chip; Determine the minimum system function supported by all the target chips, and cut and configure the kernel source code according to the minimum system function and the actual requirements of each target chip to obtain a first kernel; According to the unified kernel device tree configuration design requirements, the device tree corresponding to each of the target chips is configured; Based on the unified code design requirements, the kernel code of the first kernel is processed to obtain a second kernel; A kernel image file is generated based on the second kernel and the device tree of each of the target chips.

2. The method for realizing kernel image unification according to claim 1, characterized in that: The method of cutting and configuring the kernel source code according to the minimum system function and the actual requirements of each target chip to obtain a first kernel includes: According to the minimum system function, cutting the common configuration items of the kernel source code; According to the actual requirements of each of the target chips, the private configuration items to be included in the kernel are configured; According to the minimum system function, the hardware driver in the kernel source code is trimmed; According to the actual requirements of each target chip, the hardware driver corresponding to each target chip is configured.

3. The method for realizing kernel image unification according to claim 1, characterized in that: The configuring of the device tree corresponding to each target chip according to the unified kernel device tree configuration design requirements includes: Configure the public driver device tree; According to the model of each target chip, a private driver device tree is configured; The configuration of the private driver device tree is achieved by adding a compatible keyword.

4. The method for realizing kernel image unification according to claim 1, characterized in that: The step of processing the kernel code of the first kernel based on the unified code design requirement to obtain the second kernel includes: Modifying the common code of the first kernel using the native API function of the kernel source code; The private code of the first kernel is modified according to the unified private code design requirements and the specific needs of each of the target chips.

5. The method for realizing kernel image unification according to claim 1, characterized in that: The method further comprises: Parse the kernel image file to obtain the kernel address and the corresponding device tree address; The kernel is started according to the kernel address and the corresponding device tree address; or, when the default address of the kernel image file cannot meet the requirements of the target chip, the default address is modified using the value of the environment variable of the target chip, and then the kernel is started.

6. The method for realizing kernel image unification according to claim 5, characterized in that: The kernel image file provides a watchdog interface and the target chip has a watchdog circuit, and the method further includes: In the process of starting the kernel operation, manual dog feeding is adopted before the driver program of the watchdog timer is started, and automatic dog feeding is performed by starting the driver program of the watchdog timer.

7. A device for implementing kernel image unification, characterized in that: include: A determination unit, used for determining a unified baseline kernel source code and a cross-compilation tool required to be used by multiple target chips included in the unified kernel image; A setting unit, used to set a modification mode and storage path of the common configuration items of all the target chips, and a modification mode and storage path of the private configuration items of each target chip; A kernel cutting and configuration unit, used for determining the minimum system function supported by all the target chips, cutting and configuring the kernel source code according to the minimum system function and the actual requirements of each target chip, to obtain a first kernel; A device tree configuration unit, configured to configure the device tree corresponding to each of the target chips according to a unified kernel device tree configuration design requirement; A code processing unit, configured to process the kernel code of the first kernel based on a unified code design requirement to obtain a second kernel; A generating unit is used to generate a kernel image file based on the second kernel and the device tree of each of the target chips.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method for implementing kernel image unification as described in any one of claims 1 to 6 is implemented.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for implementing kernel image unification as described in any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method for implementing kernel image unification as described in any one of claims 1 to 6 is implemented.

Images