WO2023240558A1

WO2023240558A1 - Firmware debugging method and apparatus

Info

Publication number: WO2023240558A1
Application number: PCT/CN2022/099240
Authority: WO
Inventors: 杨冬东; 李芳�
Original assignee: 北京小米移动软件有限公司
Priority date: 2022-06-16
Filing date: 2022-06-16
Publication date: 2023-12-21
Also published as: CN117597668A

Abstract

The present invention provides a firmware debugging method and an apparatus, applied to the technical field of computers. The method comprises: obtaining installation data of firmware to be debugged and a debugging tool for said firmware; obtaining a read-only storage partition and a read-write storage partition which are independent of each other in a memory of a debug device; deploying said firmware in the read-only storage partition on the basis of the installation data; deploying the debugging tool for said firmware in the read-write storage partition; and running the debugging tool, and debugging said firmware in the read-only storage partition. The debugging tool is deployed in the read-write storage partition, so that said firmware in the read-only storage partition is debugged by means of the debugging tool in the read-write storage partition; because the read-only storage partition is independent of a system in a debugging process, operation of the system is not affected in the debugging process, and the safety of the operation of the system is improved; furthermore, debugging of system stability can be performed in a development stage, and product research and development are accelerated to quickly reach a maturity expectation.

Description

Firmware debugging method and device

Technical field

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

Background technique

In the current technology, during the system development stage, considering the security issues on the devices that are eventually released to users, device connection tools and various system permissions will not be deployed, making it impossible to stabilize the system during the development stage for the same functional version. performance monitoring and debugging.

Contents of the invention

Embodiments of the present disclosure provide a firmware debugging method and device, which can be applied in the technical field of system development to solve the problem that stability monitoring and debugging cannot be performed during the system development stage.

In a first aspect, embodiments of the present disclosure provide a method for debugging firmware, which is characterized in that the method includes: obtaining the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged; obtaining mutually independent read-only storage in the memory of the debugging device partition and read-write storage partition; 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 read-write storage partition; run the debugging tool to perform debugging on the read-only storage partition. Debug the firmware for debugging.

In the embodiment of the present disclosure, the debugging tool of the firmware to be debugged is deployed in a read-write storage partition. Since the read-write storage partition is independent of the read-only storage partition that stores the firmware to be debugged, the debugging process will not affect the system operation. impact, thus solving the problem of being unable to perform stability monitoring and debugging during the system development stage.

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

The first acquisition module is used to obtain the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged;

The second acquisition module is used to acquire mutually independent read-only storage partitions and read-write storage partitions in the memory of the debugging device;

The first deployment module is used to deploy the firmware to be debugged in the read-only storage partition based on the installation data;

The second deployment module is used to deploy the debugging tool of the firmware to be debugged in a read-write storage partition;

The running module is used to run debugging tools and debug the firmware to be debugged in the read-only storage partition.

In a third aspect, the present disclosure proposes an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores information that can be executed by the at least one processor. Instructions, which are executed by the at least one processor to implement the firmware debugging method described in the embodiment of the first aspect of the present disclosure.

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 described in the embodiment of the first aspect of the present disclosure.

In a fifth aspect, the present disclosure proposes a computer program product, which includes a computer program that, when executed by a processor, is used to implement the debugging method of firmware as described in the embodiment of the first aspect of the present disclosure.

Description of the drawings

In order to more clearly illustrate the technical solutions in the embodiments of the disclosure or the background technology, the drawings required to be used in the embodiments or the background technology of the disclosure will be described below.

Figure 1 is a schematic flow chart of a firmware debugging method provided by an embodiment of the present disclosure;

Figure 2 is a schematic flowchart of another firmware debugging method provided by an embodiment of the present disclosure;

Figure 3 is a schematic flowchart of another firmware debugging method provided by an embodiment of the present disclosure;

Figure 4 is a schematic flowchart of another firmware debugging method provided by an embodiment of the present disclosure;

Figure 5 is a schematic structural diagram of a firmware debugging device provided by an embodiment of the present disclosure;

FIG. 6 is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure.

Detailed ways

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

The terminology used in the embodiments of the present disclosure is for the purpose of describing specific embodiments only and is not intended to limit the embodiments of the present disclosure. As used in the embodiments of the present disclosure and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

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, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of the embodiments of the present disclosure, the first information may also be called second information, and similarly, the second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to determining"

For the purpose of simplicity and ease of understanding, the terms used in this article are "greater than" or "less than", "higher than" or "lower than" when characterizing size relationships. But for those skilled in the art, it can be understood 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". "The meaning of "less than" also covers the meaning of "less than or equal to".

The firmware debugging method and device provided by the present disclosure will be introduced in detail below with reference to the accompanying drawings.

Please refer to FIG. 1 , which is a schematic flowchart of a firmware debugging method provided by an embodiment of the present disclosure. As shown in Figure 1, it may include but is not limited to the following steps:

S11: Obtain the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged.

It should be noted that the firmware in the embodiment of the present disclosure refers to the device "driver" stored inside the device. Through the firmware, the operating system can implement the operating actions of a specific machine according to the standard device driver. Some system firmware can Let users update. System firmware can be used in a wide range of electronic products, from remote controls and calculators to keyboards and hard drives in computers, and even in industrial robots. Firmware is the software that performs the most basic and bottom-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 determines the function and performance of the hardware device.

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, and 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 The firmware drives the debugging device's operating system to run.

The firmware to be debugged in the embodiment of the present disclosure can be any type of firmware. For example, the firmware can be the Basic Input/Output System BIOS (Basic Input/output System) or the Unified Extensible Firmware Interface on the computer motherboard. 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.

It is understandable that the installation data of different firmwares to be debugged are different, and there is no limitation here. Correspondingly, different firmwares may require the same or different debugging tools, which need to be selected and set according to the actual monitoring and debugging purposes.

Optionally, the debugging tool can also include debugging content for all firmware, and different debugging options can be selected for different firmware to be debugged. In the embodiment of the present disclosure, debugging tools may include multiple options or tools. For example, they may include various traces (strace, ftrace, ptrace, gtrace) and their control tools, and may also include exception monitoring tools such as kpanic. , softlockup, watchdog, native crash, etc., and their corresponding log (log) and memory (dump) tools, and can also include statistical tools for various states of different systems and information collection tools such as procrank, netstat, etc., through the network Tools and automated scripts to deploy.

It should be noted that the debugging tool can perform automated testing on the firmware by simulating the user's testing of the firmware. For example, the debugging tool can perform stress testing, abnormality checking, etc. on the firmware. For example, the debugging tool can obtain monitoring data and/or monitoring logs of the firmware through piling. , through monitoring data and/or monitoring logs, it is possible to identify whether there are abnormalities in the firmware and/or where the abnormalities occur, etc. Stress conditions in the firmware can be identified through monitoring data and/or monitoring logs.

S12: Obtain mutually independent read-only storage partitions and read-write storage partitions in the memory of the debugging device.

In the embodiment of the present disclosure, the firmware can be debugged by a debugging device before the firmware is released, so as to release stable and safe debugged firmware to user equipment. In order to prevent the firmware debugging process from affecting 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 debugger only has read operation permissions on the content stored in the read-only storage partition, and cannot write operations on the content. Users or debuggers have read and write permissions on the content stored in the read-write storage partition, which means they can edit the content stored in the read-write storage partition.

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 accessible by the user through a specific The refresh program is a program for upgrading. Generally speaking, software that is responsible for the most basic and bottom-level work of a digital product can be called firmware.

In order to consider the security and stability of the final release of the firmware to user devices, device connection tools and various system permissions will not be deployed in the read-only storage partition, making it impossible to monitor and debug system stability during the development phase for the same functional version. . In the embodiment of the present disclosure, the debugging settings may be set manually or automatically operated through a script, without any limitation here.

The read-write storage partition is a rewritable memory chip, and its contents will not be lost when the power is turned off. For example, the readable and writable storage partition can be an Erasable Programmable Read Only Memory (EPROM). In other words, it is non-volatile. It is programmed through an EPROM programmer, which can provide a higher voltage than the normal operating voltage to program the EPROM. Once programmed, EPROM can only be erased by exposure to strong ultraviolet light.

S13, deploy the firmware to be debugged in the read-only storage partition based on the installation data.

In the embodiment of the present disclosure, the firmware to be debugged can be deployed in the read-only storage partition by running the installation data in the read-only storage partition, thereby realizing the functions involved in the corresponding debugging settings of the corresponding read-only storage partition. Call or open to provide the basis for subsequent debugging operations.

The system needs to identify the deployment process, enable the debugging settings in the boot partition, and replace these partitions with the contents of read-only storage partitions with debugging capabilities. By managing the access permissions of read-only storage partitions with debugging tools, you can determine the read-only storage partitions with access permissions, thereby debugging the read-only storage partitions with access permissions and obtaining monitoring data.

S14, deploy the debugging tool of the firmware to be debugged in a read-write storage partition.

In the embodiment of the present disclosure, the readable and writable storage partition is independent from the system, and the readable and writable storage partition can be used by users. The debugging equipment proposed in this disclosure can perform anomaly detection 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, it occupies a lot of space during the debugging process. This part of the storage partition can be read and written, so the debugging process will not affect the running process of the system and is conducive to the stable operation of the system.

Optionally, since the readable and writable storage partitions are storage partitions used by users respectively, in the embodiment of the present disclosure, when the firmware to be debugged is released to the user device, the readable and writable storage partition occupied by the debugging tool can also be released to use the debugging tool. Read-write storage partitions are reconfigured for users to use. In the disclosed embodiment, the recoverable read-write storage partition is occupied for debugging, which can avoid the problem of occupying system space that cannot be returned to the user for monitoring and debugging. After debugging is completed, it can be restored to the user for use, thereby saving money for the user. More storage space improves user resources.

In the embodiment of the present disclosure, after obtaining the debugging tool, the debugging tool is deployed in a read-write storage partition, so that when it is necessary to debug the firmware to be debugged in the read-only storage partition, the debug tool can be debugged from the read-write storage partition. Call related debugging tools in the storage partition.

S15, run the debugging tool to debug the firmware to be debugged in the read-only storage partition.

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

In the embodiment of the present disclosure, 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 independent read-only storage partition and read-write storage partition in the memory of the debugging device are obtained, and then based on the installation data, the read-only storage partition is obtained. Deploy the firmware to be debugged in the storage partition, deploy the debugging tool of the firmware to be debugged in the read-write storage partition, and finally run the debugging tool to debug the firmware to be debugged in the read-only storage partition. In the embodiment of the present disclosure, the debugging tool is deployed in the read-write storage partition, so that the firmware to be debugged in the read-only storage partition is debugged through the debugging tool in the read-write storage partition. During the debugging process, due to the read-only The storage partition is independent from the system, and the debugging process will not affect the system operation, improving the security of the system operation. Furthermore, system stability debugging can be carried out during the development phase, and performance stability evaluation results and various abnormal debugging data can be provided, so that the system has efficient stability monitoring and debugging capabilities, accelerating product development and quickly reaching maturity expectations.

Please refer to Figure 2. Figure 2 is a schematic flow chart of another firmware debugging method provided by an embodiment of the present disclosure. As shown in Figure 2, the deployment process of the debugging tool may include but is not limited to the following steps:

S21: Obtain the debugging source file of the debugging tool, and link the debugging source file to generate an executable file of the debugging tool.

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

S22, deploy the executable file in a read-write storage partition.

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, it can be combined with the read-only storage partition. The firmware to be debugged is isolated.

Optionally, the debugging equipment can be configured with a User Interface (UI). After generating the executable file, the executable file can be displayed to the user on the UI interface. The user can conveniently and intuitively configure the executable file based on the actual situation on the UI interface. According to the debugging needs, the selection of executable files, that is, the flexible selection of debugging functions, can not only increase the flexibility of debugging, but also improve the pertinence and practicality of debugging.

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 be pre-divided into the types of each storage partition, and the type identifier of each storage partition can be marked. In this disclosed embodiment, obtaining mutually 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 based on the type identifier. storage partition. It should be noted that the type identifier is set in advance and is not limited here.

Please refer to Figure 3. Figure 3 is a schematic flow chart of another firmware debugging method provided by an embodiment of the present disclosure. Run the debugging tool to debug the firmware to be debugged in the read-only storage partition. As shown in Figure 3, it may include But not limited to the following steps:

S31, start the debugging tool through the script.

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 extended language, or dynamic language, is a programming language used to control software applications. Scripts are usually saved in text (ASCⅡ) and are only interpreted or compiled when called. When a script is executed, the computer performs a series of operations.

In the embodiment of the present disclosure, a script for starting the debugging tool can be generated in advance, and by running the script, the debugging tool can be automatically called to debug the firmware to be debugged and collect debugging data generated during the debugging process.

It should be noted that automated testing can be carried out by generating scripts, recording key events in advance, including key sequences to enter each application, and configuring the frequency, interval and random entry of each application service. Strategies such as the sequence and times, as well as the configurable number of random key triggers after entering applications and services, implement stress testing and inspection. This enables automatic debugging of the firmware to be debugged, improves debugging efficiency, and reduces the cost of debugging the firmware to be debugged.

S32, use the debugging tool to manage the access rights of the read-only storage partition to obtain monitoring data during the operation of the firmware to be debugged.

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 open permissions for some functions corresponding to the firmware to be debugged.

The debugging tool identifies the contents of the read-only storage partition with debugging capabilities, thereby debugging the read-only storage partition with access permissions and obtaining monitoring data.

It should be noted that when the script is completely run, that is, the debugging event set in the debugging tool is completed, the log data and/or running result data of the firmware running can finally be obtained, thereby generating monitoring data during the running of the firmware to be debugged. .

S33, debug the firmware to be debugged based on the monitoring data.

In the embodiment of the present disclosure, after obtaining the data to be debugged, the monitoring data can be analyzed to determine the abnormal data, and then the firmware to be debugged can be debugged based on the abnormal data.

It should be noted that abnormal data can include many types. For example, if during the execution of the script, there are some processes that do not have access rights or the feedback monitoring data is significantly different from the expected data, etc., the firmware to be debugged needs to be Debugging, or feedback to users, waiting for further optimization.

In the embodiment of the present disclosure, 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 based on the monitoring data. Therefore, by starting the debugging tool through a script and automatically starting the system stress test, you can automatically debug the firmware to be debugged and improve debugging efficiency.

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.

Please refer to FIG. 4 , which is a schematic flowchart of another firmware debugging method provided by an embodiment of the present disclosure. As shown in Figure 4, based on the above embodiment, the method may include but is not limited to the following steps:

S41, start the debugging tool through the script.

Regarding the specific implementation of step S41, please refer to the relevant content records in the above embodiments, and will not be described again here.

S42: Obtain the tracking data of the memory and block device by debugging the memory of the device and the piling position of the block device.

It should be noted that the debugging equipment can be a multi-form system, for example, it can be a vehicle equipment, a mobile phone terminal or an embedded device, etc., without any limitation here.

A block device is a device that stores data in "blocks", typically such as a magnetic disk device, optical disk, or USB flash drive. The block device in this disclosure refers to the block device in the read-only storage partition.

In the embodiment of the present disclosure, piling can be performed on the memory and block device, and the debugging tool can track data on the running status of the memory and block device based on the piling position in the memory and block device.

S43, collect log information of the firmware to be debugged to perform abnormal monitoring of the firmware to be debugged, and obtain abnormal monitoring data of the firmware to be debugged.

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 may include the response time of certain instructions. If the response time is longer than the set value, it may be determined that the response is abnormal. For another example, the log information may include the duration and/or quantity of resources occupied by the application. If the duration and/or quantity occupied exceeds their respective set values, it may be determined that the application is abnormal.

After obtaining the abnormal monitoring data, the abnormal monitoring data can be displayed to the debugger through the UI interface, so that the debugger can perform debugging and/or fault analysis.

S44: Simulate the stress test event of the firmware to be debugged, perform a 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.

In the embodiment of the present disclosure, the debugging tool can be used to simulate the stress test event of the firmware to be debugged, and execute the simulated stress test event to perform the stress test on the firmware to be debugged, and obtain the stress test of the firmware to be debugged when executing the stress test event. data. Stress test data can include key response, or resources occupied when a key is pressed, etc.

In some implementations, stress test events can be recorded in advance, where the stress test events can include interaction sequences of each application. For example, performing frequent key operations on an application often puts pressure on the application. In the present disclosure, a series of key operations on 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 system pressure often comes from frequent key operations of multiple applications. In this disclosure, a series of key operations of multiple applications can be simulated to constitute a stress test event. That is to say, the interaction sequence includes the time of entering each application, key operations in the application, etc.

In this disclosed embodiment, the debugging tool can obtain the application identifier of each application from the stress test event. After entering the application identified by the application identifier, it can interact with the identified application according to the interaction sequence, and collect data to be processed during the interactive operation. Test the status information of the firmware during the execution of the stress test event to generate stress test data. It should be noted that the application identifiers of each application are set in advance, and the application identifiers of different applications can be different for differentiation, and there is no limitation here.

Optionally, the stress test event also includes: at least one test configuration information of each application's test entry frequency, test entry interval, and test entry timing. Optionally, you can also determine the frequency of entering each application through configuration. For example, you can enter 10 times in an hour. Or, configure the time interval for each application, for example, including 5 applications, each application can be entered at a 10-minute interval, or the interval between the 5 applications can be different, which can be configured according to actual needs. Optionally, the entry order and number of times for each application can also be randomly determined; optionally, random key operations 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, stress testing and/or abnormality checking of firmware can be implemented through key events.

It should be noted that the stress test event is a setting option of the firmware in the executable file running the debugging tool. This option may include a variety of options. For details, see the content described in the above embodiments, which will not be described again here.

Steps S42, S43 and S44 may be executed in a set order or in parallel. In the embodiments of the present disclosure, the execution order of steps S42, S43 and S44 is not limited.

In the embodiment of the present disclosure, the debugging tool is first started through a script. It can not only track the status of the memory and block devices, determine whether there are abnormalities in the memory and block devices, collect statistics on the log information and obtain abnormal monitoring data, but also start System stress testing. The debugging tool in the embodiment of the present disclosure has multiple debugging capabilities, making the debugging of the firmware to be debugged more flexible and accurate, and automated debugging improves debugging efficiency. Furthermore, the debugging tool is deployed on a read-write storage partition. The debugging tool configures its own debugging capabilities, and piles and monitors memory, block devices and various system abnormalities. It can also automatically start system stress testing and provide performance stability assessment. As a result, and various abnormal debugging data, the system has efficient stability monitoring and debugging capabilities, accelerating product development and quickly reaching maturity expectations.

Corresponding to the firmware debugging methods provided by the above embodiments, one embodiment of the present disclosure also provides a firmware debugging device. Since the firmware debugging device provided by the embodiments of the present disclosure is different from the firmware debugging method provided by the above embodiments, The firmware debugging method corresponds to the firmware debugging method. Therefore, the above implementation of the firmware debugging method is also applicable to the firmware debugging device provided by the embodiments of the present disclosure, and will not be described in detail in the following embodiments.

Please refer to FIG. 5 , which is a schematic structural diagram of a firmware debugging device 500 provided by an embodiment of the present disclosure. The communication device 500 shown in FIG. 5 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 .

Among them, 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.

The second acquisition module 52 is used to acquire mutually independent read-only storage partitions and read-write storage partitions in the memory of the debugging device.

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.

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

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

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 permissions of the read-only storage partition through the debugging tool to obtain monitoring data during the operation of the firmware to be debugged; according to the monitoring The data is used to debug the firmware to be debugged.

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

In one embodiment of the present disclosure, the running module 55 is also configured to release the readable and writable storage partition occupied by the debugging tool after determining that debugging of the firmware to be debugged is completed.

In one embodiment of the present disclosure, the first deployment module 53 is also used to: obtain the debugging source file of the debugging tool, and link the debugging source file to generate the executable file of the debugging tool; deploy the executable file in the read-write storage partition. executable file.

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 devices by debugging the memory of the device and the piling position of the block device; and collect statistics on the log information of the firmware to be debugged to treat Debug the firmware for abnormal monitoring and obtain the abnormal monitoring data of the firmware to be debugged; simulate the stress test events of the firmware to be debugged, perform a stress test on the firmware to be debugged based on the stress test events, and obtain the stress test data of the firmware to be debugged.

In one embodiment of the present disclosure, the first deployment module 53 is also used to: start a stress test script, and start a stress test event through the stress test script, where the stress test event includes the interaction sequence corresponding to each application; Obtain the application identification of each application in the test event; after entering the application identified by the application identification, interact with the identified application according to the interaction sequence; collect the status information of the firmware to be tested during the execution of the stress test event to generate stress Test Data.

In one embodiment of the present disclosure, the second acquisition module 52 is also used to: acquire the type identifier of the storage partition in the memory of the debugging device; and distinguish the read-only storage partition from the read-write storage partition according to the type identifier.

In the embodiment of the present disclosure, 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 independent read-only storage partition and read-write storage partition in the memory of the debugging device are obtained, and then based on the installation data, the read-only storage partition is obtained. Deploy the firmware to be debugged in the storage partition, deploy the debugging tool of the firmware to be debugged in the read-write storage partition, and finally run the debugging tool to debug the firmware to be debugged in the read-only storage partition. In the embodiment of the present disclosure, the debugging tool is deployed in the read-write storage partition, so that the firmware to be debugged in the read-only storage partition is debugged through the debugging tool in the read-write storage partition. During the debugging process, due to the read-only The storage partition is independent from the system, and the debugging process will not affect the system operation, improving the security of the system operation.

Furthermore, system stability debugging can be carried out during the development phase, and performance stability evaluation results and various abnormal debugging data can be provided, so that the system has efficient stability monitoring and debugging capabilities, accelerating product development and quickly reaching maturity expectations.

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

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

The present disclosure also provides a readable storage medium on which instructions are stored, and when the instructions are executed by a computer, the functions of any of the above method embodiments are implemented.

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

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may 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 processes or functions described in accordance with the embodiments of the present disclosure are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program may be stored in or transferred from one computer-readable storage medium to another, for example, the computer program may be transferred from a website, computer, server, or data center Transmission to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more available media integrated. The usable media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVD)), or semiconductor media (e.g., solid state disks, SSD)) etc.

Those of ordinary skill in the art can understand that the first, second, and other numerical numbers involved in this disclosure are only for convenience of description and are not used to limit the scope of the embodiments of the disclosure, nor to indicate the order.

At least one in the present disclosure can also be described as one or more, and the plurality can be two, three, four or more, and the present disclosure is not limited. In the embodiment of the present disclosure, for a technical feature, the technical feature is distinguished by “first”, “second”, “third”, “A”, “B”, “C” and “D” etc. The technical features described in "first", "second", "third", "A", "B", "C" and "D" are in no particular order or order.

The corresponding relationships shown in each table in this 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 is not limited by this disclosure. When configuring the correspondence between information and each parameter, it is not necessarily required to configure all the correspondences shown in each table. For example, in the table in this 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 may also be other names understandable by the communication device, and the values or expressions of the parameters may also be other values or expressions understandable 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. wait.

Predefinition in this disclosure may be understood as definition, pre-definition, storage, pre-storage, pre-negotiation, pre-configuration, solidification, or pre-burning.

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 with 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. Skilled artisans may implement the described functionality using different methods for each specific application, but such implementations should not be considered to be beyond the scope of this disclosure.

Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, devices and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be described again here.

The above are only specific embodiments of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any person familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present disclosure. should be covered by the protection scope of this disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

A firmware debugging method is characterized by including:

Obtain the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged;

Obtain mutually independent read-only storage partitions and read-write storage partitions in the memory of the debugging device;

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 read-write storage partition;

Run the debugging tool to debug the firmware to be debugged in the read-only storage partition.
The method according to claim 1, characterized in that said running the debugging tool to debug the firmware to be debugged in the read-only storage partition includes:

Launch 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;

The firmware to be debugged is debugged according to the monitoring data.
The method of claim 2, further comprising:

After it is determined that the debugging of the firmware to be debugged is completed, the access permission of the read-only storage partition is restored.
The method of claim 1, further comprising:

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.
The method according to any one of claims 1 to 4, characterized in that the deployment process of the debugging tool of the firmware to be debugged includes:

Obtain the debugging source file of the debugging tool, and link the debugging source file to generate an executable file of the debugging tool;

Deploy the executable file in the read-write storage partition.
The method according to claim 5, characterized in that said obtaining monitoring data during the operation of the firmware to be debugged includes:

Obtain the tracking data of the memory and block device through the piling position of the memory of the debugging device and the block device;

Statistics of the log information of the firmware to be debugged are performed to monitor the abnormality of the firmware to be debugged and obtain abnormal monitoring data of the firmware to be debugged;

Simulate a stress test event of the firmware to be debugged, perform a stress test on the firmware to be debugged based on the stress test event, and obtain stress test data of the firmware to be debugged.
The method according to claim 6, wherein the step of performing a stress test on the firmware to be debugged based on the stress test event and obtaining the stress test data of the firmware to be debugged includes:

Start the stress test script, and start the stress test event through the stress test script, where the stress test event includes the interaction sequence corresponding to each application;

Obtain the application identification 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;

Collect status information of the firmware to be tested during execution of the stress test event to generate the stress test data.
The method according to claim 6, wherein the stress test event further includes: at least one test configuration information among test entry frequency, test entry interval and test entry timing of each application.
The method according to any one of claims 1 to 4, characterized in that obtaining mutually independent read-only storage partitions and read-write storage partitions in the memory of the debugging device includes:

Obtain the type identifier of the storage partition in the memory of the debugging device;

According to the type identifier, the read-only storage partition and the read-write storage partition are distinguished.
A firmware debugging device, characterized by including:

The first acquisition module is used to acquire the installation data of the firmware to be debugged and the debugging tool of the firmware to be debugged;

The second acquisition module is used to acquire mutually independent read-only storage partitions and read-write storage partitions 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, configured to deploy the debugging tool of the firmware to be debugged in the readable and writable storage partition;

An operation module is used to run the debugging tool and debug the firmware to be debugged in the read-only storage partition.
An electronic device, characterized by including a memory and a processor;

Wherein, the processor reads the executable program code stored in the memory and runs a program corresponding to the executable program code, so that the method according to any one of claims 1 to 9 is implemented.
A computer-readable storage medium is used to store instructions, and when the instructions are executed, the method according to any one of claims 1 to 9 is implemented.
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 9.