CN115904809A - Data recovery method and electronic equipment - Google Patents

Data recovery method and electronic equipment Download PDF

Info

Publication number
CN115904809A
CN115904809A CN202211511754.4A CN202211511754A CN115904809A CN 115904809 A CN115904809 A CN 115904809A CN 202211511754 A CN202211511754 A CN 202211511754A CN 115904809 A CN115904809 A CN 115904809A
Authority
CN
China
Prior art keywords
firmware
data
storage medium
controller
interface
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.)
Pending
Application number
CN202211511754.4A
Other languages
Chinese (zh)
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.)
Lenovo Beijing Ltd
Original Assignee
Lenovo Beijing 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 Lenovo Beijing Ltd filed Critical Lenovo Beijing Ltd
Priority to CN202211511754.4A priority Critical patent/CN115904809A/en
Publication of CN115904809A publication Critical patent/CN115904809A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Retry When Errors Occur (AREA)

Abstract

The application provides a data recovery method, which is applied to a first controller of equipment and comprises the following steps: the first controller acquires firmware backup data from a first storage medium through a first interface under the condition that the equipment is determined to be abnormally operated; the equipment operation abnormity at least comprises equipment startup failure; sending the firmware backup data to a second storage medium through a second interface to enable the second storage medium to perform data recovery on target firmware of a device stored by the second storage medium through the firmware backup data, wherein a second controller of the device is capable of operating the device based on the target firmware in the second storage medium. Simultaneously, this application still provides an electronic equipment.

Description

Data recovery method and electronic equipment
Technical Field
The present disclosure relates to data recovery technologies, and in particular, to a data recovery method and an electronic device.
Background
At present, when firmware of equipment is recovered after upgrading failure of the firmware of the equipment, one method is realized by two storage media based on a second interface and an enhanced embedded controller, so that the embedded controller needs strong processing energy, and one storage medium is independently used for data backup, so that the cost is very high; the other is realized by a hard disk partition and a storage medium based on a second interface, wherein the backup boot code is reserved in the storage medium, so that a larger-capacity storage medium is required for realization, thereby also resulting in higher cost.
Disclosure of Invention
The technical scheme of the application is realized as follows:
according to an aspect of the present application, there is provided a data recovery method applied to a first controller of a device, the method including:
the first controller acquires firmware backup data from a first storage medium through a first interface under the condition that the equipment is determined to be abnormally operated; the equipment operation abnormity at least comprises equipment startup failure;
sending the firmware backup data to a second storage medium through a second interface to enable the second storage medium to perform data recovery on target firmware of a device stored by the second storage medium through the firmware backup data, wherein a second controller of the device is capable of operating the device based on the target firmware in the second storage medium.
In the foregoing solution, before the obtaining the firmware backup data from the first storage medium through the first interface, the method further includes:
the first controller acquires firmware data from the second storage medium through the second interface under the condition that the equipment is determined to operate normally, wherein the firmware data at least comprises first firmware data for controlling the first controller to operate;
and sending the firmware data to the first storage medium through the first interface so as to store the firmware data through a target storage area of the first storage medium, thereby forming the firmware backup data.
In the above solution, the first controller is different from the second controller, and the difference at least includes one of:
under the condition that the equipment fails to be started, the first controller can operate, and the second controller cannot operate;
under the condition that the equipment operates normally, the first controller cannot execute an operating instruction of target firmware based on the firmware data, and the second controller can acquire the firmware data from the second storage medium and execute the operating instruction of the target firmware based on the firmware data;
under the condition that the equipment runs normally, the first controller cannot execute the running instruction of the operating system, and the second controller can acquire system data from the first storage medium and execute the running instruction of the operating system based on the system data.
In the foregoing solution, before the sending the firmware data to the first storage medium through the first interface, the method further includes:
verifying the first firmware data;
if the first firmware data fails to be verified, acquiring first firmware backup data for controlling the first controller to run from the first storage medium;
and performing data recovery on the firmware controlling the operation of the first controller through the first firmware backup data.
In the above solution, the firmware backup data sent to the second storage medium through the second interface at least includes second firmware data of the bios, so that data recovery can be performed on the firmware of the bios through the second firmware data in the second storage medium.
In the above scheme, the firmware backup data sent to the second storage medium through the second interface at least includes third firmware data driven by the management engine, so that data recovery can be performed on the firmware driven by the management engine through the third firmware data in the second storage medium.
In the foregoing solution, before the obtaining the firmware backup data from the first storage medium through the first interface, the method further includes:
the first controller controls the first storage medium to be powered on through the first interface;
and when the first storage medium is in a power-on state, the firmware backup data is acquired from the first storage medium through the first interface.
In the foregoing solution, before the first controller obtains the firmware backup data from the first storage medium through the first interface, the method further includes:
the first controller establishes communication connection with the first storage medium through a first communication protocol of a first interface;
under the condition that the communication connection is successfully established, the firmware backup data is acquired from the first storage medium through a second communication protocol of the first interface;
and the data transmission rate corresponding to the second communication protocol is greater than that of the first communication protocol.
According to another aspect of the present application, there is provided an electronic device including:
the first controller is used for acquiring firmware backup data from a first storage medium through a first interface under the condition that the equipment is determined to be abnormally operated; sending the firmware backup data to a second storage medium through a second interface; the equipment operation abnormity at least comprises equipment startup failure;
a first storage medium connected to the first controller through the first interface, and capable of storing firmware backup data;
the second storage medium is connected with the first controller through the second interface, and can receive the firmware backup data sent by the first controller through the second interface when the equipment is abnormally operated so as to perform data recovery on target firmware of the equipment through the firmware backup data;
a second controller capable of operating the device based on a target firmware in the firmware data in the second storage medium.
In the foregoing solution, the second controller is different from the first controller, and the difference at least includes one of:
under the condition that the equipment fails to start, the first controller can operate, and the second controller cannot operate;
under the condition that the equipment runs normally, the first controller cannot execute a running instruction of an operating system, and the second controller can acquire system data from the first storage medium and execute the running instruction of the operating system based on the system data;
under the condition that the equipment operates normally, the first controller cannot execute an operating instruction of target firmware based on the firmware data, and the second controller can acquire the firmware data from the second storage medium and execute the operating instruction of the target firmware based on the firmware data.
According to the data recovery method and the electronic device, the firmware data is backed up by using the first storage medium and is connected with the first controller through the first interface. If the equipment runs abnormally, the first controller acquires the firmware backup data from the first storage medium through the first interface and sends the firmware backup data to the second storage medium through the second interface, so that the second storage medium performs data recovery on the target firmware of the equipment stored in the second storage medium through the firmware backup data. Therefore, the firmware data backup is carried out through the first storage medium, the storage space of the second storage medium based on the second interface communication is not occupied, and the cost of the second storage medium can be saved.
Drawings
FIG. 1 is a first schematic diagram illustrating a first implementation process of data recovery in the present application;
FIG. 2 is a second schematic diagram illustrating a data recovery process according to the present application;
FIG. 3 is a first schematic diagram of the electronic device according to the present application;
FIG. 4 is a schematic structural diagram of a data recovery apparatus according to the present application;
fig. 5 is a structural schematic diagram of an electronic device in the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions in the embodiments of the present application will be described clearly and completely with reference to the accompanying drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application. In the present application, the embodiments and features of the embodiments may be arbitrarily combined with each other without conflict. The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.
The technical solution of the present application is further described in detail with reference to the drawings and specific embodiments of the specification.
Fig. 1 is a schematic view of a flow implementation of a data recovery method in the present application, where the method is applied to a first controller of a device, and as shown in fig. 1, the method includes:
step 101, the first controller acquires firmware backup data from a first storage medium through a first interface under the condition that the equipment is determined to be abnormally operated; the equipment operation abnormity at least comprises equipment startup failure;
in the application, the first storage medium may be a Solid State Disk (SSD), and the first storage medium may have a plurality of storage blocks, where one storage block may be a main storage area for storing firmware backup data, and other storage blocks may be secondary storage areas for storing the firmware backup data, and the first controller may acquire the firmware backup data from the main storage block of the first storage medium through the first interface when determining that the device is abnormal in operation; and if the firmware backup data fails to be verified, acquiring second firmware backup data from the slave storage block of the first storage medium through the first interface.
Here, the slave storage blocks may be one or more, and are not limited herein, as long as when the firmware backup data stored in the master storage block is abnormal or damaged, the data recovery of the target firmware may be performed by the firmware backup data stored in the slave storage block.
In this application, when the first controller verifies the firmware backup data acquired from the first storage medium, hash calculation may be specifically performed on the firmware backup data to obtain a first hash value; then matching the first hash value with a second hash value stored in the first controller to obtain a matching result; and if the matching result represents that the first hash value and the second hash value are successfully matched, determining that the firmware backup data passes verification, otherwise, determining that the firmware backup data fails to verify, and representing that the firmware backup data is abnormal or damaged.
In the application, the first controller can also monitor the starting-up time of the equipment; and if the starting-up time is greater than or equal to the time threshold, determining that the equipment is abnormally operated, and acquiring the firmware backup data from the first storage medium through the first interface. And if the starting-up time is less than the time threshold, determining that the equipment normally operates. The first controller may further obtain firmware data from a second storage medium through a second interface under the condition that it is determined that the device operates normally, and then send the firmware data to the first storage medium through the first interface, so as to store the firmware data through a target storage area of the first storage medium, thereby forming the firmware backup data.
Here, the firmware data acquired by the first controller from the second storage medium may include at least first firmware data for controlling the first controller to operate.
In the application, when a first controller sends firmware data to a first storage medium through a first interface, it is first required to ensure that the firmware of the first controller is normal, and therefore, if the firmware data includes the first firmware data, the first controller may further calculate a hash value of the first firmware data, match the hash value of the first firmware data with the hash value stored in the first controller, and if a matching result indicates that the first firmware data is failed to be verified, obtain first firmware backup data for controlling the first controller to operate from the first storage medium through the first interface; and performing data recovery on the firmware operated by the first controller through the first firmware backup data. And if the matching result represents that the first firmware data is successfully verified, directly sending the firmware data containing the first firmware data to a first storage medium through the first interface so that the first storage medium performs data backup on the firmware data.
Here, the first Controller may specifically refer to an Embedded Controller (EC) and a KeyBoard Controller (KBC KeyBoard Controller), and the first interface may be at least one of an I2C Bus, an I3C Bus, and a Universal Serial Bus (USB).
In the application, when the first controller acquires the firmware backup data from the first storage medium through the first interface, the first controller may further establish a communication connection with the first storage medium through a first communication protocol of the first interface; under the condition that the communication connection is successfully established, the firmware backup data is acquired from the first storage medium through a second communication protocol of the first interface; and the data transmission rate corresponding to the second communication protocol is greater than that of the first communication protocol.
For example, when the first storage medium supports connection of an I2C bus and an I3C bus, the first controller performs handshake connection with the first storage medium through the I2C bus, and performs data transmission with the first storage medium through the I3C bus after successful handshake. Thus, it is possible to improve data transmission efficiency when data transmission is performed, and to reduce power consumption when data transmission is not performed.
In this application, when the first storage medium supports an I2C bus and/or an I3C bus connection, the first controller may further control the first storage medium to be powered on through the I2C bus and/or the I3C bus, and acquire the firmware backup data from the first storage medium through the I2C bus and/or the I3C bus in a state where the first storage medium is powered on.
In this application, the first storage medium may further support an Out of Band (OOB) transport protocol, and the first controller may retrieve the firmware backup data from the first storage medium through the OOB in an emergency.
And step 102, sending the firmware backup data to a second storage medium through a second interface so that the second storage medium can perform data recovery on target firmware of a device stored in the second storage medium through the firmware backup data, wherein a second controller of the device can run the device based on the target firmware in the second storage medium.
In this application, after the first controller acquires the firmware backup data from the first storage medium through the first interface, if the firmware backup data passes verification, the first controller sends the firmware backup data to the second storage medium through the second interface, so that the second storage medium can perform data recovery on the target firmware of the device stored in the second storage medium through the firmware backup data.
Here, when the first controller verifies the firmware backup data, hash calculation may be specifically performed on the firmware backup data to obtain a first hash value; then matching the first hash value with a second hash value stored in the first controller to obtain a matching result; and if the matching result represents that the first hash value and the second hash value are successfully matched, determining that the firmware backup data passes verification, otherwise, determining that the firmware backup data fails verification, representing that the firmware backup data is abnormal, and not executing sending of the firmware backup data to a second storage medium.
Here, the second storage medium may refer to a memory connected to a Serial Peripheral Interface (SPI), such as an SPI flash memory, and the second Interface may also be an Enhanced Serial Peripheral Interface (eSPI), and when the second storage medium receives the firmware backup data sent by the first controller through the second Interface, the second controller of the device may perform data recovery on the target firmware of the device based on the firmware backup data in the second storage medium to operate the device.
In this application, the second controller of the device is different from the first controller, and the second controller may specifically be a Central Processing Unit (CPU), and the difference between the second controller and the first controller may be at least represented in the following cases:
1) Under the condition that the equipment fails to be started, the first controller can operate, and the second controller cannot operate;
2) Under the condition that the equipment runs normally, the first controller cannot execute the running instruction of the target firmware based on the firmware data, and the second controller can acquire the firmware data from the second storage medium and execute the running instruction of the target firmware of the equipment based on the firmware data;
3) Under the condition that the equipment runs normally, the first controller cannot execute the running instruction of the operating system, and the second controller can acquire system data from the first storage medium and execute the running instruction of the operating system based on the system data.
In this application, the first controller may at least include second firmware data of a Basic Input Output System (BIOS) in the firmware backup data sent to the second storage medium through the second interface, so that, in the case that firmware upgrade of the BIOS fails or operation fails or the BIOS firmware data is damaged, the BIOS may perform data recovery on the firmware of the BIOS through the second firmware data in the second storage medium after restarting the System.
In this application, the first controller may include at least third firmware data of a Management Engine driver (ME) in the firmware backup data sent to the second storage medium through the second interface, so that, in a case that an upgrade of firmware data of the intel Management Engine driver fails or an operation of the firmware data fails or the ME firmware data is damaged, the ME may perform data recovery on the intel Management Engine driver firmware through the third firmware data in the second storage medium after the system is restarted.
In one embodiment, firmware data backup is performed through the SSD, a storage space of the SPI flash memory is not occupied, the cost of the SPI flash memory can be saved, and data recovery can be performed on the firmware of the equipment under the condition that the equipment is failed to boot by using the EC to be connected with the first storage medium through the I2C bus and/or the I3C bus, so that normal operation of the equipment is ensured. Because the size of the firmware is M Bytes level and the size of the SSD is G Bytes level, the occupied space of the firmware data for the SSD can be ignored, and the space limit of the SPI flash memory can be broken through for the expansion of the functions later, thereby realizing more user scene functions.
Fig. 2 is a schematic diagram of a second implementation of the data recovery process in the present application, as shown in fig. 2,
step 201, an EC ROM reads EC firmware and judges whether the EC firmware is damaged;
here, if the EC firmware is corrupted, go to step 202; if the EC firmware is normal, go to step 204;
step 202, the EC reads EC firmware data from the secondary copy in its image;
here, data recovery is performed on the EC firmware by the EC firmware data;
step 203, the EC starts a watchdog timer;
step 204, an encryption Service Engine (CSE, cryptographic Service Engine) ROM obtains CSE firmware data from the SPI flash memory;
here, the CSE is used to implement encryption and decryption functions.
Step 205, the CSE ROM judges whether the CSE firmware is damaged;
here, if the CSE firmware is corrupted, go to step 206; if the CSE firmware is normal, go to step 207;
step 206, booting the system to restart;
step 207, an Access Control Module (ACM) acquires ACM firmware data from the SPI flash memory;
here, the ACM is used to control the security of the security descriptor and access token.
Step 208, judging whether the ACM firmware is damaged;
here, if the ACM firmware is corrupted, go to step 206; if the ACM firmware is normal, go to step 209;
step 209, the BIOS obtains BIOS firmware data from the SPI flash memory;
step 210, judging whether the BIOS firmware is damaged;
here, if the BIOS firmware is damaged, go to step 206; if the BIOS firmware is normal, go to step 211;
step 211, BIOS determines whether the CSE data indicated by FWSTS is damaged;
if the CSE data indicated by FWSTS is normal, go to step 212; if the CSE data indicated by FWSTS is corrupted, go to step 213;
step 212, BIOS continues booting and sends a WDT (watchdog timer) command to the EC before OS boots;
step 213, BIOS sends command to EC to restore CSE data;
step 214, the EC acquires CSE firmware backup data from a data backup area of the SSD;
step 215, the CSE restores the CSE data to the main area according to the CSE firmware backup data;
step 216, the CSE issues a global reset command;
step 217, the EC watchdog timer expires;
step 218, the EC initiates a recovery process;
step 219, ec sends NVME _ MI _ Log _ page _ read0 command for each 4K block to SSD;
in step 220, the SSD responds to the NVME _ MI _ Log _ page _ read0 command;
step 221, the EC starts to calculate the cumulative hash value of the image;
step 222, the EC identifies the image offset on the SPI flash from the header;
step 223, the EC copies the data content of each 4K block from the MVME to the SPI flash memory position;
here, the data content of each 4K block can perform firmware recovery on BIOS firmware and ME firmware in the SPI flash.
Step 224, ec verifies the cumulative hash value from the hash value stored in the header;
step 225, judging whether the hash values of the firmware are matched;
here, if the hash values of the firmware do not match, go to step 226; if the hash value of the firmware is successfully matched, go to step 228;
step 226, determining that the image used to recover the data is corrupted;
step 227, EC stops the recovery process and suspends the error code;
in step 228, the EC issues a global reset command.
Fig. 3 is a schematic structural composition diagram of an electronic device in the present application, as shown in fig. 3, the electronic device includes:
a first controller 301, configured to, in a case where it is determined that the device is abnormally operated, obtain firmware backup data from a first storage medium 302 through a first interface; and sends the firmware backup data to the second storage medium 303 through the second interface; the equipment operation abnormity at least comprises equipment startup failure;
a first storage medium 302 connected to the first controller 301 through the first interface, and capable of storing firmware backup data;
the second storage medium 303 is connected to the first controller 301 through the second interface, and is capable of receiving the firmware backup data sent by the first controller 301 through the second interface when the device is abnormally operated, so as to perform data recovery on target firmware of the device through the firmware backup data;
a second controller 304 capable of operating the device based on the target firmware in the firmware data in the second storage medium 303.
Here, the second controller 304 may be a CPU provided in a Chip On Chip (SOC), or may be directly an SOC Chip. The second controller 304 is connected to the first storage medium 302 through a PCIE interface, and may acquire operating system data from the first storage medium 302 through the PCIE interface, so as to execute an operating instruction to the operating system through the operating system data. The second controller 304 may also be connected to the second storage medium 303 through an eSPI interface, and is configured to acquire firmware data from the second storage medium 303 and execute an execution instruction of the target firmware based on the firmware data.
Here, the second controller 304 is different from the first controller 301, and the difference includes at least one of:
in the case of a power-on failure of the device, the first controller 301 is operable, and the second controller 304 is inoperable;
in the case that the device operates normally, the first controller 301 cannot execute an operating instruction to the operating system, and the second controller 304 can acquire system data from the first storage medium and execute the operating instruction to the operating system based on the system data;
in a case where the apparatus is operating normally, the first controller 301 cannot execute an operation instruction for target firmware based on the firmware data, and the second controller 304 can acquire firmware data from the second storage medium 303 and execute an operation instruction for the target firmware based on the firmware data.
Here, the first controller 301 may be specifically an EC, and is connected to communicate with the first storage medium 302 through an I2C bus and/or an I3C bus, and the first controller 301 is connected to communicate with the second storage medium through an eSPI interface, where the first controller may be the EC, the first storage medium may be an SSD, and the second storage medium may be an SPI flash memory.
In a preferred embodiment, the first controller 301 is further configured to, when it is determined that the device operates normally, obtain firmware data from the second storage medium 303 through the second interface, where the firmware data at least includes first firmware data that controls the first controller 301 to operate; and is configured to send the firmware data to the first storage medium 302 through the first interface, so as to store the firmware data through a target storage area of the first storage medium 302, and form the firmware backup data.
In a preferred embodiment, the first controller 301 is further configured to verify the first firmware data; if the first firmware data fails to be verified, acquiring first firmware backup data for controlling the first controller to run from the first storage medium; and the firmware recovery module is used for performing data recovery on the firmware operated by the first controller through the first firmware backup data.
Preferably, the firmware backup data sent by the first controller 301 to the second storage medium through the second interface includes at least second firmware data of the bios, so that data recovery can be performed on the firmware of the bios through the second firmware data in the second storage medium.
In a preferred embodiment, the firmware backup data sent by the first controller 301 to the second storage medium through the second interface at least includes third firmware data driven by the management engine, so that the firmware driven by the management engine can be subjected to data recovery through the third firmware data in the second storage medium.
As shown in fig. 3, the firmware data stored in the SPI flash memory includes: descriptor of target firmware (Descriptor), network card firmware (GBE) data, EC firmware data, BIOS firmware data, and CSME firmware data.
The SSD may have a master storage block a and a slave storage block B therein for backup storage of firmware data stored in the SPI flash memory.
Preferably, the first controller 301 is further configured to control the first storage medium to be powered on through the first interface (e.g., I2C and/or I3C); and the firmware backup data is acquired from the first storage medium through the first interface when the first storage medium is in a power-on state.
In a preferred embodiment, the first controller 301 is further configured to establish a communication connection with the first storage medium through a first communication protocol of a first interface; the firmware backup data is acquired from the first storage medium through a second communication protocol of the first interface under the condition that the communication connection is successfully established; and the data transmission rate corresponding to the second communication protocol is greater than that of the first communication protocol.
For example, the first communication protocol is an I2C protocol and the second communication protocol is an I3C protocol.
According to the SPI flash memory, data backup is carried out on firmware data stored in the SPI flash memory through the SSD, the chip cost and the storage space of the SPI flash memory can be saved, and the storage capacity of the firmware data is small and can be ignored compared with that of the SSD. And the EC is connected with the SSD through the I2C bus and/or the I3C bus, so that the data recovery of the target firmware can be realized under the condition that the equipment fails to boot.
It should be noted that: the electronic device provided by the above embodiment and the data recovery method provided by the above embodiment belong to the same concept, and the specific implementation process thereof is described in the method embodiment, which is not described herein again.
Fig. 4 is a schematic structural diagram of a data recovery apparatus in the present application, and as shown in fig. 4, the apparatus includes:
an obtaining unit 401, configured to obtain, through a first interface, firmware backup data from a first storage medium when it is determined that the device is abnormally operated; the equipment operation abnormity at least comprises equipment startup failure;
a sending unit 402, configured to send the firmware backup data to a second storage medium through a second interface, so that the second storage medium can perform data recovery on target firmware of a device stored in the second storage medium through the firmware backup data, where a second controller of the device can run the device based on the target firmware in the second storage medium.
Here, the firmware backup data transmitted to the second storage medium through the second interface includes at least second firmware data of the bios, so that the firmware of the bios can be restored by the second firmware data in the second storage medium.
Here, at least third firmware data driven by a management engine is further included in the firmware backup data sent to the second storage medium through the second interface, so that data recovery can be performed on the firmware driven by the management engine through the third firmware data in the second storage medium.
In a preferred embodiment, the obtaining unit 401 is further configured to obtain, through the second interface, firmware data from the second storage medium under the condition that it is determined that the device operates normally, where the firmware data at least includes first firmware data that controls the first controller to operate;
a sending unit 402, further configured to send the firmware data to the first storage medium through the first interface, so as to store the firmware data through a target storage area of the first storage medium, and form the firmware backup data.
In a preferred embodiment, the apparatus further comprises: an authentication unit 403 and a recovery unit 404;
specifically, the verification unit 403 is configured to verify the first firmware data;
the obtaining unit 401 is further configured to obtain, from the first storage medium, first firmware backup data for controlling the first controller to operate if the first firmware data fails to be verified;
a restoring unit 404, configured to perform data restoration on the firmware executed by the first controller through the first firmware backup data.
In a preferred embodiment, the apparatus further comprises:
a control unit 405, configured to control the first storage medium to be powered on through the first interface;
the obtaining unit 401 is further configured to obtain the firmware backup data from the first storage medium through the first interface when the first storage medium is in a powered-on state.
It should be noted that: in the data recovery apparatus provided in the foregoing embodiment, when performing data recovery, only the division of each program module is described as an example, and in practical applications, the processing allocation may be completed by different program modules according to needs, that is, the internal structure of the apparatus may be divided into different program modules to complete all or part of the processing described above. In addition, the data recovery apparatus provided in the foregoing embodiment and the data recovery method provided in the foregoing embodiment belong to the same concept, and specific implementation processes thereof are described in the method embodiment and are not described herein again.
An embodiment of the present application further provides an electronic device, including: a processor and a memory for storing a computer program capable of running on the processor,
wherein the processor is configured to perform any one of the method steps of the above-mentioned processing method when running the computer program.
Fig. 5 is a schematic structural component diagram of an electronic device 500 in the present application, where the electronic device may be a mobile phone, a computer, a digital broadcast terminal, an information transceiver device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, or other terminals. The electronic device 500 shown in fig. 5 includes: at least one processor 501, memory 502, at least one network interface 504, and a user interface 503. The various components in the electronic device 500 are coupled together by a bus system 505. It is understood that the bus system 505 is used to enable connection communications between these components. The bus system 505 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 505 in FIG. 5.
The user interface 503 may include a display, a keyboard, a mouse, a trackball, a click wheel, a key, a button, a touch pad, a touch screen, or the like, among others.
It will be appreciated that the memory 502 can be either volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. Among them, the nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a magnetic random access Memory (FRAM), a magnetic random access Memory (Flash Memory), a magnetic surface Memory, an optical Disc, or a Compact Disc Read-Only Memory (CD-ROM); the magnetic surface storage may be disk storage or tape storage. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of illustration and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), synchronous Static Random Access Memory (SSRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), enhanced Synchronous Dynamic Random Access Memory (ESDRAM), enhanced Synchronous Dynamic Random Access Memory (Enhanced DRAM), synchronous Dynamic Random Access Memory (SLDRAM), direct Memory (DRmb Access), and Random Access Memory (DRAM). The memory 502 described in embodiments herein is intended to comprise, without being limited to, these and any other suitable types of memory.
The memory 502 in the embodiments of the present application is used to store various types of data to support the operation of the electronic device 500. Examples of such data include: any computer programs for operating on the electronic device 500, such as an operating system 5021 and application programs 5022; contact data; telephone book data; a message; a picture; audio, etc. The operating system 5021 includes various system programs, such as a framework layer, a core library layer, a driver layer, and the like, for implementing various basic services and processing hardware-based tasks. The application 5022 may contain various applications such as a Media Player (Media Player), a Browser (Browser), etc. for implementing various application services. A program for implementing the method according to the embodiment of the present application may be included in the application 5022.
The method disclosed in the embodiments of the present application may be applied to the processor 501, or implemented by the processor 501. The processor 501 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 501. The Processor 501 may be a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. The processor 501 may implement or perform the methods, steps, and logic blocks disclosed in the embodiments of the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium located in the memory 502, and the processor 501 reads the information in the memory 502 and performs the steps of the aforementioned methods in conjunction with its hardware.
In an exemplary embodiment, the electronic Device 500 may be implemented by one or more Application Specific Integrated Circuits (ASICs), DSPs, programmable Logic Devices (PLDs), complex Programmable Logic Devices (CPLDs), field Programmable Gate Arrays (FPGAs), general purpose processors, controllers, micro Controllers (MCUs), microprocessors (microprocessors), or other electronic components for performing the aforementioned methods.
In an exemplary embodiment, the present application further provides a computer readable storage medium, such as the memory 502 comprising a computer program, which can be executed by the processor 501 of the electronic device 500 to perform the steps of the foregoing method. The computer readable storage medium can be Memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash Memory, magnetic surface Memory, optical disk, or CD-ROM; or a variety of devices, such as mobile phones, computers, tablet devices, personal digital assistants, etc., that include one or any combination of the above memories.
A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method steps of any of the above-mentioned processing methods.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.
Features disclosed in several of the product embodiments provided in the present application may be combined in any combination to yield new product embodiments without conflict.
The features disclosed in the several method or apparatus embodiments provided in the present application may be combined arbitrarily, without conflict, to arrive at new method embodiments or apparatus embodiments.
The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (10)

1. A data recovery method applied to a first controller of a device, the method comprising:
the first controller acquires firmware backup data from a first storage medium through a first interface under the condition that the equipment is determined to be abnormally operated; the equipment operation abnormity at least comprises equipment startup failure;
sending the firmware backup data to a second storage medium through a second interface to enable the second storage medium to perform data recovery on target firmware of a device stored by the second storage medium through the firmware backup data, wherein a second controller of the device is capable of operating the device based on the target firmware in the second storage medium.
2. The method of claim 1, wherein prior to said retrieving the firmware backup data from the first storage medium via the first interface, the method further comprises:
the first controller acquires firmware data from the second storage medium through the second interface under the condition that the equipment is determined to operate normally, wherein the firmware data at least comprises first firmware data for controlling the first controller to operate;
and sending the firmware data to the first storage medium through the first interface so as to store the firmware data through a target storage area of the first storage medium, thereby forming the firmware backup data.
3. The method of claim 1, wherein the first controller is different from the second controller, the difference comprising at least one of:
under the condition that the equipment fails to be started, the first controller can operate, and the second controller cannot operate;
under the condition that the equipment runs normally, the first controller cannot execute a running instruction of target firmware based on the firmware data, and the second controller can acquire the firmware data from the second storage medium and execute the running instruction of the target firmware based on the firmware data;
under the condition that the equipment runs normally, the first controller cannot execute the running instruction of the operating system, and the second controller can acquire system data from the first storage medium and execute the running instruction of the operating system based on the system data.
4. The method of claim 2, wherein prior to said transmitting the firmware data to the first storage medium through the first interface, the method further comprises:
verifying the first firmware data;
if the first firmware data fails to be verified, acquiring first firmware backup data for controlling the first controller to run from the first storage medium;
and performing data recovery on the firmware operated by the first controller through the first firmware backup data.
5. The method of claim 1, wherein the firmware backup data sent to the second storage medium through the second interface includes at least second firmware data of a basic input output system, so that the firmware of the basic input output system can be data-restored through the second firmware data in the second storage medium.
6. The method of claim 1, wherein the firmware backup data sent to the second storage medium through the second interface includes at least third firmware data of a management engine driver, so that the data recovery of the management engine driver firmware can be performed through the third firmware data in the second storage medium.
7. The method of claim 1, wherein prior to said retrieving firmware backup data from the first storage medium via the first interface, the method further comprises:
the first controller controls the first storage medium to be powered on through the first interface;
and when the first storage medium is in a power-on state, the firmware backup data is acquired from the first storage medium through the first interface.
8. The method of claim 1, wherein prior to the first controller retrieving the firmware backup data from the first storage medium via the first interface, the method further comprises:
the first controller establishes communication connection with the first storage medium through a first communication protocol of a first interface;
under the condition that the communication connection is successfully established, the firmware backup data is acquired from the first storage medium through a second communication protocol of the first interface;
and the data transmission rate corresponding to the second communication protocol is greater than that of the first communication protocol.
9. An electronic device, comprising:
the first controller is used for acquiring firmware backup data from a first storage medium through a first interface under the condition that the equipment is determined to be abnormally operated; sending the firmware backup data to a second storage medium through a second interface; the equipment operation abnormity at least comprises equipment startup failure;
a first storage medium connected to the first controller through the first interface, and capable of storing firmware backup data;
the second storage medium is connected with the first controller through the second interface, and can receive the firmware backup data sent by the first controller through the second interface when the equipment is abnormally operated so as to perform data recovery on target firmware of the equipment through the firmware backup data;
a second controller capable of operating the device based on a target firmware in the firmware data in the second storage medium.
10. The electronic device of claim 9, wherein the second controller is different from the first controller, the difference comprising at least one of:
under the condition that the equipment fails to start, the first controller can operate, and the second controller cannot operate;
under the condition that the equipment runs normally, the first controller cannot execute a running instruction of an operating system, and the second controller can acquire system data from the first storage medium and execute the running instruction of the operating system based on the system data;
under the condition that the equipment operates normally, the first controller cannot execute an operating instruction of target firmware based on the firmware data, and the second controller can acquire the firmware data from the second storage medium and execute the operating instruction of the target firmware based on the firmware data.
CN202211511754.4A 2022-11-29 2022-11-29 Data recovery method and electronic equipment Pending CN115904809A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211511754.4A CN115904809A (en) 2022-11-29 2022-11-29 Data recovery method and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211511754.4A CN115904809A (en) 2022-11-29 2022-11-29 Data recovery method and electronic equipment

Publications (1)

Publication Number Publication Date
CN115904809A true CN115904809A (en) 2023-04-04

Family

ID=86482137

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211511754.4A Pending CN115904809A (en) 2022-11-29 2022-11-29 Data recovery method and electronic equipment

Country Status (1)

Country Link
CN (1) CN115904809A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117008704A (en) * 2023-09-27 2023-11-07 天固信息安全系统(深圳)有限公司 Control method and device based on EC or CPLD, storage medium and electronic equipment
CN117201518A (en) * 2023-11-08 2023-12-08 苏州元脑智能科技有限公司 Data transmission method, system, device, storage medium and electronic equipment

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117008704A (en) * 2023-09-27 2023-11-07 天固信息安全系统(深圳)有限公司 Control method and device based on EC or CPLD, storage medium and electronic equipment
CN117008704B (en) * 2023-09-27 2023-12-01 天固信息安全系统(深圳)有限公司 Control method and device based on EC or CPLD, storage medium and electronic equipment
CN117201518A (en) * 2023-11-08 2023-12-08 苏州元脑智能科技有限公司 Data transmission method, system, device, storage medium and electronic equipment
CN117201518B (en) * 2023-11-08 2024-02-20 苏州元脑智能科技有限公司 Data transmission method, system, device, storage medium and electronic equipment

Similar Documents

Publication Publication Date Title
CN115904809A (en) Data recovery method and electronic equipment
US10719400B2 (en) System and method for self-healing basic input/output system boot image and secure recovery
WO2019062635A1 (en) Update method and device
CN105117246A (en) Method for rapidly booting electronic equipment
US9448808B2 (en) BIOS update with service processor without serial peripheral interface (SPI) access
TW200305807A (en) Basic input/output system (BIOS) shadowed small-print hard disk drive as robust, always on, backup for hard disk image & software failure
CN114817105B (en) Device enumeration method, device, computer device and storage medium
WO2015085755A1 (en) Operating system recovery method, apparatus and terminal device
US20230140209A1 (en) System and method for secure access to a distributed virtual firmware network drive
CN116881929B (en) Safety protection method and device, electronic equipment and substrate controller chip
TWI764454B (en) Firmware corruption recovery
US11740969B2 (en) Detecting and recovering a corrupted non-volatile random-access memory
CN116088950A (en) System starting method and device and electronic equipment
CN115904831A (en) Starting method of server firmware and terminal
CN106776087B (en) Terminal equipment and starting method thereof
CN111694587A (en) Server PNOR firmware upgrading method, device, equipment and storage medium
US11468094B2 (en) Computer system and fault tolerance processing method thereof of image file
US20240134756A1 (en) Improving restoration of firmware data
TWI777664B (en) Booting method of embedded system
US11829248B2 (en) Firmware recovery by image transfusion
TW201222238A (en) System and method for performing a backup and recovery of system data
CN116028433B (en) Data migration method and electronic equipment
CN110716697B (en) Information processing method and equipment
CN114968314B (en) Firmware upgrading method and device for display equipment, electronic equipment and storage medium
CN116048572A (en) Firmware upgrading method and device of terminal equipment, terminal equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination