A firmware debugging method and device

Abstract

The debugging method and device of firmware provided by the present disclosure are applied to the field of computer technology. The method includes: obtaining the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged; obtaining the read-only storage partition and the read-write storage partition that are independent of each other in the memory of the debugging device; deploying the firmware to be debugged in the read-only storage partition based on the installation data; deploying the debugging tool of the firmware to be debugged in the read-write storage partition; running the debugging tool to debug the firmware to be debugged in the read-only storage partition. By deploying the debugging tool in the read-write storage partition, the firmware to be debugged in the read-only storage partition can be debugged through the debugging tool in the read-write storage partition. During the debugging process, since the read-write storage partition is independent of the system, the debugging process will not affect the operation of the system, thereby improving the security of the system operation. Furthermore, the system stability can be debugged in the development stage, accelerating the product development speed to quickly reach the expected maturity.

Description

Technical Field

[0001] The present disclosure relates to the technical field of system development, and in particular to a firmware debugging method and device thereof. Background Art

[0002] In current technology, during the system development stage, device connection tools and various system permissions will not be deployed in consideration of security issues on the devices that are ultimately released to users, making it impossible to monitor and debug system stability during the development phase for the same functional version. Summary of the invention

[0003] The embodiments of the present disclosure provide a firmware debugging method and device, which can be applied to the field of system development technology to solve the problem that stability monitoring and debugging cannot be performed during the system development stage.

[0004] In a first aspect, an embodiment of the present disclosure provides a firmware debugging method, characterized in that the method includes: obtaining installation data of the firmware to be debugged and a debugging tool for the firmware to be debugged; obtaining a read-only storage partition and a readable and writable storage partition that are independent of each other in the memory of a debugging device; deploying the firmware to be debugged in the read-only storage partition based on the installation data; deploying the debugging tool for the firmware to be debugged in the readable and writable storage partition; running the debugging tool to debug the firmware to be debugged in the read-only storage partition.

[0005] In the disclosed embodiment, the debugging tool of the firmware to be debugged is deployed in a readable and writable storage partition. Since the readable and writable storage partition is independent of the read-only storage partition storing the firmware to be debugged, the debugging process will not affect the system operation, thereby solving the problem of being unable to perform stability monitoring and debugging during the system development stage.

[0006] In a second aspect, an embodiment of the present disclosure provides a device for determining pilot location information, characterized in that the device includes:

[0007] A first acquisition module, used to acquire installation data of the firmware to be debugged and a debugging tool of the firmware to be debugged;

[0008] The second acquisition module is used to acquire the read-only storage partition and the read-write storage partition that are independent of each other in the memory of the debugging device;

[0009] A first deployment module, configured to deploy the firmware to be debugged in the read-only storage partition based on the installation data;

[0010] A second deployment module, used to deploy a debugging tool of the firmware to be debugged in a readable and writable storage partition;

[0011] The running module is used to run the debugging tool to debug the firmware to be debugged in the read-only storage partition.

[0012] In a third aspect, the present disclosure proposes an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to implement the firmware debugging method as described in the embodiment of the first aspect of the present disclosure.

[0013] In a fourth aspect, the present disclosure proposes a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to implement the firmware debugging method as described in the embodiment of the first aspect of the present disclosure.

[0014] In a fifth aspect, the present disclosure proposes a computer program product, including a computer program, which, when executed by a processor, is used to implement the firmware debugging method as described in the embodiment of the first aspect of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the background technology, the drawings required for use in the embodiments of the present disclosure or the background technology will be described below.

[0016] Figure 1 It is a flowchart of a firmware debugging method provided by an embodiment of the present disclosure;

[0017] Figure 2 It is a flowchart of another firmware debugging method provided by an embodiment of the present disclosure;

[0018] Figure 3 It is a flowchart of another firmware debugging method provided by an embodiment of the present disclosure;

[0019] Figure 4 It is a flowchart of another firmware debugging method provided by an embodiment of the present disclosure;

[0020] Figure 5 It is a structural diagram of a firmware debugging device provided by an embodiment of the present disclosure;

[0021] Figure 6 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0022] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0023] The terms used in the disclosed embodiments are only for the purpose of describing specific embodiments and are not intended to limit the disclosed embodiments. The singular forms of "a", "an" and "the" used in the disclosed embodiments and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0024] It should be understood that although the terms first, second, third, etc. may be used to describe various information in the embodiments of the present disclosure, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the embodiments of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining"

[0025] For the purpose of brevity and ease of understanding, the terms used herein to characterize size relationships are "greater than" or "less than", "higher than" or "lower than". However, those skilled in the art can understand that the term "greater than" also covers the meaning of "greater than or equal to", and "less than" also covers the meaning of "less than or equal to"; the term "higher than" covers the meaning of "higher than or equal to", and "lower than" also covers the meaning of "lower than or equal to".

[0026] The firmware debugging method and device provided by the present disclosure are described in detail below with reference to the accompanying drawings.

[0027] See also Figure 1 , Figure 1 FIG. 1 is a flowchart of a firmware debugging method provided by an embodiment of the present disclosure. Figure 1 As shown, the following steps may be included but not limited to:

[0028] S11, obtaining installation data of the firmware to be debugged and a debugging tool of the firmware to be debugged.

[0029] It should be noted that the firmware in the embodiments of the present disclosure refers to the device "driver" stored inside the device. Through the firmware, the operating system can implement the operation of a specific machine according to the standard device driver. Some system firmware can be updated by users. System firmware can be used in a very wide range of electronic products, from remote controls, calculators to keyboards and hard disks in computers, and even in industrial robots. Firmware is software that performs the most basic and lowest-level work of a system. In hardware devices, firmware is the soul of the hardware device, because some hardware devices have no other software components except firmware, so the firmware also determines the function and performance of the hardware device.

[0030] In the embodiment of the present disclosure, in order to debug the firmware on the debugging device, the installation data of the firmware to be debugged can be obtained, so that the firmware to be debugged can be installed on the debugging device based on the installation data. After the installation is completed, the debugging device can use the firmware to drive the operating system of the debugging device to run.

[0031] The firmware to be debugged in the embodiments of the present disclosure may be any type of firmware, for example, the firmware may be a Basic Input / Output System BIOS (Basic Input / output System) on a computer motherboard, a Unified Extensible Firmware Interface (UEFI), etc. It should be noted that this is only an example, and the type of firmware is not limited in the embodiments of the present disclosure.

[0032] It is understandable that different firmware to be debugged has different installation data, which is not limited here. Correspondingly, the debugging tools required by different firmware can also be the same or different, and the specific selection and setting needs to be based on the actual monitoring and debugging purposes.

[0033] Optionally, the debugging tool may also include debugging content of all firmwares, and different debugging options may be selected for different firmwares to be debugged. In the disclosed embodiment, the debugging tool may include multiple options or multiple tools, for example, various traces (strace, ftrace, ptrace, gtrace) and their control tools, and may also include abnormal monitoring tools such as kpanic, softlockup, watchdog, native crash, etc., and their corresponding log (log) and memory (dump) tools, and may also include statistical tools for various states of the heterogeneous system and collection tools for the information provided, such as procrank, netstat, etc., which are deployed through network tools and automated scripts.

[0034] It should be noted that the debugging tool can perform automated testing on the firmware by simulating the user, for example, the firmware can be subjected to stress testing, abnormality checking, etc. For example, the debugging tool can obtain the monitoring data and / or monitoring log of the firmware by means of stubbing, and can identify whether the firmware has abnormalities and / or the location of the abnormalities through the monitoring data and / or monitoring logs. The stress situation of the firmware can be identified through the monitoring data and / or monitoring logs.

[0035] S12, obtaining a read-only storage partition and a read-write storage partition that are independent of each other in the memory of the debugging device.

[0036] In the disclosed embodiment, the firmware can be debugged by the debugging device before the firmware is released, so as to release the debugged firmware to the user device in a stable and secure manner. In order to ensure that the firmware debugging process does not affect the installation data of the firmware itself, independent read-only storage partitions and read-write storage partitions can be identified from the memory of the debugging device. It should be noted that the user or the debugging personnel only has the permission to read the content stored in the read-only storage partition, and cannot write to the content. The user or the debugging personnel has the permission to read and write the content stored in the read-write storage partition, that is, the content stored in the read-write storage partition can be edited.

[0037] It should be noted that firmware is generally stored in a read-only storage partition in the device, for example, the read-only storage partition can be an electrically erasable programmable read-only memory (EEPROM), which is generally a program that can be upgraded by the user through a specific refresh program. Generally speaking, the software that performs the most basic and lowest-level work of a digital product can be called firmware.

[0038] In order to consider the security and stability of the firmware that is ultimately released to the user's device, the device connection tools and various system permissions will not be deployed in the read-only storage partition, so that the system stability monitoring and debugging cannot be performed for the same functional version during the development phase. In the disclosed embodiment, the debugging settings can be set manually or automatically through a script, and no restrictions are made here.

[0039] A rewritable memory partition is a rewritable memory chip whose contents will not be lost when the power is turned off. For example, a rewritable memory partition can be an erasable programmable read-only memory (EPROM). In other words, it is non-volatile. It is programmed by an EPROM programmer, which can provide a higher voltage than the normal operating voltage to program the EPROM. Once programmed, the EPROM can only be erased under strong ultraviolet light.

[0040] S13, deploying the firmware to be debugged in the read-only storage partition based on the installation data.

[0041] In the embodiment of the present disclosure, the installation data can be run in the read-only storage partition to deploy the firmware to be debugged in the read-only storage partition, so that the functions involved in the corresponding debugging settings of the corresponding read-only storage partition can be called or opened, providing a basis for subsequent debugging operations.

[0042] The system needs to identify the deployment process, start the debugging settings in the boot partition, and replace these partitions with the contents of the read-only storage partition with debugging capabilities. The access rights of the read-only storage partition can be managed through the debugging tool, and the read-only storage partition with access rights can be determined, so that the read-only storage partition with access rights can be debugged and the monitoring data can be obtained.

[0043] S14, deploying a debugging tool for the firmware to be debugged in the readable and writable storage partition.

[0044] In the embodiment of the present disclosure, the readable and writable storage partition is independent of the system and can be used by the user. The debugging device proposed in the present disclosure can detect abnormalities on the firmware to be debugged before it is released to the user device, and perform stability debugging on the firmware to be debugged. Since the readable and writable storage partition is independent of the system, this part of the readable and writable storage partition is occupied during the debugging process, so that the debugging process does not affect the operation process of the system, which is conducive to the stable operation of the system.

[0045] Optionally, since the readable and writable storage partitions are storage partitions respectively used by users, in the embodiment of the present disclosure, when the firmware to be debugged is released to the user device, the readable and writable storage partitions occupied by the debugging tool can also be released to reconfigure the readable and writable storage partitions for the user to use. In the embodiment of the present disclosure, the use of the recoverable readable and writable storage partition for debugging can avoid the problem of occupying system space that cannot be returned to the user for monitoring and debugging. After the debugging is completed, it can be restored to the user for use, thereby saving more storage space for the user and improving the user's use of resources.

[0046] In the disclosed embodiment, after the debugging tool is acquired, the debugging tool is deployed in a readable and writable storage partition, so that when the firmware to be debugged in the read-only storage partition needs to be debugged, the relevant debugging tool can be called from the readable and writable storage partition.

[0047] S15, running a debugging tool to debug the firmware to be debugged in the read-only storage partition.

[0048] It should be noted that debugging the firmware to be debugged in the read-only storage partition may include running debugging tools, tracking the status of the firmware operation, stress testing, or analyzing and troubleshooting abnormal firmware data based on the results.

[0049] In the disclosed embodiment, the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged are first obtained, and then the read-only storage partition and the read-write storage partition that are independent of each other in the memory of the debugging device are obtained, and then the firmware to be debugged is deployed in the read-only storage partition based on the installation data, and the debugging tool of the firmware to be debugged is deployed in the read-write storage partition, and finally the debugging tool is run to debug the firmware to be debugged in the read-only storage partition. In the disclosed embodiment, by deploying the debugging tool in the read-write storage partition, the firmware to be debugged in the read-only storage partition is debugged by the debugging tool in the read-write storage partition. During the debugging process, since the read-write storage partition is independent of the system, the debugging process will not affect the operation of the system, thereby improving the safety of the system operation. Furthermore, the system stability can be debugged in the development stage, and the performance stability evaluation results and various abnormal debugging data can be provided, so that the system has efficient stability monitoring and debugging capabilities, and accelerates the product development speed to quickly reach the maturity expectations.

[0050] See also Figure 2 , Figure 2 is a flowchart of another firmware debugging method provided by an embodiment of the present disclosure, such as Figure 2 As shown, the deployment process of the debugging tool may include but is not limited to the following steps:

[0051] S21, obtaining a debugging source file of a debugging tool, and linking the debugging source file to generate an executable file of the debugging tool.

[0052] The debugging source file of the debugging tool is pre-compiled in the compiler, wherein the debugging source file includes debugging environment parameters, debugging content, debugging parameters and debugging logic, etc. In the disclosed embodiment, after obtaining the debugging source file, in order to enable the debugging source file to be executed, the debugging source file needs to be linked to generate the executable file of the debugging tool. It should be noted that each source file, i.e., a .c file, corresponds to a fragmented file, i.e., a .h file. The .c and .h files are integrated into a combined C file through pre-compilation (#include), and the extension of this combined C file is .i. The combined C file is compiled into an assembly file .s, and the target file is a machine instruction placed in a .o file. A single target file cannot work because each target file supports each other. Further, each target file is integrated into an executable file. For example, the executable file suffix in the Windows system is .exe, and the suffix in the Linux system is .out.

[0053] S22, deploying the executable file in the readable and writable storage partition.

[0054] After the executable file corresponding to the debugging tool is generated through the above linking process, the executable file can be deployed to the read-write storage partition. Since the read-write storage partition is independent of the read-only storage partition, the firmware to be debugged can be isolated from the read-only storage partition.

[0055] Optionally, the debugging device can be configured with a human-computer interaction interface (User Interface, UI). After the executable file is generated, the executable file can be displayed to the user on the UI interface. The user can conveniently and intuitively select the executable file on the UI interface according to actual debugging needs, that is, flexibly select the debugging function, which can not only increase the flexibility of debugging, but also improve the pertinence and practicality of debugging.

[0056] There are multiple storage partitions in the debugging device, and different storage partitions may correspond to different types. For example, the types may include read-only storage partitions and read-write storage partitions. The memory of the debugging device can pre-divide the types of each storage partition, and mark the type identifier of each storage partition. In the disclosed embodiment, obtaining independent read-only storage partitions and read-write storage partitions in the memory of the debugging device includes: obtaining the type identifier of the storage partition in the memory of the debugging device, and distinguishing the read-only storage partition and the read-write storage partition according to the type identifier. It should be noted that the type identifier is set in advance and is not limited here.

[0057] See also Figure 3 , Figure 3 FIG. 1 is a flow chart of another firmware debugging method provided by an embodiment of the present disclosure, wherein a debugging tool is run to debug the firmware to be debugged in the read-only storage partition, such as Figure 3 As shown, the following steps may be included but not limited to:

[0058] S31, start the debugging tool through the script.

[0059] It should be noted that a script is an executable file written in a certain format using a specific descriptive language. Scripting language, also known as an extended language or dynamic language, is a programming language used to control software applications. Scripts are usually saved in text (ASCII) and are only interpreted or compiled when called. When a script is executed, the computer will perform a series of operations.

[0060] In the disclosed embodiment, a script for starting a debugging tool may be generated in advance, and the debugging tool may be automatically called by running the script to debug the firmware to be debugged, and the debugging data generated during the debugging process may be collected.

[0061] It should be noted that automated testing can be performed by generating scripts to record key events in advance, including the key sequences for entering each application, and implementing stress testing checks by configuring the frequency, interval, random order and number of entry into each application service, and the configurable number of random key triggers after entering the application and service. This enables automatic debugging of the firmware to be debugged, improves debugging efficiency, and reduces the cost of debugging the firmware to be debugged.

[0062] S32, managing the access rights of the read-only storage partition through a debugging tool to obtain monitoring data during the running of the firmware to be debugged.

[0063] In the embodiment of the present disclosure, in order to obtain monitoring data during the operation of the firmware to be debugged, it is necessary to enable permissions for some functions corresponding to the firmware to be debugged.

[0064] The debugging tool debugs the read-only storage partition with access rights and obtains monitoring data by identifying the content of the read-only storage partition with debugging capability.

[0065] It should be noted that when the script is completely executed, that is, the debugging events set in the debugging tool are executed, the log data and / or the running result data of the firmware can be obtained, thereby generating the monitoring data of the firmware to be debugged during its running.

[0066] S33, debugging the firmware to be debugged according to the monitoring data.

[0067] In the embodiment of the present disclosure, after the data to be debugged is obtained, the monitoring data may be analyzed to determine abnormal data, and then the firmware to be debugged may be debugged based on the abnormal data.

[0068] It should be noted that abnormal data can include multiple types. For example, if some processes do not have access rights during script execution or the feedback monitoring data is significantly different from the expected data, the firmware to be debugged needs to be debugged or feedback needs to be given to the user for further optimization processing.

[0069] In the disclosed embodiment, the debugging tool is first started through a script, and then the access rights of the read-only storage partition are managed through the debugging tool to obtain monitoring data during the operation of the firmware to be debugged, and finally the firmware to be debugged is debugged according to the monitoring data. Thus, the debugging tool is started through a script, and the system stress test is automatically started, so that the firmware to be debugged can be automatically debugged, thereby improving the debugging efficiency.

[0070] Further, after it is determined that the debugging of the firmware to be debugged is completed, the readable and writable storage partition occupied by the debugging tool is released.

[0071] See also Figure 4 , Figure 4 FIG. 1 is a flow chart of another firmware debugging method provided by an embodiment of the present disclosure. Figure 4 As shown, based on the above embodiment, the method may include but is not limited to the following steps:

[0072] S41, start the debugging tool through the script.

[0073] For the specific implementation of step S41, please refer to the relevant contents in the above embodiment, which will not be repeated here.

[0074] S42, obtaining the trace data of the memory and the block device by debugging the memory of the device and the stubbing position of the block device.

[0075] It should be noted that the debugging device can be a multi-format system, for example, it can be a vehicle-mounted device, a mobile phone terminal or an embedded device, etc., and no limitation is made here.

[0076] A block device is a device that stores data in "blocks", such as a disk device, an optical disk, or a USB flash drive. The block device in the present disclosure refers to a block device in a read-only storage partition.

[0077] In the disclosed embodiment, stubbing may be performed on memory and block devices, and the debugging tool may track data on the running status of the memory and block devices based on the stubbing locations in the memory and block devices.

[0078] S43, collecting log information of the firmware to be debugged to monitor abnormalities of the firmware to be debugged, and obtaining abnormal monitoring data of the firmware to be debugged.

[0079] The firmware to be debugged will generate log information during operation. In the embodiment of the present disclosure, the log information of the firmware to be debugged can be counted, and the log information can be compared with the preset information to determine the abnormal data of the firmware to be debugged. For example, the log information can include the response time of certain instructions. If the response time is longer than the set value, it can be determined that the response is abnormal. For another example, the log information can include the duration and / or amount of resources occupied by the application. If the duration and / or the amount of resources occupied exceed the respective set values, it can be determined that the application is abnormal.

[0080] After the abnormal monitoring data is acquired, the abnormal monitoring data may be displayed to a debugger through a UI interface so that the debugger can perform debugging and / or fault analysis.

[0081] S44, simulating a stress test event of the firmware to be debugged, performing a stress test on the firmware to be debugged based on the stress test event, and obtaining stress test data of the firmware to be debugged.

[0082] In the embodiment of the present disclosure, a debugging tool can be used to simulate a stress test event on the firmware to be debugged, and the simulated stress test event can be executed to perform a stress test on the firmware to be debugged, and the stress test data of the firmware to be debugged when executing the stress test event can be obtained. The stress test data may include the response of a key press, or the resources occupied when a key press is pressed, etc.

[0083] In some implementations, stress test events can be recorded in advance, where the stress test events can include interaction sequences of various applications. For example, frequent key operations on an application often cause stress on the application. In the present disclosure, a series of key operations in the application can be simulated, and the series of key operations constitute a stress test event. The interaction sequence can be understood as the key sequence corresponding to the application. It should be noted that the pressure of the system often comes from frequent key operations of multiple applications. In the present disclosure, a series of key operations of multiple applications can be simulated to constitute a stress test event. In other words, the interaction sequence includes the moment of entering each application, the key operations in the application, etc.

[0084] In the disclosed embodiment, the debugging tool can obtain the application identifier of each application from the stress test event, and after entering the application identified by the application identifier, perform interactive operations on the identified application according to the interactive sequence, and collect state information of the firmware to be tested during the execution of the stress test event during the interactive operation to generate stress test data. It should be noted that the application identifier of each application is set in advance, and the application identifiers of different applications can be different for distinction, which is not limited here.

[0085] Optionally, the stress test event also includes: at least one test configuration information of the test entry frequency, test entry interval and test entry sequence of each application. Optionally, the frequency of entering each application can also be determined by configuration, for example, it can be entered 10 times within an hour. Alternatively, the time interval of each application is configured, for example, including 5 applications, each application can be entered at an interval of 10 minutes, or the interval time between the 5 applications can be different, which can be configured according to actual needs. Optionally, the entry order and number of times of each application can also be randomly determined; optionally, the random key operation after entering the application can also be randomly determined, and the number of keys can also be configured. In the embodiment of the present disclosure, the stress test and / or abnormality check of the firmware can be implemented through key events.

[0086] It should be noted that the stress test event is a setting option of the firmware in the executable file of the running debugging tool. The option may include multiple options. For details, please refer to the content described in the above embodiment, which will not be repeated here.

[0087] Step S42, step S43 and step S44 may be executed in a set order or in parallel. The execution order of step S42, step S43 and step S44 is not limited in the embodiments of the present disclosure.

[0088] In the disclosed embodiment, the debugging tool is first started through a script, which can not only track the status of the memory and block devices, determine whether there are abnormalities in the memory and block devices, and obtain abnormal monitoring data by statistics of log information, but also start the system stress test. The debugging tool in the disclosed embodiment has a variety of debugging capabilities, which makes the debugging of the firmware to be debugged more flexible and accurate, and the automated debugging improves the efficiency of debugging. Further, the debugging tool is deployed on a readable and writable storage partition. The debugging tool configures its own debugging capabilities, and monitors the memory, block devices and various system abnormalities, and can automatically start the system stress test, and provide performance stability evaluation results, and various abnormal debugging data, so that the system has efficient stability monitoring and debugging capabilities, and accelerates the speed of product development to quickly reach the maturity expectations.

[0089] Corresponding to the firmware debugging methods provided in the above-mentioned embodiments, an embodiment of the present disclosure further provides a firmware debugging device. Since the firmware debugging device provided in the embodiment of the present disclosure corresponds to the firmware debugging methods provided in the above-mentioned embodiments, the implementation methods of the above-mentioned firmware debugging methods are also applicable to the firmware debugging device provided in the embodiment of the present disclosure, and will not be described in detail in the following embodiments.

[0090] See also Figure 5 , is a structural diagram of a firmware debugging device 500 provided in an embodiment of the present disclosure. Figure 5The communication device 500 shown may include a first acquisition module 51 , a second acquisition module 52 , a first deployment module 53 , a second deployment module 54 and an operation module 55 .

[0091] The first acquisition module 51 is used to acquire the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged.

[0092] The second acquisition module 52 is used to obtain independent read-only storage partitions and read-write storage partitions in the debugging device memory.

[0093] The first deployment module 53 is used to deploy the firmware to be debugged in the read-only storage partition based on the installation data.

[0094] The second deployment module 54 is used to deploy the debugging tool of the firmware to be debugged in the readable and writable storage partition.

[0095] The running module 55 is used to run the debugging tool to debug the firmware to be debugged in the read-only storage partition.

[0096] In one embodiment of the present disclosure, the running module 55 is also used to: start the debugging tool through a script; manage the access rights of the read-only storage partition through the debugging tool to obtain monitoring data during the operation of the firmware to be debugged; and debug the firmware to be debugged according to the monitoring data.

[0097] In one embodiment of the present disclosure, the running module 55 is further used to: after determining that debugging of the firmware to be debugged is completed, restore the access rights to the read-only storage partition.

[0098] In one embodiment of the present disclosure, the running module 55 is further used to: after determining that the debugging of the firmware to be debugged is completed, release the readable and writable storage partition occupied by the debugging tool.

[0099] In one embodiment of the present disclosure, the first deployment module 53 is further used to: obtain a debugging source file of a debugging tool, link the debugging source file to generate an executable file of the debugging tool; and deploy the executable file in a readable and writable storage partition.

[0100] In one embodiment of the present disclosure, the first deployment module 53 is also used to: obtain the tracking data of the memory and block device by debugging the memory of the device and the stubbing position of the block device; count the log information of the firmware to be debugged to perform abnormal monitoring of the firmware to be debugged, and obtain the abnormal monitoring data of the firmware to be debugged; simulate the stress test event of the firmware to be debugged, perform stress test on the firmware to be debugged based on the stress test event, and obtain the stress test data of the firmware to be debugged.

[0101] In one embodiment of the present disclosure, the first deployment module 53 is further used to: start a stress test script, start a stress test event through the stress test script, wherein the stress test event includes an interaction sequence corresponding to each application; obtain an application identifier of each application from the stress test event; after entering the application identified by the application identifier, perform interactive operations on the identified application according to the interaction sequence; and collect status information of the firmware to be tested during the execution of the stress test event to generate stress test data.

[0102] In one embodiment of the present disclosure, the second acquisition module 52 is further used to: acquire the type identification of the storage partition in the debugging device memory; and distinguish between the read-only storage partition and the read-write storage partition according to the type identification.

[0103] In the disclosed embodiment, the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged are first obtained, and then the read-only storage partition and the read-write storage partition that are independent of each other in the memory of the debugging device are obtained, and then the firmware to be debugged is deployed in the read-only storage partition based on the installation data, and the debugging tool of the firmware to be debugged is deployed in the read-write storage partition, and finally the debugging tool is run to debug the firmware to be debugged in the read-only storage partition. In the disclosed embodiment, by deploying the debugging tool in the read-write storage partition, the firmware to be debugged in the read-only storage partition is debugged by the debugging tool in the read-write storage partition. During the debugging process, since the read-write storage partition is independent of the system, the debugging process will not affect the operation of the system, thereby improving the security of the system operation.

[0104] Furthermore, it is possible to debug the system stability during the development phase, provide performance stability evaluation results and various abnormal debugging data, so that the system has efficient stability monitoring and debugging capabilities, and accelerate product development to quickly reach maturity expectations.

[0105] Those skilled in the art may also understand that the various illustrative logical blocks and steps listed in the embodiments of the present disclosure may be implemented by electronic hardware, computer software, or a combination of the two. Whether such functions are implemented by hardware or software depends on the specific application and the design requirements of the entire system. Those skilled in the art may use various methods to implement the functions described for each specific application, but such implementation should not be understood as exceeding the scope of protection of the embodiments of the present disclosure.

[0106] In order to implement the above embodiment, the present disclosure also provides an electronic device 600, such as Figure 6As shown, the electronic device 600 includes: a processor 61 and a memory 62 communicatively connected to the processor, the memory 62 stores instructions that can be executed by at least one processor, and the instructions are executed by at least one processor 61 to implement a firmware debugging method as in the first aspect of the present disclosure.

[0107] The present disclosure also provides a readable storage medium having instructions stored thereon, which implement the functions of any of the above method embodiments when executed by a computer.

[0108] The present disclosure also provides a computer program product, which implements the functions of any of the above method embodiments when executed by a computer.

[0109] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs. When the computer program is loaded and executed on a computer, the process or function described in the embodiment of the present disclosure is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer program can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a high-density digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0110] Those skilled in the art can understand that the various numerical numbers such as first and second involved in the present disclosure are only used for the convenience of description and are not used to limit the scope of the embodiments of the present disclosure, but also indicate the order of precedence.

[0111] At least one in the present disclosure may also be described as one or more, and a plurality may be two, three, four or more, which is not limited in the present disclosure. In the embodiments of the present disclosure, for a technical feature, the technical features in the technical feature are distinguished by "first", "second", "third", "A", "B", "C" and "D", etc., and there is no order of precedence or size between the technical features described by the "first", "second", "third", "A", "B", "C" and "D".

[0112] The corresponding relationships shown in the tables in the present disclosure can be configured or predefined. The values ​​of the information in each table are only examples and can be configured as other values, which are not limited by the present disclosure. When configuring the corresponding relationship between the information and each parameter, it is not necessarily required to configure all the corresponding relationships illustrated in each table. For example, in the table in the present disclosure, the corresponding relationships shown in some rows may not be configured. For another example, appropriate deformation adjustments can be made based on the above table, such as splitting, merging, etc. The names of the parameters shown in the titles of the above tables can also use other names that can be understood by the communication device, and the values ​​or representations of the parameters can also be other values ​​or representations that can be understood by the communication device. When implementing the above tables, other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables or hash tables.

[0113] The predefined in the present disclosure may be understood as defined, predefined, stored, pre-stored, pre-negotiated, pre-configured, solidified, or pre-burned.

[0114] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this disclosure.

[0115] 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 units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0116] The above is only a specific embodiment of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present disclosure, which should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.

Claims

1. A firmware debugging method, characterized in that: include: Obtaining installation data of the firmware to be debugged and a debugging tool for the firmware to be debugged; Get the independent read-only storage partitions and read-write storage partitions in the debug device memory; Deploy the firmware to be debugged in the read-only storage partition based on the installation data; Deploy the debugging tool of the firmware to be debugged in the readable and writable storage partition, and the system of the debugging device is independent of the readable and writable storage partition; Running the debugging tool to debug the firmware to be debugged in the read-only storage partition; After determining that debugging of the firmware to be debugged is completed, releasing the readable and writable storage partition occupied by the debugging tool.

2. The method according to claim 1, characterized in that The running of the debugging tool to debug the firmware to be debugged in the read-only storage partition includes: Launch the debugging tool through a script; The access rights of the read-only storage partition are managed by the debugging tool to obtain monitoring data during the operation of the firmware to be debugged; The firmware to be debugged is debugged according to the monitoring data.

3. The method according to claim 2, characterized in that The method further comprises: After determining that debugging of the firmware to be debugged is completed, the access permission of the read-only storage partition is restored.

4. The method according to any one of claims 1 to 3, characterized in that The deployment process of the debugging tool of the firmware to be debugged includes: Acquire a debugging source file of the debugging tool, and link the debugging source file to generate an executable file of the debugging tool; The executable file is deployed in the readable and writable storage partition.

5. The method according to claim 4, characterized in that The obtaining of monitoring data during the running of the firmware to be debugged includes: Obtaining tracking data of the memory and block device through the memory of the debugging device and the stubbing position of the block device; Collecting log information of the firmware to be debugged to monitor abnormalities of the firmware to be debugged and obtain abnormal monitoring data of the firmware to be debugged; A stress test event of the firmware to be debugged is simulated, and a stress test is performed on the firmware to be debugged based on the stress test event to obtain stress test data of the firmware to be debugged.

6. The method according to claim 5, characterized in that The step of performing a stress test on the firmware to be debugged based on the stress test event and obtaining stress test data of the firmware to be debugged includes: Starting a stress test script, and starting a stress test event through the stress test script, wherein the stress test event includes an interaction timing corresponding to each application; Obtaining an application identifier of each application from the stress test event; After entering the application identified by the application identifier, performing an interactive operation on the identified application according to the interactive sequence; The state information of the firmware to be tested during the execution of the stress test event is collected to generate the stress test data.

7. The method according to claim 5, characterized in that The stress test event further includes: at least one test configuration information of a test entry frequency, a test entry interval, and a test entry sequence of each application.

8. The method according to any one of claims 1 to 3, characterized in that The step of obtaining the independent read-only storage partitions and the read-write storage partitions in the memory of the debugging device includes: Obtaining a type identifier of a storage partition in the memory of the debugging device; The read-only storage partition and the readable and writable storage partition are distinguished according to the type identifier.

9. A firmware debugging device, characterized in that: include: A first acquisition module, used to acquire installation data of the firmware to be debugged and a debugging tool of the firmware to be debugged; The second acquisition module is used to acquire the read-only storage partition and the read-write storage partition that are independent of each other in the memory of the debugging device; A first deployment module, configured to deploy the firmware to be debugged in the read-only storage partition based on the installation data; A second deployment module is used to deploy the debugging tool of the firmware to be debugged in the readable and writable storage partition, and the system of the debugging device is independent of the readable and writable storage partition; An operating module, used for operating the debugging tool to debug the firmware to be debugged in the read-only storage partition; The operation module is also used for: After determining that debugging of the firmware to be debugged is completed, releasing the readable and writable storage partition occupied by the debugging tool.

10. An electronic device, characterized in that: Including memory and processor; The processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so that the method according to any one of claims 1 to 8 is implemented.

11. A computer-readable storage medium storing instructions, which, when executed, enable the method according to any one of claims 1 to 8 to be implemented.

12. A computer program product comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 8.

Images