System recovery method and electronic equipment

Abstract

The invention discloses a system recovery method and electronic equipment, and the method comprises the steps: obtaining latest fault information when a system of the electronic equipment is restarted; determining the fault type of the electronic equipment based on the latest fault information; under the condition that the fault type is a peripheral device fault, determining a fault peripheral device; acquiring a device tree corresponding to the electronic device; the equipment tree comprises a plurality of nodes, and the plurality of nodes respectively correspond to each peripheral device in the electronic equipment; modifying the state of a node corresponding to the fault peripheral device in the device tree into a forbidden state; based on the modified device tree, starting each peripheral device in the electronic device; wherein the fault peripheral device in the forbidden state is not started. Therefore, when the system is restarted, the fault peripheral is not started, and the fault of the fault peripheral is not monitored, so that the normal starting of the system is not interfered by the fault peripheral.

Description

Technical Field

[0001] The present application belongs to the field of terminal technology, and specifically relates to a system recovery method and electronic equipment. Background Art

[0002] With the rapid development of electronic devices such as mobile phones, their functions are becoming more and more abundant. For example, electronic devices can collect images, collect sensor data such as user movement and health, play music, etc. The realization of these functions is inseparable from the support of peripheral devices (hereinafter referred to as peripherals).

[0003] However, during the startup or use of the electronic device, if a peripheral device in the electronic device fails, the electronic device will automatically restart repeatedly and cannot enter the system normally. In this way, since it cannot enter the system normally and cannot start normally, it is impossible to obtain data in the electronic device, affecting the user experience. Summary of the invention

[0004] The present application provides a system recovery method and electronic device, which can solve the problem that when a peripheral device fails, the electronic device automatically restarts repeatedly and cannot enter the system normally.

[0005] In a first aspect, the present application provides a system recovery method, which is applied to an electronic device, and the method includes: when the system of the electronic device is restarted, obtaining the latest fault information; determining the fault type of the electronic device based on the latest fault information; when the fault type is a peripheral device fault, determining the faulty peripheral device; and prohibiting the faulty peripheral device from starting.

[0006] In this way, since the faulty peripheral device will not be started when the system is restarted, the faulty peripheral device will not be detected to have failed, thereby ensuring that the faulty peripheral device will not interfere with the normal startup of the system.

[0007] In one achievable manner, after determining the faulty peripheral device, the method further includes: displaying first prompt information when the faulty peripheral device does not include a display screen or a touch sensor, the first prompt information being used to prompt a user whether to isolate the faulty peripheral device.

[0008] In this way, when neither the display screen nor the touch sensor fails, the first prompt information can be displayed on the display screen. The first prompt information can include two selection controls "yes" and "no". In this way, when the touch sensor does not fail, the user can choose to isolate the faulty peripheral device or not to isolate the faulty peripheral device by clicking the controls "yes" and "no".

[0009] In one achievable manner, prohibiting the faulty peripheral device from starting up includes: prohibiting the faulty peripheral device from starting up in response to receiving an isolation confirmation operation input by a user; or prohibiting the faulty peripheral device from starting up when the faulty peripheral device includes a display screen or a touch sensor.

[0010] In this way, the conditions for triggering the execution of the operation of prohibiting the startup of the faulty peripheral device can be divided into the following two cases:

[0011] The first is receiving an isolation confirmation operation input by the user. For example, if the user chooses to isolate the faulty peripheral device, such as clicking the control "Yes", the electronic device can receive the isolation confirmation operation input by the user, and thus, in response to receiving the isolation confirmation operation input by the user, the faulty peripheral device is prohibited from starting.

[0012] The second type is that the faulty peripheral device includes a display screen or a touch sensor. In this case, the electronic device may not be able to realize the display function, or even if the interface is displayed, it cannot detect the user's touch operation. Therefore, if the faulty peripheral device includes a display screen or a touch sensor, the step of displaying the first prompt information can be skipped, and the faulty peripheral device can be directly prohibited from starting.

[0013] In one implementable manner, prohibiting the faulty peripheral device from starting up includes: obtaining a device tree corresponding to the electronic device; the device tree includes multiple nodes, and the multiple nodes respectively correspond to each peripheral device in the electronic device; modifying the state of the node corresponding to the faulty peripheral device in the device tree to a disabled state; based on the modified device tree, starting each peripheral device in the electronic device; wherein the faulty peripheral device in the disabled state is not started.

[0014] In this way, by modifying the state of the node corresponding to the faulty peripheral device in the device tree to a disabled state, when loading peripheral devices, the faulty peripheral device in the disabled state is not loaded, and the faulty peripheral device will not be started, and then the fault of the faulty peripheral device will not be detected, thereby ensuring normal startup of the system.

[0015] In one implementable manner, before obtaining the device tree corresponding to the electronic device, the method further includes: when the electronic device includes multiple device trees, determining a device tree corresponding to the electronic device from the multiple device trees; wherein the multiple device trees correspond to different series of electronic devices, respectively, and the peripheral device parameters corresponding to different series of electronic devices are different.

[0016] In one implementable manner, starting each peripheral device in the electronic device based on the modified device tree includes: traversing each node in the device tree, and starting the peripheral device corresponding to each node based on the state of each node; wherein the peripheral device corresponding to the node in the started state is started, and the peripheral device corresponding to the node in the disabled state is not started.

[0017] In this way, since the state of the faulty peripheral device is modified to a disabled state in the device tree, when the peripheral devices in the electronic device are started, the faulty peripheral device will not be started, thereby ensuring that the faulty peripheral device will not interfere with the normal startup of the system.

[0018] In one implementable manner, starting each peripheral device in the electronic device based on the modified device tree includes: starting each peripheral device in the electronic device based on the modified device tree and the startup priority of each peripheral device; wherein the peripheral devices corresponding to the nodes in the startup state are started, and the peripheral devices corresponding to the nodes in the disabled state are not started.

[0019] In this way, peripheral devices that have a higher startup priority and are in the startup state can be started first.

[0020] In one achievable manner, the method further includes: in response to the system of the electronic device being in a backup file system dump mode, transferring the fault information in the memory of the electronic device to a disk.

[0021] The dump mode is a special operation mode in the XBL stage. The dump mode is used to handle system or hardware failures. That is, when the electronic device detects a system or hardware failure, a restart operation is triggered, and the system enters the dump mode in the XBL stage. In order to avoid the loss of fault information in the memory after the electronic device is powered off, in response to the electronic device's system being in the dump mode, the fault information in the memory of the electronic device is transferred to the disk.

[0022] In an implementable manner, when the system is restarted, obtaining the latest fault information includes: obtaining the latest fault information from the disk.

[0023] Since the fault information has been transferred to the disk in advance, the latest fault information, that is, the fault information that triggers the restart operation, can be obtained from the disk.

[0024] In one implementable manner, the method further includes: after the system of the electronic device is restarted, determining whether the disk of the electronic device includes the latest fault information; if the disk of the electronic device includes the latest fault information, generating second prompt information, the second prompt information being used to prompt a user that the faulty peripheral device has failed.

[0025] In this way, after the system of the electronic device is restarted, if it is detected that the disk includes the latest fault information, for example, if it is detected that the latest fault information in the disk includes a display screen fault, it means that the cause of the system restart is a display screen fault. In this way, a second prompt information can be generated to prompt the user that the display screen has a fault.

[0026] In one achievable embodiment, the method further includes: after the system of the electronic device is restarted, monitoring whether the electronic device has a fault; if a fault is detected in the electronic device, saving fault information corresponding to the fault to the memory of the electronic device and triggering a restart operation.

[0027] In a second aspect, the present application provides an electronic device, comprising a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code comprises computer instructions, and when the processor executes the computer instructions, the electronic device executes a method as described in any one of the first aspects.

[0028] In a third aspect, the present application provides a computer-readable storage medium, in which a computer program or instructions are stored. When the computer program or instructions are executed, the method described in any one of the first aspects is executed. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0030] Figure 1 A schematic diagram of a system restart process provided in an embodiment of the present application;

[0031] Figure 2 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

[0032] Figure 3 A software architecture diagram of an electronic device provided in an embodiment of the present application;

[0033] Figure 4 A schematic diagram of a work flow of a system recovery method provided in an embodiment of the present application;

[0034] Figure 5 An example diagram of a user interface for first prompt information provided in an embodiment of the present application;

[0035] Figure 6 A schematic diagram of a workflow of another system recovery method provided in an embodiment of the present application;

[0036] Figure 7 An example diagram of a user interface for second prompt information provided in an embodiment of the present application;

[0037] Figure 8 A schematic diagram of a workflow of another system recovery method provided in an embodiment of the present application;

[0038] Fig. 9 A schematic diagram of a chip structure provided in an embodiment of the present application. DETAILED DESCRIPTION

[0039] With the rapid development of electronic devices such as mobile phones, their functions are becoming more and more abundant. For example, electronic devices can collect images, collect sensor data such as user movement and health, play music, etc. The realization of these functions is inseparable from the support of peripheral devices (hereinafter referred to as peripherals).

[0040] In some embodiments, the electronic device may include a display screen, a camera module, a sensor (such as a touch sensor, a pressure sensor, an acceleration sensor, etc.), a smart power amplifier (smart PA), a microphone, a motor, NFC, a fingerprint module and other peripherals.

[0041] During the startup or use of the electronic device, the electronic device can monitor in real time whether each peripheral device has a fault. If a peripheral device is detected to have a fault, an automatic restart operation will be triggered.

[0042] For example, Figure 1 As shown in FIG, the automatic restart operation mainly includes five stages: the extensible boot loader (XBL) stage, the Unified extensible firmware interface (UEFI) stage, the Linux kernel (Linux Kernel) stage, the Linux initialization (Linux Init) stage and the Android stage.

[0043] The XBL phase is the first phase of system startup. In this phase, the electronic device mainly executes the code of hardware initialization and boot loader. XBL is a small program, usually stored in the boot memory of the electronic device (such as flash memory). Its main task is to initialize the hardware, load the boot kernel and file system, and then hand over control to the boot kernel.

[0044] The UEFI stage is the second stage of system startup. After the boot loader is started, the electronic device loads the UEFI firmware. The UEFI firmware is responsible for tasks such as further hardware initialization and loading the boot loader or operating system kernel from disk. The boot loader loads the operating system kernel, usually the Linux kernel, but it may also be the kernel of other operating systems. After the kernel is loaded, the boot loader hands control to the kernel, causing it to enter kernel state.

[0045] The Linux Kernel stage is the third stage of system startup. In the Linux Kernel stage, kernel data structures can be initialized, hardware (such as CPU, memory management unit, peripheral drivers, etc.) can be initialized, and the root file system can be mounted.

[0046] The Linux Init phase is the fourth phase of system startup. The Linux Init phase is mainly responsible for initializing the system. During the Linux Init phase, the system executes a series of initialization scripts and configuration files to start various system services and daemons. These scripts and configuration files usually define the tasks that should be run when the system starts, such as loading drivers, configuring the network, setting the host name, etc.

[0047] The Android stage is the fifth stage of system startup. In the Android stage, various system services and applications can be started. For example, applications can include desktop managers, application services, and user interfaces.

[0048] Please continue to see Figure 1 , in both the Linux Init stage and the Android stage, the peripherals of the electronic device can be monitored to see if they fail. For example, after the electronic device fails to start the display screen, the electronic device can determine that the display screen fails. If the peripherals of the monitored electronic device fail, the fault information can be recorded in the memory first, and then the automatic restart operation can be triggered, that is, the above five stages are executed.

[0049] However, if Figure 1As shown in the figure, since the problem of peripheral failure has not been solved, after the electronic device automatically restarts, the peripheral failure will still be detected in the LinuxInit stage, which will trigger the automatic restart again. Therefore, at present, when the peripherals in the electronic device fail, the electronic device will automatically restart repeatedly and cannot enter the system normally. In this way, since it is impossible to enter the system normally and cannot be turned on normally, it is impossible to obtain data in the electronic device, which affects the user experience.

[0050] To solve the above problem, the embodiment of the present application provides a system recovery method, which, in response to monitoring the peripheral failure of the electronic device, prohibits the startup of the faulty peripheral when the system is restarted. In this way, since the faulty peripheral will not be started when the system is restarted, the faulty peripheral will not be detected, thereby ensuring that the faulty peripheral will not interfere with the normal startup of the system.

[0051] The system recovery method provided in the embodiments of the present application can be applied to electronic devices. In some embodiments, the electronic devices can be mobile phones, tablet computers, handheld computers, personal computers (PCs), personal digital assistants (PDAs), wearable devices, and the like. The embodiments of the present application do not limit the specific form of the electronic devices.

[0052] For example, taking the electronic device as a mobile phone, Figure 2 A schematic structural diagram of an electronic device provided in an embodiment of the present application is shown.

[0053] like Figure 2 As shown, the electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0054] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0055] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0056] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0057] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0058] In some embodiments, the processor 110 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0059] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple groups of I2C buses. The processor 110 may be coupled to the touch sensor 180K, the charger, the flash, the camera 193, etc. through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K through the I2C interface, so that the processor 110 communicates with the touch sensor 180K through the I2C bus interface, thereby realizing the touch function of the electronic device 100.

[0060] The I2S interface can be used for audio communication. In some embodiments, the processor 110 can include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to achieve communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit an audio signal to the wireless communication module 160 via the I2S interface to achieve the function of answering a call through a Bluetooth headset.

[0061] The PCM interface can also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via a PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface to realize the function of answering calls via a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0062] The UART interface is a universal serial data bus for asynchronous communication. The bus can be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, the UART interface is generally used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 through the UART interface to implement the Bluetooth function. In some embodiments, the audio module 170 can transmit an audio signal to the wireless communication module 160 through the UART interface to implement the function of playing music through a Bluetooth headset.

[0063] The MIPI interface can be used to connect the processor 110 with peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), etc. In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to implement the shooting function of the electronic device 100. The processor 110 and the display screen 194 communicate via the DSI interface to implement the display function of the electronic device 100.

[0064] The GPIO interface can be configured by software. The GPIO interface can be configured as a control signal or as a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 with the camera 193, the display 194, the wireless communication module 160, the audio module 170, the sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0065] The USB interface 130 is an interface that complies with the USB standard specification, and specifically can be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used to transfer data between the electronic device 100 and a peripheral device. It can also be used to connect headphones to play audio through the headphones. The interface can also be used to connect other electronic devices, such as AR devices, etc.

[0066] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present invention is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0067] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device through the power management module 141.

[0068] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the display screen 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0069] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0070] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0071] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0072] The modem processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a receiver 170B, etc.), or displays an image or video through a display screen 194. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0073] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the frequency of the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency of it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0074] In some embodiments, the antenna 1 of the electronic device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other devices through wireless communication technology. The wireless communication technology may include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

[0075] The electronic device 100 implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

[0076] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device 100 may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0077] The electronic device 100 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0078] The ISP is used to process the data fed back by the camera 193. For example, when taking a photo, the shutter is opened, and the light is transmitted to the camera photosensitive element through the lens. The light signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converts it into an image visible to the naked eye. The ISP can also perform algorithm optimization on the noise and brightness of the image. The ISP can also optimize the exposure, color temperature and other parameters of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0079] The camera 193 is used to capture still images or videos. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then passes the electrical signal to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV or other format. In some embodiments, the electronic device 100 may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0080] The digital signal processor is used to process digital signals, and can process not only digital image signals but also other digital signals. For example, when the electronic device 100 is selecting a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy.

[0081] Video codecs are used to compress or decompress digital videos. The electronic device 100 may support one or more video codecs. Thus, the electronic device 100 may play or record videos in a variety of coding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0082] NPU is a neural network (NN) computing processor. By drawing on the structure of biological neural networks, such as the transmission mode between neurons in the human brain, it can quickly process input information and can also continuously self-learn. Through NPU, applications such as intelligent cognition of electronic device 100 can be realized, such as image recognition, face recognition, voice recognition, text understanding, etc.

[0083] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0084] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device 100 by running instructions stored in the internal memory 121, and / or instructions stored in a memory provided in the processor.

[0085] The electronic device 100 can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0086] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The audio module 170 can also be used to encode and decode audio signals. In some embodiments, the audio module 170 can be arranged in the processor 110, or some functional modules of the audio module 170 can be arranged in the processor 110.

[0087] The speaker 170A, also called a "speaker", is used to convert an audio electrical signal into a sound signal. The electronic device 100 can listen to music or listen to a hands-free call through the speaker 170A. A plurality of speakers 170A can be provided in the electronic device 100. For example, a speaker 170A can be provided on the top of the electronic device 100, and a speaker 170A can also be provided on the bottom, and so on.

[0088] The receiver 170B, also called a "receiver", is used to convert audio electrical signals into sound signals. When the electronic device 100 receives a call or voice message, the receiver 170B can be placed close to the human ear to receive the voice. In some embodiments, the speaker 170A and the receiver 170B can also be set as one component, which is not limited in the present application.

[0089] Microphone 170C, also called "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or sending a voice message, the user can speak by putting their mouth close to microphone 170C to input the sound signal into microphone 170C. The electronic device 100 can be provided with at least one microphone 170C. In other embodiments, the electronic device 100 can be provided with two microphones 170C, which can not only collect sound signals but also realize noise reduction function. In other embodiments, the electronic device 100 can also be provided with three, four or more microphones 170C to collect sound signals, reduce noise, identify the sound source, realize directional recording function, etc.

[0090] The earphone interface 170D is used to connect a wired earphone and can be a USB interface 130 or a 3.5 mm open mobile terminal platform (OMTP) standard interface or a cellular telecommunications industry association of the USA (CTIA) standard interface.

[0091] The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A can be set on the display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc. The capacitive pressure sensor can be a parallel plate including at least two conductive materials. When a force acts on the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the intensity of the pressure according to the change in capacitance. When a touch operation acts on the display screen 194, the electronic device 100 detects the touch operation intensity according to the pressure sensor 180A. The electronic device 100 can also calculate the touch position according to the detection signal of the pressure sensor 180A. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities can correspond to different operation instructions. For example: when a touch operation with a touch operation intensity less than the first pressure threshold acts on the short message application icon, an instruction to view the short message is executed. When a touch operation with a touch operation intensity greater than or equal to the first pressure threshold acts on the short message application icon, an instruction to create a new short message is executed.

[0092] The gyro sensor 180B can be used to determine the motion posture of the electronic device 100. In some embodiments, the angular velocity of the electronic device 100 around three axes (i.e., x, y, and z axes) can be determined by the gyro sensor 180B. The gyro sensor 180B can be used for anti-shake shooting. For example, when the shutter is pressed, the gyro sensor 180B detects the angle of the electronic device 100 shaking, calculates the distance that the lens module needs to compensate based on the angle, and allows the lens to offset the shaking of the electronic device 100 through reverse movement to achieve anti-shake. The gyro sensor 180B can also be used for navigation and somatosensory game scenes.

[0093] The air pressure sensor 180C is used to measure air pressure. In some embodiments, the electronic device 100 calculates the altitude through the air pressure value measured by the air pressure sensor 180C to assist positioning and navigation.

[0094] The magnetic sensor 180D includes a Hall sensor. The electronic device 100 can use the magnetic sensor 180D to detect the opening and closing of the flip leather case. In some embodiments, when the electronic device 100 is a flip phone, the electronic device 100 can detect the opening and closing of the flip cover according to the magnetic sensor 180D. Then, according to the detected opening and closing state of the leather case or the opening and closing state of the flip cover, the flip cover can be automatically unlocked.

[0095] The acceleration sensor 180E can detect the magnitude of the acceleration of the electronic device 100 in all directions (generally three axes). When the electronic device 100 is stationary, the magnitude and direction of gravity can be detected. It can also be used to identify the posture of the electronic device and is applied to applications such as horizontal and vertical screen switching and pedometers.

[0096] The distance sensor 180F is used to measure the distance. The electronic device 100 can measure the distance by infrared or laser. In some embodiments, when shooting a scene, the electronic device 100 can use the distance sensor 180F to measure the distance to achieve fast focusing.

[0097] The proximity light sensor 180G may include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode. The electronic device 100 emits infrared light outward through the light emitting diode. The electronic device 100 uses a photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that there is an object near the electronic device 100. When insufficient reflected light is detected, the electronic device 100 can determine that there is no object near the electronic device 100. The electronic device 100 can use the proximity light sensor 180G to detect that the user holds the electronic device 100 close to the ear to talk, so as to automatically turn off the screen to save power. The proximity light sensor 180G can also be used in leather case mode and pocket mode to automatically unlock and lock the screen.

[0098] The ambient light sensor 180L is used to sense the ambient light brightness. The electronic device 100 can adaptively adjust the brightness of the display screen 194 according to the perceived ambient light brightness. The ambient light sensor 180L can also be used to automatically adjust the white balance when taking pictures. The ambient light sensor 180L can also cooperate with the proximity light sensor 180G to detect whether the electronic device 100 is in a pocket to prevent accidental touches.

[0099] The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to implement fingerprint unlocking, access application locks, fingerprint photography, fingerprint call answering, etc.

[0100] The temperature sensor 180J is used to detect temperature. In some embodiments, the electronic device 100 uses the temperature detected by the temperature sensor 180J to execute a temperature processing strategy. For example, when the temperature reported by the temperature sensor 180J exceeds a threshold, the electronic device 100 reduces the performance of a processor located near the temperature sensor 180J to reduce power consumption and implement thermal protection. In other embodiments, when the temperature is lower than another threshold, the electronic device 100 heats the battery 142 to avoid abnormal shutdown of the electronic device 100 due to low temperature. In other embodiments, when the temperature is lower than another threshold, the electronic device 100 performs a boost on the output voltage of the battery 142 to avoid abnormal shutdown caused by low temperature.

[0101] The touch sensor 180K is also called a "touch control device". The touch sensor 180K can be set on the display screen 194. The touch sensor 180K and the display screen 194 form a touch screen, also called a "touch control screen". The touch sensor 180K is used to detect touch operations acting on or near it. The touch sensor can pass the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through the display screen 194. In other embodiments, the touch sensor 180K can also be set on the surface of the electronic device 100, which is different from the position of the display screen 194.

[0102] The bone conduction sensor 180M can obtain a vibration signal. In some embodiments, the bone conduction sensor 180M can obtain a vibration signal of a vibrating bone block of the vocal part of the human body. The bone conduction sensor 180M can also contact the human pulse to receive a blood pressure beat signal. In some embodiments, the bone conduction sensor 180M can also be set in an earphone and combined into a bone conduction earphone. The audio module 170 can parse out a voice signal based on the vibration signal of the vibrating bone block of the vocal part obtained by the bone conduction sensor 180M to realize a voice function. The application processor can parse the heart rate information based on the blood pressure beat signal obtained by the bone conduction sensor 180M to realize a heart rate detection function.

[0103] The key 190 includes a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The electronic device 100 may receive key input and generate key signal input related to user settings and function control of the electronic device 100.

[0104] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. For example, touch operations acting on different applications (such as taking pictures, audio playback, etc.) can correspond to different vibration feedback effects. For touch operations acting on different areas of the display screen 194, motor 191 can also correspond to different vibration feedback effects. Different application scenarios (for example: time reminders, receiving messages, alarm clocks, games, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect can also support customization.

[0105] Indicator 192 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0106] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to and separated from the electronic device 100 by inserting it into the SIM card interface 195 or pulling it out from the SIM card interface 195. The electronic device 100 can support 1 or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, and the like. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The types of the multiple cards can be the same or different. The SIM card interface 195 can also be compatible with different types of SIM cards. The SIM card interface 195 can also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to implement functions such as calls and data communications. In some embodiments, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

[0107] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. In the embodiment of the present invention, the Android system of the layered architecture is taken as an example to exemplify the software structure of the electronic device 100.

[0108] Figure 3 It is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

[0109] The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system library, and the kernel layer.

[0110] The application layer can include a series of application packages.

[0111] like Figure 3 As shown, the application package may include camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0112] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0113] like Figure 3 As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0114] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0115] Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0116] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0117] The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including connecting, hanging up, etc.).

[0118] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0119] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0120] Android Runtime includes core libraries and virtual machines. Android runtime is responsible for scheduling and management of the Android system.

[0121] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0122] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0123] The system library may include multiple functional modules, such as surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

[0124] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0125] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0126] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0127] A 2D graphics engine is a drawing engine for 2D drawings.

[0128] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and sensor driver.

[0129] The following is a detailed description of a system recovery method provided in an embodiment of the present application.

[0130] like Figure 4 As shown, during the startup or use of the electronic device, if there is a processing system or hardware failure, the electronic device will try to automatically restart. The automatic restart operation of the electronic device mainly includes five stages: XBL stage, UEFI stage, Linux Kernel stage, Linux Init stage and Android stage. Among them, the XBL stage can be executed by XBL, the UEFI stage can be executed by UEFI, the Linux Kernel stage can be executed by the kernel, the Linux Init stage can be executed by the Init process, and the Android stage can be executed by the Android system.

[0131] The following is based on Figure 4 The system startup process shown provides a detailed description of the system recovery method provided in the embodiment of the present application.

[0132] The XBL phase is the first phase of system startup. The XBL phase can include the following steps:

[0133] S201, the system enters the backup file system dump mode.

[0134] The automatic restart operation of the electronic device first enters the XBL stage. The dump mode is a special operation mode in the XBL stage. The dump mode is used to handle system or hardware failures. That is, when the electronic device detects a system or hardware failure, the restart operation is triggered, and in the XBL stage, the system enters the dump mode.

[0135] S202, in response to the system entering a dump mode, reading fault information from a memory of the electronic device.

[0136] In the Linux Init stage and the Android stage, if the electronic device detects that a peripheral device has failed, it will record the failure information and save the failure information to the memory of the electronic device for subsequent diagnosis and analysis. In this way, after the system enters the dump mode, the failure information can be obtained from the memory of the electronic device.

[0137] In some embodiments, the fault information may include a fault type, an error code, a context in which the fault occurs, etc. Exemplarily, the fault type may include a peripheral fault, a system on chip (SoC) fault, a central processor unit (CPU) fault, etc. Different fault types correspond to different error codes, so the fault type can be determined based on the error code.

[0138] If the fault type is a peripheral fault, the fault information may also include the peripheral identification of the faulty device. For example, peripheral identification 001 indicates a display fault, peripheral identification 002 indicates a touch sensor fault, peripheral identification 003 indicates a camera module fault, peripheral identification 004 indicates a pressure sensor fault, peripheral identification 005 indicates a smart power amplifier (smart PA) fault, peripheral identification 006 indicates a microphone fault, peripheral identification 007 indicates a motor fault, peripheral identification 008 indicates an NFC fault, and peripheral identification 009 indicates a fingerprint module fault, etc. In this way, based on the peripheral identifications 001-009 in the fault information, it can be determined which peripheral has failed.

[0139] S203, transferring the fault information to a disk of the electronic device.

[0140] It should be noted that the electronic device is still powered during the XBL stage. After the XBL stage is completed, the power is turned off first, and then restarted to enter the UEFI stage.

[0141] Since the data stored in the memory of the electronic device will be lost after the electronic device is powered off, but the data stored in the disk of the electronic device will not be lost, in order to avoid the loss of fault information in the memory after the electronic device is powered off, the fault information is first transferred to the disk before the power is turned off in the XBL stage.

[0142] After transferring the fault information to the disk, the electronic device is powered off, restarted and enters the UEFI stage. The UEFI stage is the second stage of system startup. The UEFI stage may include the following steps:

[0143] S204, obtaining the latest fault information from the disk of the electronic device.

[0144] Since the fault information has been transferred to the disk in the XBL stage, the fault information can still be obtained from the disk of the electronic device after the electronic device is powered off and restarted.

[0145] In some embodiments, a plurality of fault information may be stored in the disk of the electronic device. In this case, the latest fault information is obtained in S204 so that the acquired fault information is the fault information occurring before the current restart.

[0146] In an implementable manner, the latest fault information can be determined from the multiple fault information based on the storage time of the multiple fault information. Exemplarily, the fault information whose storage time is the shortest from the current system time can be determined as the latest fault information.

[0147] In an implementable manner, the latest fault information can be determined from the multiple fault information based on the fault occurrence time of the multiple fault information. Exemplarily, the fault information whose fault occurrence time is the shortest from the current system time can be determined as the latest fault information.

[0148] In one possible implementation, if the fault information is transferred to the disk of the electronic device during the startup process, a marker can be added to the latest transferred fault information. In this way, the latest fault information in the disk can be determined by the marker.

[0149] S205: Determine whether the fault type of the electronic device is a peripheral fault based on the fault information.

[0150] There are many reasons that cause the electronic device to restart, such as peripheral failure, CPU failure, SoC failure, etc. Among them, the fault type is recorded in the fault information. Therefore, in the UEFI stage, the fault type of the electronic device can be determined based on the fault information. Exemplarily, the fault type can be determined based on the error code in the fault information.

[0151] S206: If the fault type is a peripheral fault, determine whether the faulty peripheral is a display screen or a touch sensor.

[0152] In some embodiments, if the fault type is a peripheral fault, it is also possible to determine which peripheral has failed based on the peripheral identifier in the fault information, such as 001-009, etc., that is, determine the faulty peripheral.

[0153] If the faulty peripheral device is not a display screen or a touch sensor, the following steps S207 to S209 may be performed. If the faulty peripheral device is a display screen or a touch sensor, the following steps S208 to S209 may be performed.

[0154] S207: If the faulty peripheral device does not include a display screen or a touch sensor, display a first prompt message, where the first prompt message is used to prompt the user whether to isolate the faulty peripheral device.

[0155] If the faulty peripheral device does not include a display screen, the first prompt information may be displayed on the display screen. If the faulty peripheral device does not include a touch sensor, the user may select whether to isolate the faulty peripheral device by clicking a control displayed on the display screen.

[0156] For example, taking the faulty peripheral as a front camera module in a camera module as an example, Figure 5 As shown, the first prompt message "Whether to isolate the front camera module" can be displayed on the user interface of the electronic device. After the first prompt message is displayed, the user can click the control "Yes" or the control "No" to trigger different processing flows.

[0157] For example, if the electronic device detects that the user clicks the control "yes", step S208 to step S209 are executed. If the electronic device detects that the user clicks the control "no", step S209 is executed.

[0158] It should be noted that, in the embodiment of the present application, the faulty peripheral device may be one or more. If there are multiple faulty peripheral devices, the generated first prompt information may be used to prompt the user whether to isolate all the faulty peripheral devices.

[0159] S208, modifying the state of the faulty peripheral node in the flattened device tree (FDT) to be disabled.

[0160] In some embodiments, if the first prompt information is displayed on the display screen of the electronic device and an isolation confirmation operation input by the user is detected, the state of the faulty peripheral node in the device tree may be modified to disabled.

[0161] Exemplarily, the isolation confirmation operation input by the user may be that the user clicks a control “Yes” in the first prompt information.

[0162] In some embodiments, if it is determined in step S206 that the faulty peripheral is a display screen or a touch sensor, step S207 may be skipped and step S208 may be executed, that is, the state of the faulty peripheral node in the device tree is directly modified in the background to be disabled.

[0163] The device tree is a registry that describes various peripherals and information related to each peripheral.

[0164] In some embodiments, the device tree may include multiple nodes, each node corresponding to a peripheral and peripheral information corresponding to the peripheral. For example, the peripheral information may include a peripheral name, a peripheral status, etc. The peripheral status includes two states: enabled and disabled.

[0165] In some embodiments, modifying the state of the faulty peripheral node in the device tree to be disabled can be implemented in the following manner: each node in the device tree can be traversed to find the node corresponding to the faulty peripheral. After finding the node corresponding to the faulty peripheral, the peripheral state of the node can be modified to be disabled.

[0166] For example, if the faulty peripheral is a front camera module, traverse each node in the device tree to find the node corresponding to the front camera module. After finding the node corresponding to the front camera module, the status attribute of the node can be set to "disabled" or "off" to disable the peripheral corresponding to the front camera module.

[0167] In specific implementation, the state of the faulty peripheral node in the device tree can be modified to disabled through functions such as fdt_begin_node, fdt_end_node, fdt_add_string_, and fdt_del_last_string_.

[0168] In this way, the status of the faulty peripheral node in the modified device tree is disabled.

[0169] Generally, different series of electronic devices from the same manufacturer may use different peripheral models, performance parameters, etc. Therefore, in some embodiments, the same electronic device may store multiple device trees, which may correspond to peripherals used by different series of electronic devices.

[0170] Exemplarily, three device trees are stored in the same electronic device, wherein device tree 01 corresponds to peripherals of A series electronic devices, device tree 02 corresponds to peripherals of B series electronic devices, and device tree 03 corresponds to peripherals of C series electronic devices.

[0171] Thus, in some embodiments, the state of the faulty peripheral node in each device tree in the electronic device may be modified to be disabled.

[0172] S209, continue booting and enter the Linux Kernel stage.

[0173] If the fault type is not a peripheral fault, or in response to a non-isolation confirmation operation input by the user, step S209 is directly executed.

[0174] The non-isolation confirmation operation input by the user may be that the user clicks a control “No” in the first prompt information.

[0175] The above embodiment only illustrates the processing flow of the UEFI stage by using steps S204 to S209, and does not limit the processing flow of the UEFI stage. Figure 6 As shown, the processing flow at the UEFI stage can also adopt the following steps:

[0176] S301, obtaining the latest fault information from a disk of the electronic device.

[0177] S302: Determine whether the fault type of the electronic device is a peripheral fault based on the fault information.

[0178] S303: If the fault type is a peripheral fault, determine the faulty peripheral.

[0179] S304, modifying the state of the faulty peripheral node in the device tree to disabled.

[0180] S305, continue booting and enter the Linux Kernel stage.

[0181] That is to say, Figure 6 In the processing flow of the UEFI stage shown, after determining the faulty peripheral, the state of the faulty peripheral node in the device tree can be directly modified to disabled. It is not necessary to perform the steps of determining whether the faulty peripheral is a display screen or a touch sensor, and determining whether to display the first prompt information based on the determination result. In this way, the processing flow of the UEFI stage can be simplified.

[0182] Among them, steps S301 to S303 can refer to the description of the above steps S204 to S206, and steps S304 to S305 can refer to the description of the above steps S208 to S209, which will not be repeated here.

[0183] The Linux Kernel stage is the third stage of system startup. After entering the Linux Kernel stage, the boot loader hands over control to the kernel, causing it to enter kernel state. The Linux Kernel stage can include the following steps:

[0184] S210: Determine a device tree corresponding to the current electronic device.

[0185] In some embodiments, multiple device trees may be stored in the same electronic device. Therefore, after entering the Linux Kernel stage, the device tree corresponding to the current electronic device can be determined. For example, the product information of the current electronic device can be obtained first, and the current electronic device can be determined to be a B series based on the product information of the current electronic device. Further, the device tree corresponding to the current electronic device can be determined to be device tree 02. In this way, each peripheral can be loaded based on device tree 02 later.

[0186] It should be noted that if the electronic device includes only one device tree, the device tree may be directly determined as the device tree corresponding to the electronic device.

[0187] After determining the device tree corresponding to the current electronic device, the system enters the Linux Init stage. The Linux Init stage is the fourth stage of system startup and can also be called the Linux user state.

[0188] The Linux Init phase is responsible for initializing the system. During the Linux Init phase, the system executes a series of initialization scripts and configuration files to start various system services and daemons. These scripts and configuration files usually define the tasks that should be run when the system starts, such as loading drivers, configuring the network, setting the host name, etc.

[0189] Taking the loading of each peripheral driver as an example, after entering the Linux Init stage, each peripheral driver can be loaded based on the determined device tree. It should be understood that in the Linux Init stage, the peripheral drivers in the enabled state in the device tree are loaded, and the peripheral drivers in the disabled state are not loaded. Since the state of the faulty peripheral node in the device tree is modified to disabled in the UEFI stage, the faulty peripheral driver will not be loaded in the Linux Init stage, so that it can be ensured that the faulty peripheral will not interfere with the normal startup of the system.

[0190] Specifically, the following steps may be included in the Linux Init phase:

[0191] S211, loading the peripheral driver corresponding to the node in the device tree whose status is enabled.

[0192] In some embodiments, peripheral drivers corresponding to nodes in the enabled state may be loaded one by one based on the modified device tree.

[0193] In some embodiments, the peripheral device drivers corresponding to the nodes in the enabled state may also be loaded based on a preset priority rule.

[0194] Exemplarily, the Linux Init phase can be divided into two loading phases based on a preset priority rule, wherein the first loading phase can load peripheral drivers and system services with higher priorities, and the second loading phase can load peripheral drivers and system services with lower priorities.

[0195] S212, after loading the peripheral device driver corresponding to the node in the device tree whose status is enabled, monitor whether a new peripheral device fault occurs.

[0196] In some embodiments, if a peripheral device driver is not successfully loaded during the Linux Init phase, the system will report an error, so that the electronic device can detect the occurrence of a peripheral device failure.

[0197] Exemplarily, the display screen of the electronic device fails again during the restart phase, so when the display screen is loaded during the Linux Init phase, the system will report that the display screen fails.

[0198] S213: If a peripheral device fault is detected, the fault information is recorded in the memory of the electronic device.

[0199] After a peripheral failure occurs, the system can automatically save the relevant fault information to the memory of the electronic device.

[0200] Further, after the fault information is recorded in the memory of the electronic device, the automatic restart operation is triggered again. That is, the system re-enters the XBL stage and re-executes the above steps S201 to S212. Correspondingly, the state of the display screen node in the device tree is modified to disabled in the UEFI stage.

[0201] After the Linux Init stage completes the initialization of the system, the system proceeds to the Android stage, which is the fifth stage of system startup and can also be called the Android user state. In the Android stage, various applications can be started, including starting the desktop manager, application services, and user interfaces. Specifically, the following steps may be included in the Android stage:

[0202] S214, in the Android stage, determining whether the disk includes new fault information.

[0203] In the embodiment of the present application, the fault information in the disk is transferred from the memory to the disk during the XBL phase. Therefore, the new fault information refers to the latest fault information transferred from the memory to the disk during this startup process.

[0204] In some embodiments, if the fault information is transferred to the disk of the electronic device during the current startup process, a marker can be added to the latest transferred fault information. In this way, it can be determined by the marker whether the disk includes new fault information. For example, if the disk includes the marker, it is determined that the disk includes new fault information. If the disk does not include the marker, it is determined that the disk does not include new fault information.

[0205] S215: If the disk includes new fault information, generate second prompt information, where the second prompt information is used to prompt the user that a fault occurs in the peripheral device.

[0206] In some embodiments, the second prompt information can be displayed on the user interface of the electronic device to prompt the user.

[0207] For example, Figure 7 As shown, a second prompt message "Front camera module failure, please go to a nearby store for repair as soon as possible" can be displayed on the user interface of the electronic device. After the second prompt message is displayed, the user can learn that the front camera module has failed, so that the user can back up the data in the electronic device in time and go to a nearby store to repair the front camera module as soon as possible.

[0208] In some embodiments, the second prompt information can be broadcasted by a speaker of the electronic device to prompt the user. For example, after the system enters the Android stage, the speaker broadcasts "The front camera module is faulty, please go to a nearby store for repair as soon as possible."

[0209] In some embodiments, the second prompt information can be displayed on the user interface of the electronic device and broadcasted by the speaker of the electronic device to prompt the user. For example, after the system enters the Android stage, the second prompt information "Front camera module failure, please go to a nearby store for repair as soon as possible" can be displayed on the user interface of the electronic device, and "Front camera module failure, please go to a nearby store for repair as soon as possible" can be broadcasted through the speaker.

[0210] In some embodiments, it may be determined whether the faulty peripheral device is a display screen or a speaker. If the faulty peripheral device is a display screen, the second prompt information may be broadcasted by the speaker of the electronic device to prompt the user. If the faulty peripheral device is a speaker, the second prompt information may be displayed on the user interface of the electronic device to prompt the user.

[0211] In addition, in the Android stage, it is also possible to monitor whether a new peripheral fault occurs. If a new peripheral fault is detected, the fault information is recorded in the memory of the electronic device. For details, please refer to the description of step S212 and step S213, which will not be repeated here.

[0212] In summary, the system recovery method provided by the embodiment of the present application isolates the faulty peripherals during the system restart process to ensure that the faulty peripherals do not interfere with the normal startup of the system. Specifically, the faulty peripherals can be identified in the UEFI stage, and the state of the faulty peripheral node in the device tree can be modified to be disabled. In this way, when the peripheral driver is loaded in the Linux Init stage, the driver of the faulty peripheral in the disabled state will not be loaded, and the problem of failure to load the faulty peripheral will not occur, thereby ensuring that the faulty peripheral will not interfere with the normal startup of the system. In this way, after restarting, the user can obtain the data in the electronic device.

[0213] It should be noted that the above embodiment is only described by taking the case where the electronic device includes multiple device trees as an example. If the electronic device includes only one device tree, step S210 may be skipped.

[0214] Figure 8 The following is a flowchart of a system recovery method provided in an embodiment of the present application. Figure 8 As shown, the method may include the following steps:

[0215] S401, when the system of the electronic device is restarted, the latest fault information is obtained.

[0216] S402: Determine the fault type of the electronic device based on the latest fault information.

[0217] S403: When the fault type is a peripheral device fault, determine the faulty peripheral device.

[0218] S404, prohibiting the faulty peripheral device from starting.

[0219] In one possible implementation, after determining the faulty peripheral device, the method further includes: if the faulty peripheral device does not include a display screen or a touch sensor, displaying a first prompt message, the first prompt message being used to prompt a user whether to isolate the faulty peripheral device. The implementation method may be specifically described in steps S206-S207, which will not be described in detail here.

[0220] In one possible implementation, prohibiting the startup of the faulty peripheral device includes: prohibiting the startup of the faulty peripheral device in response to receiving an isolation confirmation operation input by a user; or prohibiting the startup of the faulty peripheral device when the faulty peripheral device includes a display screen or a touch sensor. The implementation method can be specifically described in steps S206-S208, which will not be repeated here.

[0221] In one achievable manner, prohibiting the startup of a faulty peripheral device includes: obtaining a device tree corresponding to the electronic device; the device tree includes multiple nodes, and the multiple nodes correspond to each peripheral device in the electronic device; modifying the state of the node corresponding to the faulty peripheral device in the device tree to a disabled state; based on the modified device tree, starting each peripheral device in the electronic device; wherein the faulty peripheral device in the disabled state is not started. The implementation method can be specifically referred to the description of step S208, which will not be repeated here.

[0222] In one possible implementation, before obtaining the device tree corresponding to the electronic device, the method further includes: when the electronic device includes multiple device trees, determining a device tree corresponding to the electronic device in the multiple device trees; wherein the multiple device trees correspond to different series of electronic devices, and the peripheral device parameters included in the different series of electronic devices are different. The implementation method can be specifically referred to the description of step S210, which will not be repeated here.

[0223] In one possible implementation, based on the modified device tree, each peripheral device in the electronic device is started, including: traversing each node in the device tree, and starting the peripheral device corresponding to each node based on the state of each node; wherein the peripheral device corresponding to the node in the enabled state is started, and the peripheral device corresponding to the node in the disabled state is not started. The implementation method can be specifically referred to the description of step S211, which will not be repeated here.

[0224] In one possible implementation, based on the modified device tree, each peripheral device in the electronic device is started, including: based on the modified device tree and the startup priority of each peripheral device, each peripheral device in the electronic device is started; wherein, the peripheral device corresponding to the node in the startup state is started, and the peripheral device corresponding to the node in the disabled state is not started. The implementation method can be specifically referred to the description of step S211, which will not be repeated here.

[0225] In an achievable manner, the method further includes: in response to the electronic device system being in a backup file system dump mode, transferring the fault information in the memory of the electronic device to a disk. The implementation manner may be specifically described in steps S201-S203, which will not be described in detail here.

[0226] In one possible implementation, when the system is restarted, the latest fault information is obtained, including: obtaining the latest fault information from the disk. The implementation can be specifically described in step S204, which will not be repeated here.

[0227] In an implementable manner, the method further includes: after the system of the electronic device is restarted, determining whether the disk of the electronic device includes the latest fault information; if the disk of the electronic device includes the latest fault information, generating second prompt information, the second prompt information is used to prompt the user that the faulty peripheral device has failed. The implementation method can be specifically described in steps S214-S215, which will not be repeated here.

[0228] In one possible implementation, the method further includes: after the system of the electronic device is restarted, monitoring whether a new fault occurs in the electronic device; if a new fault occurs in the electronic device, saving fault information corresponding to the new fault to the memory of the electronic device, and triggering a restart operation. The implementation method can be specifically described in steps S212-S213, which will not be repeated here.

[0229] The various method embodiments described in this document may be independent solutions or may be combined according to internal logic, and these solutions all fall within the protection scope of this application.

[0230] It can be understood that, in the above-mentioned various method embodiments, the methods and operations implemented by the electronic device can also be implemented by components (such as chips, modules or circuits) that can be used in the electronic device.

[0231] The above embodiments introduce the system recovery method provided by the present application. It is understandable that, in order to implement the above functions, the electronic device includes a hardware structure and / or software module corresponding to each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0232] Above, combined Figures 1 to 8 The system recovery method provided by the embodiment of the present application is described in detail. Fig. 9 The device provided in the embodiment of the present application is described in detail. It should be understood that the description of the device embodiment corresponds to the description of the method embodiment, so the contents not described in detail can be referred to the method embodiment above, and for the sake of brevity, they will not be repeated here.

[0233] The embodiment of the present application further provides a processing device, which includes at least one processor and a communication interface. The communication interface is used to provide information input and / or output to the at least one processor, and the at least one processor is used to execute the method in the above method embodiment.

[0234] It should be understood that the above-mentioned processing device can be a chip. Fig. 9 , Fig. 9 A structural block diagram of a chip provided in an embodiment of the present application. Fig. 9 The chip shown may be a general-purpose processor or a dedicated processor. The chip 500 may include at least one processor 501. The at least one processor 501 may be used to execute Figures 1 to 8 The technical solution shown in any one of the embodiments.

[0235] Optionally, the chip 500 may further include a transceiver 502, which is used to accept the control of the processor 501 and to execute Figures 1 to 8 The technical solution shown in any one of the embodiments. Optionally, Fig. 9 The chip 500 shown may further include a storage medium 503. Specifically, the transceiver 502 may be replaced by a communication interface, and the communication interface provides information input and / or output for the at least one processor 501.

[0236] It should be noted that Fig. 9 The chip 500 shown can be implemented using the following circuits or devices: one or more field programmable gate arrays (FPGA), programmable logic devices (PLD), application specific integrated circuits (ASIC), system on chip (SoC), central processor unit (CPU), network processor (NP), digital signal processor (DSP), micro controller unit (MCU), controller, state machine, gate logic, discrete hardware components, any other suitable circuits, or any combination of circuits capable of performing the various functions described throughout this application.

[0237] In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software. The steps of the method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor for execution, or a combination of hardware and software modules in a processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in conjunction with its hardware. To avoid repetition, it is not described in detail here.

[0238] It can be understood that the memory in the embodiments of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can 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), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0239] According to the method provided in the embodiment of the present application, the embodiment of the present application also provides a computer program product, which includes: a computer program or instruction, when the computer program or instruction is run on a computer, the computer executes Figures 1 to 8 A method according to any one of the embodiments shown.

[0240] According to the method provided in the embodiment of the present application, the embodiment of the present application also provides a computer storage medium, which stores a computer program or instruction, and when the computer program or instruction is run on a computer, the computer executes Figures 1 to 8 A method according to any one of the embodiments shown.

[0241] According to the method provided in the embodiment of the present application, the embodiment of the present application also provides an electronic device. The electronic device includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code includes computer instructions, and when the processor executes the computer instructions, the electronic device executes the system recovery method provided in the above embodiment.

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

[0243] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0244] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0245] In addition, each functional module in each embodiment of the present application may be integrated into one processing unit, or each module may exist physically separately, or two or more modules may be integrated into one unit.

[0246] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks or optical disks.

[0247] The above-mentioned embodiments of the present application provide a device, system, processing device, chip, computer storage medium, computer program product, and electronic device for determining the shooting duration, which are all used to execute the method provided above. Therefore, the beneficial effects that can be achieved can refer to the corresponding beneficial effects of the method provided above, and will not be repeated here.

[0248] It should be understood that in each embodiment of the present application, the execution order of each step should be determined by its function and internal logic, and the size of the sequence number of each step does not mean the order of execution and does not limit the implementation process of the embodiment.

[0249] Each part of this specification is described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the device, system, chip, computer storage medium, computer program product, and electronic device for determining the duration of photographing, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0250] Although the preferred embodiments of the present application have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0251] The above-described embodiments of the present application do not constitute a limitation on the protection scope of the present application.

Claims

1. A system recovery method, characterized in that: The method is applied to an electronic device, and the method comprises: When the system of the electronic device is restarted, obtaining the latest fault information; Determining the fault type of the electronic device based on the latest fault information; In the case where the fault type is a peripheral device fault, determining the faulty peripheral device; The faulty peripheral device is prohibited from starting.

2. The method according to claim 1, characterized in that After determining the faulty peripheral device, the method further includes: In the case that the faulty peripheral device does not include a display screen or a touch sensor, a first prompt message is displayed, where the first prompt message is used to prompt a user whether to isolate the faulty peripheral device.

3. The method according to claim 2, characterized in that The prohibiting the faulty peripheral device from starting up comprises: In response to receiving an isolation confirmation operation input by a user, prohibiting the faulty peripheral device from starting; or, In the case where the faulty peripheral device includes a display screen or a touch sensor, the faulty peripheral device is prohibited from starting.

4. The method according to any one of claims 1 to 3, characterized in that The prohibiting the faulty peripheral device from starting up comprises: Acquire a device tree corresponding to the electronic device; the device tree includes a plurality of nodes, and the plurality of nodes respectively correspond to peripheral devices in the electronic device; Modify the state of the node corresponding to the faulty peripheral device in the device tree to a disabled state; Based on the modified device tree, each peripheral device in the electronic device is started; wherein a faulty peripheral device in a disabled state is not started.

5. The method according to claim 4, characterized in that Before acquiring the device tree corresponding to the electronic device, the method further includes: In the case that the electronic device includes multiple device trees, a device tree corresponding to the electronic device is determined from the multiple device trees; wherein the multiple device trees correspond to different series of electronic devices, respectively, and the peripheral device parameters corresponding to different series of electronic devices are different.

6. The method according to claim 4, characterized in that The step of starting each peripheral device in the electronic device based on the modified device tree includes: Each node in the device tree is traversed, and the peripheral devices corresponding to each node are started based on the status of each node; wherein the peripheral devices corresponding to the nodes in the started state are started, and the peripheral devices corresponding to the nodes in the disabled state are not started.

7. The method according to claim 4, characterized in that The step of starting each peripheral device in the electronic device based on the modified device tree includes: Based on the modified device tree and the startup priority of each peripheral device, each peripheral device in the electronic device is started; wherein the peripheral devices corresponding to the nodes in the startup state are started, and the peripheral devices corresponding to the nodes in the disabled state are not started.

8. The method according to claim 1, characterized in that The method further comprises: In response to the system of the electronic device being in a backup file system dump mode, the fault information in the memory of the electronic device is transferred to a disk.

9. The method according to claim 8, characterized in that When the system of the electronic device is restarted, the latest fault information is obtained, including: When the system of the electronic device is restarted, the latest fault information is obtained from the disk.

10. The method according to claim 9, characterized in that The method further comprises: After the system of the electronic device is restarted, determining whether the disk of the electronic device includes the latest fault information; In the case that the disk of the electronic device includes the latest fault information, second prompt information is generated, and the second prompt information is used to prompt the user that the faulty peripheral device has a fault.

11. The method according to claim 1, characterized in that: The method further comprises: After the system of the electronic device is restarted, monitoring whether the electronic device fails; When a fault is detected in the electronic device, fault information corresponding to the fault is saved in the memory of the electronic device, and a restart operation is triggered.

12. An electronic device, characterized in that: The electronic device comprises a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code comprises computer instructions, and when the processor executes the computer instructions, the electronic device executes the method as described in any one of claims 1-11.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program or instructions. When the computer program or instructions are executed, the method according to any one of claims 1 to 11 is executed.

Images