WO2023240558A1 - 一种固件的调试方法及其装置 - Google Patents

一种固件的调试方法及其装置 Download PDF

Info

Publication number
WO2023240558A1
WO2023240558A1 PCT/CN2022/099240 CN2022099240W WO2023240558A1 WO 2023240558 A1 WO2023240558 A1 WO 2023240558A1 CN 2022099240 W CN2022099240 W CN 2022099240W WO 2023240558 A1 WO2023240558 A1 WO 2023240558A1
Authority
WO
WIPO (PCT)
Prior art keywords
firmware
debugging
debugged
read
storage partition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/099240
Other languages
English (en)
French (fr)
Inventor
杨冬东
李芳�
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Xiaomi Mobile Software Co Ltd
Original Assignee
Beijing Xiaomi Mobile Software Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Xiaomi Mobile Software Co Ltd filed Critical Beijing Xiaomi Mobile Software Co Ltd
Priority to CN202280004135.8A priority Critical patent/CN117597668B/zh
Priority to PCT/CN2022/099240 priority patent/WO2023240558A1/zh
Publication of WO2023240558A1 publication Critical patent/WO2023240558A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software

Definitions

  • 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.
  • 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 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.
  • 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.
  • FIG. 2 is a schematic flowchart of another firmware debugging method provided by an embodiment of the present disclosure
  • FIG. 3 is a schematic flowchart of another firmware debugging method provided by an embodiment of the present disclosure.
  • FIG. 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.
  • 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.
  • first information may also be called second information, and similarly, the second information may also be called first information.
  • word “if” as used herein may be interpreted as "when” or “when” or “in response to determining”
  • FIG. 1 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:
  • 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.
  • 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.
  • 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.
  • the debugging tool can also include debugging content for all firmware, and different debugging options can be selected for different firmware to be debugged.
  • 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.
  • the debugging tool can perform automated testing on the firmware by simulating the user's testing of the firmware.
  • the debugging tool can perform stress testing, abnormality checking, etc. on the firmware.
  • 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.
  • firmware is generally stored in a read-only storage partition in the device.
  • 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
  • EEPROM Electrically Erasable Programmable Read Only Memory
  • the refresh program is a program for upgrading.
  • firmware software that is responsible for the most basic and bottom-level work of a digital product can be called firmware.
  • the read-write storage partition is a rewritable memory chip, and its contents will not be lost when the power is turned off.
  • the readable and writable storage partition can be an Erasable Programmable Read Only Memory (EPROM).
  • EPROM Erasable Programmable Read Only Memory
  • 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.
  • 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.
  • the debugging tool 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.
  • 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. .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • the debugging source file needs to be linked to generate an executable file of the debugging tool.
  • 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.
  • 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.
  • the executable file corresponding to the debugging tool 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.
  • the debugging equipment can be configured with a User Interface (UI).
  • UI User Interface
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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 (ASCII) and are only interpreted or compiled when called. When a script is executed, the computer performs a series of operations.
  • 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.
  • 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.
  • 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.
  • the script 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. .
  • 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.
  • 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.
  • 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.
  • the readable and writable storage partition occupied by the debugging tool is released.
  • FIG. 4 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:
  • 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.
  • 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.
  • 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 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.
  • Stress test data can include key response, or resources occupied when a key is pressed, etc.
  • stress test events can be recorded in advance, where the stress test events can include interaction sequences of each application.
  • performing frequent key operations on an application often puts pressure on the application.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the execution order of steps S42, S43 and S44 is not limited.
  • FIG. 5 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the above embodiments it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof.
  • 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.
  • the computer program 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开提供的固件的调试方法及装置，应用于计算机技术领域，该方法包括：获取待调试固件的安装数据和待调试固件的调试工具；获取调试设备内存中相互独立的只读存储分区和可读写存储分区；基于安装数据在只读存储分区中部署待调试固件；将待调试固件的调试工具部署在可读写存储分区中；运行调试工具，对只读存储分区内的待调试固件进行调试。通过将调试工具部署在可读写存储分区中，从而通过可读写存储分区中的调试工具，对只读存储分区内的待调试固件进行调试，在调试过程中由于只读存储分区与系统独立，调试过程不会影响系统运行，提高系统运行的安全性，进一步地，能够在开发阶段进行系统稳定性的调试，加速产品研发速度快速达到成熟度预期。

Description

一种固件的调试方法及其装置 技术领域
本公开涉及系统开发技术领域，尤其涉及一种固件的调试方法及其装置。
背景技术
当前技术中，在系统开发的阶段，考虑到最终发布给用户的设备上的安全性问题，是不会部署设备连接工具和各种系统权限的，使得不能对于相同功能版本在开发阶段进行系统稳定性监控和调试。
发明内容
本公开实施例提供一种固件的调试方法及其装置，可以应用于系统开发技术领域，用于解决在系统开发阶段无法进行稳定性监控和调试的问题。
第一方面，本公开实施例提供了一种固件的调试方法，其特征在于，方法包括：获取待调试固件的安装数据和待调试固件的调试工具；获取调试设备内存中相互独立的只读存储分区和可读写存储分区；基于安装数据在只读存储分区中部署待调试固件；将待调试固件的调试工具部署在可读写存储分区中；运行调试工具，对只读存储分区内的待调试固件进行调试。
本公开实施例中通过将待调试固件的调试工具部署在可读写存储分区中，由于该可读写存储分区与存储待调试固件的只读存储分区相互独立，使得调试过程对系统运行不会造成影响，从而可以解决在系统开发阶段无法进行稳定性监控和调试的问题。
第二方面，本公开实施例提供了一种导频位置信息确定装置，其特征在于，装置包括：
第一获取模块，用于获取待调试固件的安装数据和待调试固件的调试工具；
第二获取模块，用于获取调试设备内存中相互独立的只读存储分区和可读写存储分区；
第一部署模块，用于基于安装数据在只读存储分区中部署待调试固件；
第二部署模块，用于将待调试固件的调试工具部署在可读写存储分区中；
运行模块，用于运行调试工具，对只读存储分区内的待调试固件进行调试。
第三方面，本公开提出了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以实现如本公开第一方面实施例所述的固件的调试方法。
第四方面，本公开提出了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于实现如本公开第一方面实施例所述的固件的调试方法。
第五方面，本公开提出了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时用于实现如本公开第一方面实施例所述的固件的调试方法。
附图说明
为了更清楚地说明本公开实施例或背景技术中的技术方案，下面将对本公开实施例或背景技术中所需要使用的附图进行说明。
图1是本公开实施例提供的一种固件的调试方法的流程示意图；
图2是本公开实施例提供的另一种固件的调试方法流程示意图；
图3是本公开实施例提供的另一种固件的调试方法流程示意图；
图4是本公开实施例提供的另一种固件的调试方法流程示意图；
图5是本公开实施例提供的一种固件的调试装置的结构示意图；
图6是本公开实施例提供的电子设备的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
在本公开实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开实施例。在本公开实施例和所附权利要求书中所使用的单数形式的“一种”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”
出于简洁和便于理解的目的，本文在表征大小关系时，所使用的术语为“大于”或“小于”、“高于”或“低于”。但对于本领域技术人员来说，可以理解：术语“大于”也涵盖了“大于等于”的含义，“小于”也涵盖了“小于等于”的含义；术语“高于”涵盖了“高于等于”的含义，“低于”也涵盖了“低于等于”的含义。
下面结合附图对本公开所提供的固件的调试方法及其装置进行详细地介绍。
请参见图1，图1是本公开实施例提供的一种固件的调试方法的流程示意图。如图1所示，可以包括但不限于如下步骤：
S11，获取待调试固件的安装数据和待调试固件的调试工具。
需要说明的是，本公开实施例中的固件(firmware)是指设备内部保存的设备“驱动程序”，通过固件，操作系统才能按照标准的设备驱动实现特定机器的运行动作，有的系统固件可以让用户更新。系统固件可以应用在非常广泛的电子产品中，从遥控器、计算器到电脑中的键盘和硬盘，甚至工业机器人中都可见到它的身影。固件是担任着一个系统最基础 最底层工作的软件。而在硬件设备中，固件就是硬件设备的灵魂，因为一些硬件设备除了固件以外没有其它软件组成，因此固件也就决定着硬件设备的功能及性能。
本公开实施例中，为了在调试设备上对固件进行调试，可以获取到待调试固件的安装数据，以基于该安装数据在该调试设备上对待调试固件进行安装，安装完成后调试设备可以使用该固件进行驱动调试设备的操作系统运行。
本公开实施例中的待调试固件可以为任一类型的固件，例如固件可以为计算机主板上的基本输入/输出系统BIOS(Basic Input/output System)、统一可扩展固件接口(Unified Extensible Firmware Interface，UEFI)等，需要说明的是此处仅为示例，本公开实施例中对固件的类型不做限定。
可以理解的是，不同的待调试固件安装数据不同，此处不作任何限定。对应的，不同的固件需要的调试工具也可以相同或不同，具体需要根据实际的监控和调试的目的去选择和设定。
可选地，调试工具还可包括所有固件的调试内容，在针对不同的待调试固件时，可选择不同的调试选项。在本公开实施例中，调试工具可包含多种选项或者多种工具，举例来说，可包括各种trace(strace,ftrace,ptrace,gtrace)及其控制工具，还可包含异常监控工具如kpanic,softlockup,watchdog,native crash等,及其对应的日志(log)和内存(dump)工具，还可包含异系统各个状态的统计工具及提供的信息的采集工具，如procrank,netstat等，通过网络工具和自动化脚本来部署。
需要说明的是，调试工具可通过模拟用户对固件来进行自动化测试，例如可以对固件进行压力测试、异常检查等，例如调试工具可以通过打桩的方式，获取到固件的监控数据和/或监控日志，通过监控数据和/或监控日志可以识别固件是否存在异常和/或出现异常的位置等。通过监控数据和/或监控日志可以识别固件的压力情况。
S12，获取调试设备内存中相互独立的只读存储分区和可读写存储分区。
本公开实施例中，可以通过调试设备在固件发布之前，对固件进行调试，以实现向用户设备发布稳定和安全的调试后的固件。为了使得固件的调试过程并不影响固件本身的安装数据，可以从调试设备的内存中识别出相互独立的只读存储分区和可读写存储分区。需要说明的是，用户或调试人员对存储在只读存储分区的内容仅具有读操作的权限，对该内容不能进行写操作。用户或调试人员对存储在可读写存储分区的内容具有读操作和写操作的权限，也就是说可以对存储在可读写存储分区的内容进行编辑。
需要说明的是，固件一般存储于设备中的只读存储分区，例如，只读存储分区可以为电可擦可编程只读存储器(Electrically Erasable Programmable Read Only Memory，EEPROM)，一般为可由用户通过特定的刷新程序进行升级的程序。一般来说，担任着一个数码产品最基础、最底层工作的软件才可以称之为固件。
为了考虑到固件最终发布到用户设备上的安全性和稳定性，不会在只读存储分区部署设备连接工具和各种系统权限，使得不能对于相同功能版本在开发阶段进行系统稳定性监 控和调试。在本公开实施例中，调试设置可为人为设置的，也可为通过脚本自动进行操作的，此处不作任何限制。
可读写存储分区是一种可重写的存储器芯片，并且其内容在掉电的时候也不会丢失。例如，可读写存储分区可以为可擦可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)。换句话说，它是非易失性的。它通过EPROM编程器进行编程，EPROM编程器能够提供比正常工作电压更高的电压对EPROM编程。一旦经过编程，EPROM只有在强紫外线的照射下才能够进行擦除。
S13，基于安装数据在只读存储分区中部署待调试固件。
在本公开实施例中，可通过在只读存储分区中运行安装数据，以此在只读存储分区中部署待调试固件，从而实现将对应的只读存储分区的对应调试设置中涉及的功能进行调用或打开，为后续的调试操作提供基础。
系统需要识别出来部署的过程，启动引导分区里面调试设置，将这些分区替换成能有调试能力的只读存储分区的内容。通过调试工具对只读存储分区的访问权限进行管理，可确定具有访问权限的只读存储分区，从而对该具有访问权限的只读存储分区进行调试，获取监控数据。
S14，将待调试固件的调试工具部署在可读写存储分区中。
在本公开实施例中，可读写存储分区是和系统独立的，该可读写存储分区可以供用户使用。本公开提出的调试设备可以在待调试固件发布至用户设备前，对待调试固件进行异常检测，并且对待调试固件进行稳定性调试，由于该可读写存储分区与系统相互独立，在调试过程中占用这部分可读写存储分区，从而调试过程并不会影响系统的运行过程，有利于系统的稳定运行。
可选地，由于可读写存储分区是分别给用户使用的存储分区，本公开实施例中在待调试固件发布至用户设备时，还可释放调试工具占用的可读写存储分区，以将该可读写存储分区重新配置给用户来使用。本公开实施例中占用可恢复的可读写存储分区进行调试，可以避免占用不能还给用户的系统空间来做监控和调试的问题，在调试完成后可以恢复给用户使用，从而可以为用户节省更多的存储空间，提升用户的使用资源。
在本公开实施例中，在获取到调试工具后，将调试工具部署于可读写存储分区中，以便于在需要对只读存储分区内的待调试固件进行调试时，可以从该可读写存储分区中调用相关的调试工具。
S15，运行调试工具，对只读存储分区内的待调试固件进行调试。
需要说明的是，对只读存储分区内的待调试固件进行调试，可包括运行的调试工具，对固件的运行进行状态跟踪、压力测试或者是基于结果对固件的异常数据进行分析和故障排查等。
在本公开实施例中，首先获取待调试固件的安装数据和待调试固件的调试工具，然后获取调试设备内存中相互独立的只读存储分区和可读写存储分区，而后基于安装数据在只读存储分区中部署待调试固件，将待调试固件的调试工具部署在可读写存储分区中，最后 运行调试工具，对只读存储分区内的待调试固件进行调试。本公开实施例中通过将调试工具部署在可读写存储分区中，从而通过可读写存储分区中的调试工具，对只读存储分区内的待调试固件进行调试，在调试过程中由于只读存储分区与系统独立，调试过程不会影响系统运行，提高系统运行的安全性。进一步地，能够在开发阶段进行系统稳定性的调试，提供性能稳定性评估结果和各种异常的调试数据，使得系统具备高效的稳定性监控和调试能力，加速产品研发速度快速达到成熟度预期。
请参见图2，图2是本公开实施例提供的另一种固件的调试方法的流程示意图，如图2所示，调试工具的部署过程，可包括但不限于如下步骤：
S21，获取调试工具的调试源文件，并对调试源文件链接生成调试工具的可执行文件。
在编译器中预先编译调试工具的调试源文件，其中调试源文件中包括调试环境参数、调试的内容，调试参数和调试逻辑等。本公开实施例中在获取到调试源文件后，为了能使得调试源文件可以被执行，需要对调试源文件进行链接以生成调试工具的可执行文件。需要说明的是，每一个源文件即.c文件对应有零碎文件即.h文件，通过预编译(#include)把.c和.h文件整合成一个组合C文件，这个组合C文件的扩展名为.i。把组合C文件编译成汇编文件.s，目标文件为机器指令放在一个.o文件当中，单个目标文件是不能工作的，因为各个目标文件是相互支撑工作的，进一步地把各个目标文件整合为可执行文件，例如，在windows系统中可执行文件后缀为.exe，Linux系统中后缀为.out。
S22，在可读写存储分区中部署可执行文件。
通过上述链接过程生成调试工具对应的可执行文件后，可以将可执行文件部署到课读写存储分区中，由于可读写存储分区为与只读存储分区相互独立，可以与只读存储分区的待调试固件进行隔离。
可选地，调试设备可以配置有人机互动界面(User Interface，UI)，在生成可执行文件后，可以在UI界面上向用户展示可执行文件，用户可以在UI界面上方便和直观地根据实际的调试需要，对可执行文件进行选择，即对调试功能进行灵活选择，不仅可以可以增加调试的灵活性，而且提高了调试的针对性和实用性。
调试设备中有多个存储分区，不同的存储分区可能对应不同的类型，例如，类型可以包括只读存储分区和可读写存储分区。调试设备的内存可以预先划分好各个存分区的类型，并且标记各个存储分区的类型标识。本公开实施例中获取调试设备内存中相互独立的只读存储分区和可读写存储分区，包括：获取调试设备内存中存储分区的类型标识，根据类型标识，区分只读存储分区和可读写存储分区。需要说明的是类型标识为提前设定好的，此处不作任何限定。
请参见图3，图3是本公开实施例提供的另一种固件的调试方法的流程示意图，运行调试工具，对只读存储分区内的待调试固件进行调试，如图3所示，可以包括但不限于如下步骤：
S31，通过脚本启动调试工具。
需要说明的是，脚本是使用一种特定的描述性语言，依据一定的格式编写的可执行文 件。脚本语言又被称为扩建的语言,或者动态语言,是一种编程语言,用来控制软件应用程序,脚本通常是以文本(ASCⅡ)保存,只是在被调用时进行解释或者编译。当执行脚本时，计算机会执行一连串的操作。
本公开实施例中，可以预先生成启动调试工具的脚本，通过的脚本运行，实现自动调取调试工具，以对待调试固件进行调试，并采集调试过程中产生的调试数据。
需要说明的是，可通过生成脚本来进行自动化测试，将按键事件提前录制好，包括进入到各个应用的各个按键序列，并通过配置进入各个应用服务的频率、间隔和随机的各个应用服务的进入次序及次数，和进入应用和服务后随机的按键触发的可配置个数等策略，实现压力测试检查。由此实现对待调试固件的自动调试，提升调试的效率，降低待调试固件调试的成本。
S32，通过调试工具对只读存储分区的访问权限进行管理，以获取待调试固件运行过程中监控数据。
在本公开实施例中，为了获取待调试固件运行过程中监控数据，需要打开待调试固件对应的一些功能的权限。
调试工具通过识别有调试能力的只读存储分区的内容，从而对该具有访问权限的只读存储分区进行调试，获取监控数据。
需要说明的是，当脚本完全运行完毕，即运行完成调试工具中设置好的的调试事件，最终可获取到固件运行的日志数据和/或运行结果数据，从而生成待调试固件运行过程中监控数据。
S33，根据监控数据对待调试固件进行调试。
在本公开实施例中，在获取到待调试数据后，可对监控数据进行分析，确定异常数据，然后基于异常数据对待调试固件进行调试。
需要说明的是，异常数据可包含多种，举例来说，如果执行脚本过程中，出现了一些进程中无访问权限或者反馈的监控数据与预期的数据差距较大等，则需要对待调试固件进行调试，或者反馈给用户，等待进一步地优化处理。
在本公开实施例中，首先通过脚本启动调试工具，然后通过调试工具对只读存储分区的访问权限进行管理，以获取待调试固件运行过程中监控数据，最后根据监控数据对待调试固件进行调试。由此，通过脚本启动调试工具，自动启动系统压力测试，可以实现自动对待调试固件进行调试，提升调试的效率。
进一步地，在确定待调试固件的调试结束后，释放调试工具占用的可读写存储分区。
请参见图4，图4是本公开实施例提供的另一种固件的调试方法的流程示意图。如图4所示，在上述实施例的基础之上，该方法可以包括但不限于如下步骤：
S41，通过脚本启动调试工具。
关于步骤S41的具体实现可参见上述实施例中相关内容的记载，此处不再赘述。
S42，通过调试设备的内存和块设备的打桩位置，获取内存和块设备的跟踪数据。
需要说明的是，调试设备可为多形态的系统，举例来说可为车机设备、手机终端或者 嵌入式设备等，此处不作任何限定。
块设备也就是存储以“块”为单位数据的设备，比较典型的如磁盘设备、光盘或者优盘。本公开中的块设备指的是只读存储分区中块设备。
在本公开实施例中，可以在内存和块设备上进行打桩，调试工具可以基于内存和块设备内的打桩位置，对内存和块设备的运行状态进行跟踪数据。
S43，统计待调试固件的日志信息，以对待调试固件进行异常监控，获取待调试固件的异常监控数据。
待调试固件在运行过程中会产生日志信息，在本公开实施例中，可以统计待调试固件的日志信息，将日志信息与预设信息进行对比，以确定待调试固件的异常数据。例如，可以日志信息中可以包括某些指令的响应时长，若响应时长大于设定值，可以确定响应异常。再例如，日志信息中可以包括应用占用资源的时长和/或数量，占用的时长和/或占用的数量超出各自的设定值，可以确定该应用存在异常。
在获取到异常监控数据后，可以将异常监控数据通过UI界面展示给调试人员，以由调试人员进行调试和/或故障分析。
S44,模拟待调试固件的压力测试事件，基于压力测试事件对待调试固件进行压力测试，获取待调试固件的压力测试数据。
在本公开实施例中，可以通过调试工具模拟对待调试固件的压力测试事件，并执行模拟出的压力测试事件，来对待调试固件进行压力测试，获取待调试固件在执行压力测试事件时的压力测试数据。压力测试数据可以包括按键的响应，或者按键时占用的资源等。
在一些实现中，可以将压力测试事件提前录制好，其中压力测试事件可以包括各个应用的交互序列。举例说明，在应用上执行频繁的按键操作，往往会对应用造成压力，本公开中可以模拟在应用的一系列按键操作，该一系列按键操作构成压力测试事件。交互序列可以理解为应用对应的按键序列。需要说明的是，系统的压力往往来自于多个应用的频繁按键操作，本公开中可以模拟多个应用的一系列按键操作来构成压力测试事件。也就是说，该交互序列中包括进入到各个应用的时刻、在应用中的按键操作等。
本公开实施例中，调试工具可以从压力测试事件中获取各个应用的应用标识，在进入应用标识所标识的应用后，按照交互时序对所标识的应用进行交互操作，在交互操作过程中采集待测试固件在压力测试事件执行过程中的状态信息，以生成压力测试数据。需要说明的是，各个应用的应用标识为提前设定好的，并且不同的应用的应用标识可为不同，以用来区分，此处不作任何限定。
可选地，压力测试事件还包括：每个应用的测试进入频次、测试进入间隔和测试进入时序中的至少一个测试配置信息。可选地，还可以通过配置确定进入各个应用的频率，例如，可以按照一个小时内进入10次。或者，配置各个应用的时间间隔，例如包括5个应用，每个应用可以间隔10分钟进入，也可以5个应用之间的间隔时间不同，可以根据实际需求进行配置。可选地，还可以随机的确定各个应用的进入次序及次数；可选地，还可以随机确定进入应用后随机的按键操作，还可以配置按键的个数等。本公开实施例中可以通过按 键事件实现对固件的压力测试和/或异常检查。
需要说明的是，压力测试事件是固件在运行调试工具的可执行文件中的设置选项，该选项可包含多种，具体可见上述实施例中描述的内容，此处不再赘述。
步骤S42、步骤S43和步骤S44可以按照设定的顺序执行，也可以并行执行，本公开中实施例中对步骤S42、步骤S43和步骤S44的执行顺序不做限定。
在本公开实施例中，首先通过脚本启动调试工具，不仅可以对内存和块设备进行状态跟踪，确定内存和块设备是否存在异常，并且可以对日志信息进行统计获取异常监控数据，而且还可以启动系统压力测试。本公开实施例中的调试工具具有多种调试能力，使得待调试固件的调试更加灵活和准确，而且自动化调试提升调试的效率。进一步地，将调试工具部署在可读写存储分区上，该调试工具配置各自调试能力，并打桩监控内存、块设备和各种系统异常，并可自动启动系统压力测试，并提供性能稳定性评估结果，和各种异常的调试数据，使得系统具备高效的稳定性监控和调试能力，加速产品研发速度快速达到成熟度预期。
与上述几种实施例提供的固件的调试方法相对应，本公开的一个实施例还提供了一种固件的调试装置，由于本公开实施例提供的固件的调试装置与上述几种实施例提供的固件的调试方法相对应，因此上述固件的调试方法的实施方式也适用于本公开实施例提供的固件的调试装置，在下述实施例中不再详细描述。
请参见图5，为本公开实施例提供的一种固件的调试装置500的结构示意图。图5所示的通信装置500可包括第一获取模块51、第二获取模块52、第一部署模块53、第二部署模块54和运行模块55。
其中，第一获取模块51，用于获取待调试固件的安装数据和待调试固件的调试工具。
第二获取模块52，用于获取调试设备内存中相互独立的只读存储分区和可读写存储分区.
第一部署模块53，用于基于安装数据在只读存储分区中部署待调试固件。
第二部署模块54，用于将待调试固件的调试工具部署在可读写存储分区中。
运行模块55，用于运行调试工具，对只读存储分区内的待调试固件进行调试。
在本公开的一个实施例中，运行模块55，还用于：通过脚本启动调试工具；通过调试工具对只读存储分区的访问权限进行管理，以获取待调试固件运行过程中监控数据；根据监控数据对待调试固件进行调试。
在本公开的一个实施例中，运行模块55，还用于：确定待调试固件调试结束后，对只读存储分区的访问权限进行恢复。
在本公开的一个实施例中，运行模块55，还用于：确定待调试固件的调试结束后，释放调试工具占用的可读写存储分区。
在本公开的一个实施例中，第一部署模块53，还用于：获取调试工具的调试源文件，并对调试源文件链接生成调试工具的可执行文件；在可读写存储分区中部署可执行文件。
在本公开的一个实施例中，第一部署模块53，还用于：通过调试设备的内存和块设备的打桩位置，获取内存和块设备的跟踪数据；统计待调试固件的日志信息，以对待调试固件进行异常监控，获取待调试固件的异常监控数据；模拟待调试固件的压力测试事件，基于压力测试事件对待调试固件进行压力测试，获取待调试固件的压力测试数据。
在本公开的一个实施例中，第一部署模块53，还用于：启动压力测试脚本，通过压力测试脚本启动压力测试事件，其中，压力测试事件中包括每个应用对应的交互时序；从压力测试事件中获取各个应用的应用标识；在进入应用标识所标识的应用后，按照交互时序对所标识的应用进行交互操作；采集待测试固件在压力测试事件执行过程中的状态信息，以生成压力测试数据。
在本公开的一个实施例中，第二获取模块52，还用于：获取调试设备内存中存储分区的类型标识；根据类型标识，区分只读存储分区和可读写存储分区。
在本公开实施例中，首先获取待调试固件的安装数据和待调试固件的调试工具，然后获取调试设备内存中相互独立的只读存储分区和可读写存储分区，而后基于安装数据在只读存储分区中部署待调试固件，将待调试固件的调试工具部署在可读写存储分区中，最后运行调试工具，对只读存储分区内的待调试固件进行调试。本公开实施例中通过将调试工具部署在可读写存储分区中，从而通过可读写存储分区中的调试工具，对只读存储分区内的待调试固件进行调试，在调试过程中由于只读存储分区与系统独立，调试过程不会影响系统运行，提高系统运行的安全性。
进一步地，能够在开发阶段进行系统稳定性的调试，提供性能稳定性评估结果和各种异常的调试数据，使得系统具备高效的稳定性监控和调试能力，加速产品研发速度快速达到成熟度预期。
本领域技术人员还可以了解到本公开实施例列出的各种说明性逻辑块(illustrative logical block)和步骤(step)可以通过电子硬件、电脑软件，或两者的结合进行实现。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本公开实施例保护的范围。
为了实现上述实施例，本公开实施例还提出一种电子设备600，如图6所示，该电子设备600包括：处理器61和处理器通信连接的存储器62，存储器62存储有可被至少一个处理器执行的指令，指令被至少一个处理器61执行，以实现如本公开第一方面实施例的固件的调试方法。
本公开还提供一种可读存储介质，其上存储有指令，该指令被计算机执行时实现上述任一方法实施例的功能。
本公开还提供一种计算机程序产品，该计算机程序产品被计算机执行时实现上述任一方法实施例的功能。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。 当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机程序。在计算机上加载和执行所述计算机程序时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机程序可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机程序可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如，高密度数字视频光盘(digital video disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
本领域普通技术人员可以理解：本公开中涉及的第一、第二等各种数字编号仅为描述方便进行的区分，并不用来限制本公开实施例的范围，也表示先后顺序。
本公开中的至少一个还可以描述为一个或多个，多个可以是两个、三个、四个或者更多个，本公开不做限制。在本公开实施例中，对于一种技术特征，通过“第一”、“第二”、“第三”、“A”、“B”、“C”和“D”等区分该种技术特征中的技术特征，该“第一”、“第二”、“第三”、“A”、“B”、“C”和“D”描述的技术特征间无先后顺序或者大小顺序。
本公开中各表所示的对应关系可以被配置，也可以是预定义的。各表中的信息的取值仅仅是举例，可以配置为其他值，本公开并不限定。在配置信息与各参数的对应关系时，并不一定要求必须配置各表中示意出的所有对应关系。例如，本公开中的表格中，某些行示出的对应关系也可以不配置。又例如，可以基于上述表格做适当的变形调整，例如，拆分，合并等等。上述各表中标题示出参数的名称也可以采用通信装置可理解的其他名称，其参数的取值或表示方式也可以通信装置可理解的其他取值或表示方式。上述各表在实现时，也可以采用其他的数据结构，例如可以采用数组、队列、容器、栈、线性表、指针、链表、树、图、结构体、类、堆、散列表或哈希表等。
本公开中的预定义可以理解为定义、预先定义、存储、预存储、预协商、预配置、固化、或预烧制。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装 置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (13)

  1. 一种固件的调试方法，其特征在于，包括：
    获取待调试固件的安装数据和所述待调试固件的调试工具；
    获取调试设备内存中相互独立的只读存储分区和可读写存储分区；
    基于所述安装数据在所述只读存储分区中部署所述待调试固件；
    将所述待调试固件的调试工具部署在所述可读写存储分区中；
    运行所述调试工具，对所述只读存储分区内的所述待调试固件进行调试。
  2. 根据权利要求1所述的方法，其特征在于，所述运行所述调试工具，对所述只读存储分区内的所述待调试固件进行调试，包括：
    通过脚本启动所述调试工具；
    通过所述调试工具对所述只读存储分区的访问权限进行管理，以获取所述待调试固件运行过程中监控数据；
    根据所述监控数据对所述待调试固件进行调试。
  3. 根据权利要求2所述的方法，其特征在于，所述方法还包括：
    确定所述待调试固件调试结束后，对所述只读存储分区的访问权限进行恢复。
  4. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    确定所述待调试固件的调试结束后，释放所述调试工具占用的所述可读写存储分区。
  5. 根据权利要求1-4中任一项所述的方法，其特征在于，所述待调试固件的调试工具的部署过程，包括：
    获取所述调试工具的调试源文件，并对所述调试源文件链接生成所述调试工具的可执行文件；
    在所述可读写存储分区中部署所述可执行文件。
  6. 根据权利要求5所述的方法，其特征在于，所述获取所述待调试固件运行过程中监 控数据，包括：
    通过所述调试设备的内存和块设备的打桩位置，获取所述内存和块设备的跟踪数据；
    统计所述待调试固件的日志信息，以对所述待调试固件进行异常监控，获取所述待调试固件的异常监控数据；
    模拟所述待调试固件的压力测试事件，基于所述压力测试事件对所述待调试固件进行压力测试，获取所述待调试固件的压力测试数据。
  7. 根据权利要求6所述的方法，其特征在于，所述基于所述压力测试事件对所述待调试固件进行压力测试，获取所述待调试固件的压力测试数据，包括：
    启动压力测试脚本，通过所述压力测试脚本启动压力测试事件，其中，所述压力测试事件中包括每个应用对应的交互时序；
    从所述压力测试事件中获取各个应用的应用标识；
    在进入所述应用标识所标识的应用后，按照所述交互时序对所述所标识的应用进行交互操作；
    采集所述待测试固件在所述压力测试事件执行过程中的状态信息，以生成所述压力测试数据。
  8. 根据权利要求6所述的方法，其特征在于，所述压力测试事件还包括：每个应用的测试进入频次、测试进入间隔和测试进入时序中的至少一个测试配置信息。
  9. 根据权利要求1-4中任一项所述的方法，其特征在于，所述获取调试设备内存中相互独立的只读存储分区和可读写存储分区，包括：
    获取所述调试设备内存中存储分区的类型标识；
    根据所述类型标识，区分所述只读存储分区和所述可读写存储分区。
  10. 一种固件的调试装置，其特征在于，包括：
    第一获取模块，用于获取待调试固件的安装数据和所述待调试固件的调试工具；
    第二获取模块，用于获取调试设备内存中相互独立的只读存储分区和可读写存储分区；
    第一部署模块，用于基于所述安装数据在所述只读存储分区中部署所述待调试固件；
    第二部署模块，用于将所述待调试固件的调试工具部署在所述可读写存储分区中；
    运行模块，用于运行所述调试工具，对所述只读存储分区内的所述待调试固件进行调试。
  11. 一种电子设备，其特征在于，包括存储器、处理器；
    其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，使如权利要求1至9中任一项所述的方法被实现。
  12. 一种计算机可读存储介质，用于存储有指令，当指令被执行时，使如权利要求1至9中任一项所述的方法被实现。
  13. 一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1至9中任一项所述的方法。
PCT/CN2022/099240 2022-06-16 2022-06-16 一种固件的调试方法及其装置 Ceased WO2023240558A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202280004135.8A CN117597668B (zh) 2022-06-16 2022-06-16 一种固件的调试方法及其装置
PCT/CN2022/099240 WO2023240558A1 (zh) 2022-06-16 2022-06-16 一种固件的调试方法及其装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/099240 WO2023240558A1 (zh) 2022-06-16 2022-06-16 一种固件的调试方法及其装置

Publications (1)

Publication Number Publication Date
WO2023240558A1 true WO2023240558A1 (zh) 2023-12-21

Family

ID=89192810

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/099240 Ceased WO2023240558A1 (zh) 2022-06-16 2022-06-16 一种固件的调试方法及其装置

Country Status (2)

Country Link
CN (1) CN117597668B (zh)
WO (1) WO2023240558A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10133654B1 (en) * 2017-02-28 2018-11-20 American Megatrends, Inc. Firmware debug trace capture
CN109189485A (zh) * 2018-08-08 2019-01-11 烽火通信科技股份有限公司 一种嵌入式设备的系统启动管理、操作系统配置方法
WO2020145973A1 (en) * 2019-01-10 2020-07-16 Hewlett-Packard Development Company, L.P. Event logs with firmware debug information
CN113645052A (zh) * 2020-04-27 2021-11-12 中移物联网有限公司 一种固件调试方法及相关设备
CN114035855A (zh) * 2021-09-30 2022-02-11 鸣芯信息科技(上海)有限公司 固件的调试方法、装置、终端及存储介质
CN114036047A (zh) * 2021-11-08 2022-02-11 南京百敖软件有限公司 一种基于串口的固件即时调试器的实现方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7171653B2 (en) * 2003-06-03 2007-01-30 Hewlett-Packard Development Company, L.P. Systems and methods for providing communication between a debugger and a hardware simulator
US10504605B2 (en) * 2017-11-02 2019-12-10 National Tsing Hua University Method and system for testing firmware of solid-state storage device, and electronic apparatus
CN109753453A (zh) * 2018-12-26 2019-05-14 北京可信华泰信息技术有限公司 一种存储隔离的可信系统
CN111694585A (zh) * 2020-06-02 2020-09-22 深圳Tcl数字技术有限公司 替换系统分区文件的方法、系统、终端和存储介质
CN111949529B (zh) * 2020-08-06 2024-03-22 曙光信息产业(北京)有限公司 系统调试方法、装置、计算机设备和存储介质
CN112328281A (zh) * 2020-11-06 2021-02-05 苏州浪潮智能科技有限公司 一种服务器固件刷新方法和装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10133654B1 (en) * 2017-02-28 2018-11-20 American Megatrends, Inc. Firmware debug trace capture
CN109189485A (zh) * 2018-08-08 2019-01-11 烽火通信科技股份有限公司 一种嵌入式设备的系统启动管理、操作系统配置方法
WO2020145973A1 (en) * 2019-01-10 2020-07-16 Hewlett-Packard Development Company, L.P. Event logs with firmware debug information
CN113645052A (zh) * 2020-04-27 2021-11-12 中移物联网有限公司 一种固件调试方法及相关设备
CN114035855A (zh) * 2021-09-30 2022-02-11 鸣芯信息科技(上海)有限公司 固件的调试方法、装置、终端及存储介质
CN114036047A (zh) * 2021-11-08 2022-02-11 南京百敖软件有限公司 一种基于串口的固件即时调试器的实现方法

Also Published As

Publication number Publication date
CN117597668B (zh) 2025-02-07
CN117597668A (zh) 2024-02-23

Similar Documents

Publication Publication Date Title
Chen et al. An exploratory study of performance regression introducing code changes
US9146831B2 (en) Sampling based runtime optimizer for efficient debugging of applications
KR20140053542A (ko) 내장형 소프트웨어의 자동 테스트 장치, 자동 테스트 방법 및 테스트 시나리오 작성방법
US20200104244A1 (en) Scriptless software test automation
US8850407B2 (en) Test script generation
US10846206B2 (en) Adaptive software testing
US9195562B2 (en) Recording external processes
CA2811617C (en) Commit sensitive tests
GB2460407A (en) Using coverage data to choose software regression tests
US12197316B2 (en) Automated decoupling of unit tests
US20070168736A1 (en) Breakpoint groups
US20050049814A1 (en) Binding a GUI element to a control in a test executive application
US11163924B2 (en) Identification of changes in functional behavior and runtime behavior of a system during maintenance cycles
US8997048B1 (en) Method and apparatus for profiling a virtual machine
US20200272553A1 (en) Configurable system for interaction with system or processor states in development tools
US11226890B2 (en) Optimal selection of relevant testing parameters
CN112527312B (zh) 一种嵌入式系统的测试方法和测试装置
WO2023240558A1 (zh) 一种固件的调试方法及其装置
JP7750409B2 (ja) 情報処理装置、試験方法、及び試験プログラム
CN115017059B (zh) 图形用户界面程序的模糊测试方法及系统
CN118885380A (zh) 测试方法、计算设备及计算机程序产品
CN116225952A (zh) 软件修改性能测试方法、系统、设备及存储介质
US10922249B2 (en) Input/output control code filter
CN113031964A (zh) 一种大数据应用的管理方法、装置、设备及存储介质
US8898636B1 (en) Method and apparatus for testing an application running in a virtual machine

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 202280004135.8

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22946247

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWG Wipo information: grant in national office

Ref document number: 202280004135.8

Country of ref document: CN

122 Ep: pct application non-entry in european phase

Ref document number: 22946247

Country of ref document: EP

Kind code of ref document: A1