Linux system restart information recording method based on mtd equipment and related equipment

Abstract

The invention discloses a Linux system restart information recording method based on mtd equipment and related equipment.According to the scheme, on the basis of an existing mtcoop recording system oops information, recording of system restart information of each time can be achieved, and the information is reserved in an mtd flash medium which is not prone to losing in power failure; by adding corresponding character string marks, the cold and hot restart type of the system can be judged; meanwhile, an interface for an upper layer module is provided, and restarting reason types can be self-defined. Compared with other restart recording modes, the scheme is simple and convenient, recent detailed restart information of the equipment can be completely recorded, and great assistance is provided for field fault diagnosis.

Description

Technical Field

[0001] The invention relates to an embedded system development technology, and in particular to a method for recording restart information of an embedded system. Background Art

[0002] In the daily maintenance of embedded devices, accurately determining the restart cause and obtaining abnormal information are very important for fault diagnosis. Due to the space limitations of embedded system storage devices, the methods currently used on PC Linux (such as kdump, etc.) cannot be transplanted to embedded devices.

[0003] To this end, the existing solution also provides the use of high-end memory to record the restart information of embedded devices. However, this solution has the problem that the data will be lost when the power is off during use, and the CPU hot restart of some embedded devices will not save the high-end memory data, resulting in the inability to effectively record the restart information.

[0004] Currently, there is also a method of using mtd to record oops information, but it cannot support common restart information recording and cold and hot restart type judgment.

[0005] Therefore, how to effectively record the system restart information of the embedded device is a problem that needs to be solved urgently in this field. Summary of the invention

[0006] Glossary:

[0007] MTD device: MTD (Memory Technology Device) devices are a type of device used to manage and access flash memory, especially in embedded systems. MTD devices provide a unified interface for flash memory, allowing system software to read, write, and erase flash blocks.

[0008] mtdoops: Used in the Linux kernel to save kernel oops (kernel exception or crash information) to the MTD device when the system crashes. Its main purpose is to help developers analyze the cause of the crash after the system is restarted.

[0009] mtdoops can only save kernel oops information, but cannot record restart information, let alone determine system hot or cold restart information. It still has certain limitations for fault diagnosis.

[0010] Therefore, the purpose of the present invention is to provide a Linux system restart information recording method based on an mtd device, and to construct an output mode redirected to the mtd device based on the mtdoops mechanism. The output mode is configured to call the kmsg_dump function when the system oops, thereby saving the currently output oops information on the mtd device.

[0011] In some embodiments of the present invention, the method configures an interface file for the upper-level application based on the proc file system, and for the configured interface file, the upper-level application will write a preset type information in the configured interface file as restart information before restarting the device, so that the kernel can obtain this restart information before restarting.

[0012] In some embodiments of the present invention, the method adds restart type, time, and sequence number fields to the mtdoops header, stores the acquired restart information into the configured fields based on the fields configured in the mtdoops header, and stores it in the mtd device.

[0013] In some embodiments of the present invention, in the method, mtdoops is configured to enable corresponding functions on corresponding mtd devices according to the kernel startup parameter "mtdoops.mtddev"; and the maximum storage space for each record is determined according to the kernel startup parameter "mtdoops.record_size", thereby dividing the specified mtd partition into several "storage areas".

[0014] In some implementations of the present invention, when the Linux system is started in the method, it is determined whether the "storage area" is free based on the content in the "storage area", so as to select a suitable "storage area" as the "working area" during the kernel operation.

[0015] In some embodiments of the present invention, the method adds a preset string mark in the selected "working area" to accurately determine the cold or hot restart type of the system.

[0016] In some embodiments of the present invention, the method uses Nor Flash or Nand Flash as a storage medium; or uses an mtdram-compatible high-end memory medium as a storage medium.

[0017] On this basis, the present invention further provides a processor, which is used to run a program, wherein the program executes the steps of the above-mentioned Linux system restart information recording method when running.

[0018] The present invention further provides a terminal device, which includes a processor, a memory, and a program stored in the memory and executable on the processor, wherein the program code is loaded and executed by the processor to implement the steps of the above-mentioned Linux system restart information recording method.

[0019] The present invention further provides a computer program product, which, when executed on a data processing device, is suitable for executing the steps of the above-mentioned Linux system restart information recording method.

[0020] Compared with the existing restart recording mode, the Linux system restart information recording scheme provided by the present invention is simple and convenient, and can completely record the recent detailed restart information of the device. The relevant information is complete and will not be lost during power failure, which provides great assistance for on-site fault diagnosis.

[0021] The Linux system restart information recording scheme provided by the present invention can accurately determine the cold or hot restart type of the system by adding a special Magic Word, that is, it can distinguish between a cold restart and a hot restart; at the same time, it provides an interface to the upper-level module so that the upper-level application can customize the restart reason type.

[0022] The Linux system restart information recording solution provided by the present invention can still save the information on abnormal restart.

[0023] The Linux system restart information recording scheme provided by the present invention can operate normally once the reading, judgment and initialization of the mtd working area are completed when the kernel is started. This process can be completed within 1 second of the kernel starting. Therefore, it has high sensitivity and can correctly record short power-off restarts of seconds.

[0024] The Linux system restart information recording solution provided by the present invention is based on a Linux universal mtd device, can be quickly transplanted for different CPU architectures, and is easy to maintain. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments.

[0026] Figure 1 A flowchart for recording system restart information in an example of the present invention;

[0027] Figure 2 The result of viewing the system history restart information through Linux command in the example of the present invention;

[0028] Figure 3 This is the result of viewing the system historical abnormal restart information through Linux commands in an example of the present invention. DETAILED DESCRIPTION

[0029] In order to make the technical means, creative features, objectives and effects achieved by the present invention easy to understand, the present invention is further explained below with reference to specific diagrams.

[0030] Aiming at the problems existing in the acquisition and recording of device restart information of embedded devices running Linux system, the present invention provides an implementation scheme of recording Linux device restart information by using mtd device.

[0031] The implementation scheme of recording oops information by mtd is studied. When recording oops information by mtd, it is necessary to provide the panic_write interface of the storage device. At the same time, the general storage media are SPI-NOR or SPI-NAND devices. Correspondingly, the SPI interface of the Linux device will have kernel scheduling operations. If the kernel scheduling is executed in panic mode, new exceptions will be caused.

[0032] In this regard, the solution of the present invention is improved through the Linux kernel SPI implementation solution, some kernel scheduling waiting operations are modified to waiting operations in Panic mode, and the interrupt behavior in the SPI read and write operations of the corresponding driver is turned off and adjusted to a loop mode.

[0033] Based on this, the present invention forms a Linux system restart information recording method based on the mtd device. The recording method can record the system oops information based on mtdoops, and can also realize recording the information of each system restart, and retain the recorded information in the mtd flash medium which is not volatile when power is off.

[0034] Specifically, the scheme of the present invention is based on the operation mechanism of kmsg_dump, and registers and builds an output mode redirected to the mtd device through the mtdoops mechanism implementation scheme. Based on the output mode, when the system oops, the kmsg_dump function will be called to save the currently output oops information to the mtd device.

[0035] Furthermore, the solution of the present invention configures the mtdoops mechanism to support kmsg_dump in kernel_restart, thereby enabling the kernel_restart function of the kernel to be called to record the restart information for the normal restart behavior of Linux.

[0036] Furthermore, the solution of the present invention also configures an interface file that cooperates with the upper-layer application based on the proc file system, which is presented here in the form of a / proc / reset_reason file as a priority. Based on the configured interface, when the upper-layer application is about to restart the device, the upper-layer application will write a preset special type information in the configured interface file as the restart information, such as "AC Reboot", so that the kernel can obtain the restart information before restarting.

[0037] On this basis, the scheme of the present invention further configures the header of mtdoops, specifically, adds restart type, time, and sequence number fields to the header of mtdoops. Based on the fields configured in the mtdoops header, the obtained restart information can be stored in these configured fields and stored in the mtd device.

[0038] Furthermore, in the solution of the present invention, mtdoops is configured to enable the function on the corresponding mtd device (i.e., enable the mtdoops function) according to the kernel startup parameter "mtdoops.mtddev"; and the maximum storage space of each record is determined according to the kernel startup parameter "mtdoops.record_size", thereby dividing the mtd partition into several "storage areas". In this way, when the Linux system is started, it will determine whether it is free according to the content in the "storage area", and thus select a suitable "storage area" as the "working area" during the kernel operation.

[0039] On this basis, the solution of the present invention targets the selected "working area" and adds a special string mark therein, thereby accurately determining the cold or hot restart type of the system.

[0040] Specifically, the solution of the present invention is for the normal startup of a device running a Linux system. A fixed special string mark, such as "BD00BD00", is filled in a specific position of the selected "working area". When the kernel is started, the cold or hot restart type of the system is determined by checking whether there is a special string mark in the "working area". The "specific position" is not limited here, as long as it can cooperate with subsequent identification.

[0041] As a further explanation, the implementation process of the solution of the present invention to determine the type of hot or cold restart of the system is as follows:

[0042] When the device is hot-restarted or abnormally restarted, the kernel will record the restart information and some serial number information in the "working area". When the kernel restarts, it will decide which "storage area" is the "working area" based on these serial number information.

[0043] Based on the selected "work area", when the device running the Linux system starts, the configured special string mark will be written to a specific location in the "work area". On this basis, before the device is hot restarted, this special string mark will be cleared; while a cold restart is a direct restart, the kernel restart process will not be executed, so this special mark will not be cleared.

[0044] Based on this, when the kernel starts, if it is found that there is no marked string in the specified position in the "working area", it is judged as a hot restart, and then a new "working area" is selected and a special string mark is filled in; if a string mark exists, it means that the system has not executed the normal reboot process and it is a cold restart.

[0045] Based on the above scheme, the present invention can realize the customization of the restart reason type by forming an interface file that cooperates with the upper-layer application. As mentioned above, the Proc file system of the Linux kernel can be used to present it in the form of a file / proc / reset_reason. Before an application executes the reboot command, it writes specific content to / proc / reset_reason, and the kernel can know the current restart type.

[0046] In some implementations of the present invention, the storage medium of the mtd device in the solution of the present invention generally adopts NorFlash.

[0047] As an alternative, Nand Flash can also be used as a storage medium. Nand Flash has a larger capacity and lower cost, but due to its physical characteristics, its erase and write life is much lower than that of Nor Flash. More restarts will result in more erase and write times, which may cause chip damage.

[0048] As an alternative, you can also use mtdram technology to be compatible with high-end memory media. The memory read speed is fast, and there is no need to modify the kernel's SPI code, but some CPUs cannot save memory contents regardless of hot or cold restarts, so there are some limitations.

[0049] In some embodiments of the present invention, the solution of the present invention is further configured to specify which mtd device to enable the mtdoops function on by using the kernel startup parameter "mtdoops.mtddev", and if "mtdoops.record_size" is not set, the default size of each record is 4096 bytes. On this basis, in order to improve the efficiency of reading a large amount of information from the Flash device, the number of record entries is preferably set to 32, so this mtd partition needs to be set to 128KB.

[0050] Furthermore, the solution of the present invention can also be configured to flexibly modify the size of a single record and the maximum number of record entries by modifying the size of "mtdoops.record_size" and adjusting the size of the corresponding mtd partition according to the size of the mtd device and the amount of abnormal information of different CPU architectures.

[0051] In some embodiments of the present invention, the present invention adds fields to the software structure (i.e., adds restart type, time, and sequence number fields to the header of mtdoops), and the current time and sequence number of the device are recorded before restarting. Therefore, the recorded restart information, except for power-off restart, has an accurate restart time for all restart types; on this basis, each restart information is configured with an incremental number, for example, it can be numbered in sequence according to time, so that each restart information can be sorted and displayed.

[0052] The Linux system restart information recording method based on the mtd device formed based on the above scheme can completely record the recent detailed restart information of the device. Even if the information of abnormal restart can still be saved, it will not be lost in case of power failure.

[0053] The solution provided by the present invention is further described below through corresponding examples.

[0054] In this example, the Linux system restart information recording scheme provided by the present invention is configured in the device running the Linux system. On this basis, the relevant devices run normally.

[0055] See also Figure 1 , which shows an implementation flow chart of recording system restart information during the operation of a device running a Linux system configured with the solution of the present invention.

[0056] As can be seen from the figure, in this example, when recording system restart information based on the Linux system restart information recording solution provided by the present invention, a special string mark will be added to accurately determine the cold or hot restart type of the system.

[0057] First, when the device running the Linux system starts normally, after selecting the "working area", fill in the preset special string mark, such as "BD00BD00", in the specific location inside.

[0058] When the device is hot-restarted or abnormally restarted, the kernel will record the restart information and some serial number information in the "working area". When the kernel restarts, it can decide which storage area is the "working area" based on the serial number information.

[0059] When the device starts, a special string tag will be written to a specific location in the working area. Before the device is hot restarted, this special string tag will be cleared. A cold restart is a direct restart without executing the kernel restart process, so this special tag will not be cleared.

[0060] Therefore, when the kernel starts, if it is found that there is no mark string in the specified position in the "working area", it is judged as a hot restart, and then a new working area is selected and a special string mark is filled in; if a string mark exists, it means that the system has not executed the normal reboot process and it is a cold restart.

[0061] Furthermore, if the abnormal restart is caused by a Linux kernel crash, since the solution of the present invention is based on the expansion of the original mtdoops mechanism, it is still compatible with the original mechanism, so the original mtdoops mechanism will still work. Therefore, for the abnormal restart caused by the Linux kernel crash, the CPU register information, stack information, and abnormal call sequence information at the time of the abnormality are recorded in the working area based on the original mtdoops mechanism (see Figure 3 ), and the restart type is recorded as abnormal restart.

[0062] like Figure 3 As shown in the figure, when the kernel executes the wlan_operate_get_ht_bw function, because it accesses a non-existent instruction address, the kernel throws an exception and enters the exception process, outputting stack information, exception information, and exception function call sequence. Since the mtdoops function is enabled, these output information will also be redirected to the corresponding mtd partition and retained. After the system is restarted, you can view it through the corresponding command.

[0063] Furthermore, in this example, the reboot command is used to implement application execution reboot. As a further explanation, if the application is special, you can set the corresponding custom reboot type before calling reboot, such as "ACreboot", "Cloud reboot", etc., and these custom reboot types will be recorded. Otherwise, they will all be recorded as "Command" reboot (see Figure 2 ).

[0064] In the command line, you can easily view the related restart information by providing the show reset_reason and show break commands (see Figure 2 , Figure 3 ).

[0065] For Linux systems, except for power-off restart, all other restarts are hot restarts, and the kernel_restart function will be executed in the end. In this example, a global variable is defined to record the hot restart type. The default value of this variable is "Command". When the application calls the reboot command, you can customize a new restart reason through the proc file system interface provided by the kernel: / proc / reset_reason. For example, if the restart is issued by AC, you can write "AC reboot" to this file. Before executing the restart operation, the kernel will copy the value of this variable to the restart type field in the mtdoops software structure, and finally save it to the "working area" in the flash.

[0066] As further explanation, the present invention further provides the following implementation scheme.

[0067] An embodiment of the present invention further provides a processor, which is used to run a program, wherein the program executes the steps of the above-mentioned Linux system restart information recording method when running.

[0068] An embodiment of the present invention also provides a terminal device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. The program code is loaded and executed by the processor to implement the steps of the above-mentioned Linux system restart information recording method.

[0069] The present invention also provides a computer program product, which, when executed on a data processing device, is suitable for executing the steps of the above-mentioned Linux system restart information recording method.

[0070] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0071] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0072] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0073] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products of the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0074] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0075] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0076] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0077] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0078] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0079] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0080] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, systems or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0081] The above-mentioned method of the present invention, or a specific system unit, or a part of the same, is a pure software architecture, which can be arranged on a physical medium, such as a hard disk, an optical disk, or any electronic device (such as a smart phone, a computer-readable storage medium) through program code. When the machine loads the program code and executes it (such as a smart phone loading and executing it), the machine becomes a device for implementing the present invention. The above-mentioned method and device of the present invention can also be transmitted in the form of program code through some transmission media, such as cables, optical fibers, or any transmission mode. When the program code is received, loaded and executed by a machine (such as a smart phone), the machine becomes a device for implementing the present invention.

[0082] The above shows and describes the basic principles, main features and advantages of the present invention. It should be understood by those skilled in the art that the present invention is not limited to the above embodiments, and the above embodiments and descriptions are only for explaining the principles of the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention to be protected. The scope of protection of the present invention is defined by the attached claims and their equivalents.

Claims

1. A Linux system restart information recording method based on mtd equipment, characterized in that: An output mode redirecting to the mtd device is constructed based on the mtdoops mechanism. The output mode is configured such that when the system oops, the kmsg_dump function is called to save the currently output oops information to the mtd device.

2. The method for recording Linux system restart information based on mtd equipment according to claim 1, characterized in that: The method is based on the proc file system, configures an interface file for the upper-layer application, and for the configured interface file, the upper-layer application writes a preset type information in the configured interface file as restart information before restarting the device, so that the kernel can obtain the restart information before restarting.

3. The method for recording Linux system restart information based on mtd equipment according to claim 1, characterized in that: The method adds restart type, time and sequence number fields to the header of mtdoops, stores the acquired restart information into the configured fields based on the fields configured in the header of mtdoops, and stores the information in the mtd device.

4. The method for recording Linux system restart information based on mtd equipment according to claim 1, characterized in that: In the method, mtdoops is configured to enable corresponding functions on corresponding mtd devices according to kernel startup parameter "mtdoops.mtddev"; and to determine the maximum storage space of each record according to kernel startup parameter "mtdoops.record_size", thereby dividing the specified mtd partition into several "storage areas".

5. The method for recording Linux system restart information based on mtd equipment according to claim 1, characterized in that: In the method, when the Linux system is started, it is determined whether the "storage area" is idle based on the content in the "storage area", so as to select a suitable "storage area" as the "working area" during the kernel operation.

6. The method for recording Linux system restart information based on mtd equipment according to claim 5, characterized in that: In the method, a preset string mark is added to the selected "working area" to accurately determine the cold or hot restart type of the system.

7. The method for recording Linux system restart information based on mtd equipment according to claim 1, characterized in that: In the method, Nor Flash or Nand Flash is used as the storage medium; or a high-end memory medium compatible with mtdram is used as the storage medium.

8. A processor, the processor being used to run a program, characterized in that: When the program is running, the steps of the Linux system restart information recording method described in any one of claims 1 to 7 are executed.

9. A terminal device, comprising a processor, a memory, and a program stored in the memory and executable on the processor, characterized in that: The program code is loaded and executed by the processor to implement the steps of the Linux system restart information recording method according to any one of claims 1 to 7.

10. A computer program product, when executed on a data processing device, characterized in that Suitable for executing the steps of the Linux system restart information recording method described in any one of claims 1-7.

Images