Starting method and device of embedded equipment, storage medium and embedded equipment
By automatically detecting and repairing data partition mounting failures when the embedded device is powered on, stable device startup and rapid recovery are achieved, solving the startup failure problem caused by data partition corruption and ensuring device continuity and maintainability.
Patent Information
- Application Number
- CN202511595037.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-03
- Publication Date
- 2026-01-30
Smart Images

Figure CN121433754A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of embedded devices, and in particular to a starting method and device of an embedded device, a storage medium and an embedded device. BACKGROUND
[0002] An embedded device usually adopts a partition storage architecture, and stores firmware and configuration data in different partitions of the same memory. In these partitions, the root file system partition is usually set as a read-only attribute to ensure the integrity and stability of the system core files; and the data partition is designed as a read-write attribute to store various configuration parameters and dynamic data generated during the running of an application. Since the data partition needs to frequently perform write operations, and the embedded device often faces unstable power supply conditions such as unexpected power failure, the data partition has a high risk of file system damage. Once the data partition is damaged, the embedded device cannot normally load the necessary configuration parameters during the starting process, thereby causing system starting failure and affecting the normal function running of the device. SUMMARY
[0003] The present application provides a starting method and device of an embedded device, a storage medium and an embedded device, which can solve the problem that the existing technology cannot normally start the embedded device due to data partition damage. The technical solution is as follows: In a first aspect, the present application provides a starting method of an embedded device, which comprises: When the embedded device is powered on, performing a mounting operation on a data partition of a NOR flash memory; Obtaining a mounting result of the data partition; If the mounting result is mounting failure, recording error description data of the mounting operation into a log file, and starting a repair process for performing a repair process, the repair process comprising: unmounting the data partition, performing an erasing operation on the data partition, reading a default configuration file in a root file system partition of the NOR flash memory, writing the default configuration file into the data partition, after successfully writing the default configuration file, remounting the data partition, and restarting the application according to default parameters in the default configuration file when the data partition is mounted successfully; If the mounting result is mounting success, normally starting the application by using configuration parameters in the data partition.
[0004] In a second aspect, the present application provides a starting device of an embedded device, which comprises: A mounting unit, configured to perform a mounting operation on a data partition of a NOR flash memory when the embedded device is powered on; An obtaining unit, configured to obtain a mounting result of the data partition; the mounting operation is recorded into a log file, and a repair process for executing a repair procedure is started, the repair procedure including: unmounting the data partition, performing an erase operation on the data partition, reading a default configuration file in a root file system partition of the NOR flash memory, writing the default configuration file into the data partition, after successfully writing the default configuration file, remounting the data partition, and when the data partition is mounted successfully, restarting the application according to default parameters in the default configuration file; a starting unit configured to, if the mounting result is mounting success, start the application normally by using configuration parameters in the data partition.
[0005] In a third aspect, an embodiment of the present application provides a computer storage medium, which stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and performing the method steps described above.
[0006] In a fourth aspect, an embodiment of the present application provides a terminal device, which can include a processor and a memory, wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and performing the method steps described above.
[0007] The technical solutions provided by some embodiments of the present application have at least the following beneficial effects: By automatically detecting the mounting state and triggering the repair procedure, unattended processing of data partition faults is realized, the risk of device downtime caused by file system damage is significantly reduced, and the continuity of device operation in industrial control, smart home and other application scenarios is ensured. The method of storing the default configuration file in the root file system partition ensures the integrity of the system core file and provides a reliable configuration source for data partition repair. The cooperative design of the read-only and read-write partitions ensures system stability while taking into account the flexibility of configuration updates. By recording detailed error description data into a non-volatile log file, complete data support is provided for subsequent device maintenance and fault analysis, effectively improving the maintainability of the device. The entire repair procedure uses a standardized operation sequence, from partition erasing to default configuration writing, to remounting and restarting the application, forming a complete automated recovery chain, which greatly shortens the time required for the device to recover from failure. BRIEF DESCRIPTION OF DRAWINGS
[0008] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.
[0009] Figure 1 is a network architecture schematic diagram provided by the embodiments of the present application; Figure 2 is a flowchart of a starting method of an embedded device provided by the embodiments of the present application; Figure 3 is a structural schematic diagram of a starting device of an embedded device provided by the present application; Figure 4 is a schematic diagram of a computer storage medium provided by the embodiments of the present application; Figure 5 is a structural schematic diagram of an embedded device provided by the present application. DETAILED DESCRIPTION
[0010] In order to make the purpose, technical solutions and advantages of the present application more clear, the embodiments of the present application will be further described in detail below with reference to the drawings.
[0011] It should be noted that the starting method of the embedded device provided by the present application is generally executed by the embedded device, and correspondingly, the starting device of the embedded device is generally arranged in the embedded device.
[0012] Figure 1 An exemplary system architecture that can be applied to the starting method of the embedded device or the starting device of the embedded device of the present application is shown.
[0013] As shown in Figure 1 , the system architecture can include an embedded device 101 and a server 102. The embedded device 101 and the server 102 can communicate through a network, and the network is a medium for providing a communication link between the above-mentioned units. The network can include various types of wired communication links or wireless communication links, for example, the wired communication links include optical fiber, twisted pair or coaxial cable, etc., and the wireless communication links include Bluetooth communication link, wireless fidelity (WIreless-FIdelity, Wi-Fi) communication link or microwave communication link, etc.
[0014] Among them, the embedded device 101 collects related data (such as video data, device state data, and field environment data) on the spot, and transmits the collected data to the server 101 through the network for analysis and processing.
[0015] It should be noted that the embedded device 101 and the server 102 can be hardware or software. When the embedded device 101 and the server 102 are hardware, a distributed server cluster composed of multiple servers can be implemented, or a single server can be implemented. When the embedded device 101 and the server 102 are software, multiple software or software modules (for example, used to provide distributed services) can be implemented, or a single software or software module can be implemented, which is not limited here.
[0016] Various communication client applications can be installed on the embedded device of the present application, such as a video recording application, a video playing application, a voice interaction application, a search application, an instant messaging tool, a mailbox client, a social platform software, etc.
[0017] The embedded device can be hardware or software. When the embedded device is hardware, it can be various embedded devices with a display screen, including but not limited to a camera, a router, a home gateway, a smart meter, etc.
[0018] It should be understood that Figure 1 The number of embedded devices, networks and servers in the above is only illustrative. According to the implementation needs, there can be any number of embedded devices, networks and servers.
[0019] The above will be described in detail below with reference to the accompanying drawings Figure 2 The starting method of the embedded device provided by the embodiment of the present application will be described in detail. The starting device of the embedded device in the embodiment of the present application can be the embedded device shown in Figure 1
[0020] Please refer to Figure 2 A flowchart of a starting method of an application program in an embedded device is provided by the embodiment of the present application. As shown in Figure 2 The method of the embodiment of the present application can include the following steps: S1, when the embedded device is powered on, performing a mounting operation on the data partition of the NOR flash memory.
[0021] In the power-on initialization process of the embedded device, the processor first performs a mounting operation on the data partition in the NOR flash memory. The NOR flash memory is divided into multiple functional partitions, including a bootloader partition, an environment variable partition, a kernel partition, a root file system partition, a data partition, and a device information partition. The size of each partition is accurately divided according to system requirements to fully utilize the storage space. Among them, the data partition is specially used to store various configuration parameters required by the application program during the startup process, which are crucial for the normal initialization and running of the application program. The mounting operation is a process of associating the data partition with the file system directory of the embedded device by specifying the file system type and mounting parameters, so that the processor can access and read the configuration parameters therein.
[0022] For example, in a NOR flash memory with a capacity of 8MB, the space allocation of each functional partition is as follows: the bootloader partition occupies 128KB, the environment variable partition occupies 64KB, the kernel partition occupies 2000KB, the root file system partition occupies 5488KB, the data partition occupies 448KB, and the device information partition occupies 64KB. In the application scenario of a smart home controller, when the device is powered on and starts, the processor will perform a mounting operation. This operation is implemented through specific mounting instructions, for example: the mounting instruction can specify that the flash file system type is jffs2, which is designed specifically for flash devices; the device node corresponding to the data partition is specified, which represents the fifth storage block in the NOR flash memory; and the mounting point path in the system directory is specified. Through this complete mounting instruction, the processor successfully associates the data partition with the file system. The data partition stores important information such as network connection configuration and device running parameters, and by successfully completing the mounting operation, the processor can access these configuration parameters, laying the foundation for the normal startup of subsequent application programs.
[0023] S2, obtaining the mounting result of the data partition.
[0024] After completing the mounting operation of the data partition, the processor needs to obtain and confirm the execution result of the operation. This step is implemented by detecting the status information returned by the system to determine whether the data partition has been successfully integrated into the file system of the embedded device. Obtaining the mounting result is a key basis for determining the direction of the subsequent process, and the processor decides whether to continue the normal startup process or to enter the error handling program according to the result.
[0025] For example, during the running of a smart home controller, the processor will query the system interface to obtain the operation result status after executing the mounting instruction. If a success status is returned, it indicates that the data partition has been correctly mounted; if an error status is returned, it indicates that the mounting process encounters an obstacle. Taking an industrial gateway device as an example, the processor determines whether the key configuration parameters stored in the data partition can be normally accessed by analyzing the return value of the system call, and this determination result will directly affect the subsequent startup process of the device.
[0026] S3, if the mounting result is mounting failure, the error description data of the mounting operation is recorded into a log file, and a repair process for executing a repair process is started, the repair process comprising: unmounting the data partition, performing an erasing operation on the data partition, reading a default configuration file in the root file system partition of the NOR flash memory, writing the default configuration file into the data partition, after successfully writing the default configuration file, remounting the data partition, and when the data partition is mounted successfully, restarting the application according to the default parameters in the default configuration file.
[0027] When the mounting result obtained by the processor indicates that the data partition mounting fails, the processor will execute a preset fault handling process: firstly, the error description data generated in the mounting operation process is recorded into the non-volatile log file of the embedded device, forming a system fault record for subsequent analysis. Subsequently, the processor starts an independent repair process, which is specially responsible for executing the systematic repair process of the data partition.
[0028] The repair process contains a series of ordered operation steps. The repair process firstly unmounts the data partition which has been mounted but has a fault from the file system, ensuring the safety of subsequent operations. Then, a comprehensive erasing operation is performed on the data partition to clear the abnormal data and damaged storage structure in the partition. Subsequently, the repair process reads the pre-stored default configuration file from the root file system partition of the NOR flash memory, which contains the parameter settings necessary to ensure the basic running of the application. The repair process writes the default configuration file into the data partition which has completed erasing, and after confirming that the configuration file is successfully written, the data partition is remounted. When the data partition is successfully mounted, the processor restarts the application according to the default parameters contained in the default configuration file, so that the embedded device returns to the normal working baseline state.
[0029] For example, in the application scenario of a smart home gateway device, when the data partition fails to mount due to file system corruption caused by abnormal power-off, the processor records specific error description information such as file system verification failure in the system log. The subsequently started repair process first unmounts the abnormal data partition, then performs a complete erase on the partition, then reads a default configuration file containing basic network configuration and device parameters from the root file system partition, and writes it completely to the data partition. After completing the writing, the system remounts the data partition, and restarts the home automation control application according to the network connection parameters and device identifiers in the default configuration.
[0030] In the application scenario of an industrial controller, when mounting fails due to storage medium damage, the repair process performs a similar recovery process. By first unmounting the faulty partition, then performing an erase operation, obtaining a default configuration file from the root file system and writing it to the data partition, and finally restarting the industrial control application based on the default process parameters and control settings, the production system can be ensured to resume normal operation state in the shortest time.
[0031] S4, if the mounting result is mounting success, the application program is normally started by using the configuration parameters in the data partition.
[0032] When the mounting result obtained by the processor indicates that the data partition is mounted successfully, the processor will perform a normal application program startup process. In this case, the processor directly reads the stored configuration parameters from the mounted data partition, which contain various setting information required for application program running. The processor completes the initialization work of the application program according to these configuration parameters, including configuring the running environment, setting the function modules, and establishing the necessary system connections, so as to ensure that the application program can be normally started and put into operation according to the expected working mode.
[0033] For example, in the application scenario of a smart home control device, when the data partition is successfully mounted, the processor reads the device network configuration parameters stored therein, including wireless network connection information, device identity identifier, and user personalized settings, etc. Based on these parameters, the processor successfully starts the home automation management application program, establishes communication connection with each smart terminal, and loads the user preset scene mode. In the application example of an industrial control device, after the data partition is successfully mounted, the processor reads the production process parameters and device running configuration stored therein, and accordingly starts the production line monitoring application program to realize accurate control of each execution unit and real-time monitoring of the running state.
[0034] In one possible embodiment, the restarting of the application program by using the default parameters in the default configuration file includes: S31, determine the storage location information of all start parameters of the application program in the NOR flash memory, and determine the start parameters located in the data partition according to the storage location information; S32, query the corresponding default parameters in the default configuration file according to the storage location information; S33, restart the application program according to the default parameters.
[0035] Specifically, in step S31, in the process of restarting the application program according to the default configuration file, the processor first needs to determine the specific storage location information of all start parameters of the application program in the NOR flash memory. Each functional partition of the NOR flash memory stores different types of start parameters, and the processor establishes a complete parameter storage location distribution map by analyzing the system configuration mapping relationship. After the storage location of all start parameters is clear, the processor further screens out the part of start parameters located in the data partition according to the storage location information, to provide accurate basis for subsequent parameter acquisition and application program recovery.
[0036] For example, in the smart home gateway device, the processor analyzes the configuration requirements of the home automation control application program, and determines that the start parameters to be acquired include the wireless network configuration parameters stored in the data partition and the device running mode parameters stored in the environment variable partition. In the industrial control device, the processor needs to determine the necessary start parameters of the production line monitoring application program, including the communication protocol parameters in the data partition and the system log level parameters in the environment variable partition.
[0037] In step S32, after determining all start parameter items and their storage locations required by the application program, the processor queries the default parameter values corresponding to these parameter items in the default configuration file and each related functional partition. The default configuration file is stored in the root file system partition, and other functional partitions also save the default parameter settings in their respective fields. The processor performs systematic matching and searching in each storage location through parameter item identification to obtain the corresponding default parameter values. These default parameters can ensure that the application program can still start normally and perform core functions in the absence of user configuration.
[0038] For example, in the application scenario of the smart home gateway, the processor will obtain the preset default network identifier when querying the wireless network name parameter item in the default configuration file, and will obtain the preset standard running mode value when querying the device running mode parameter item in the environment variable partition. For industrial control devices, the processor will obtain the preset value of the standard communication protocol when querying the communication protocol parameter item in the data partition default configuration, and will obtain the optimized default log level setting when querying the system log level parameter item in the environment variable partition.
[0039] In step S33, after successfully obtaining all the required default parameter values, the processor restarts the application according to the parameter values from different storage locations. The processor integrates the obtained various default parameters and applies them to the initialization process of the application, configures the running environment and functional modules of the application, establishes necessary external connections, and finally completes the startup process of the application. This process ensures that even if the data partition configuration is lost, the application can still recover to a normal running state based on reliable default parameters from each functional partition.
[0040] For example, in a smart home gateway device, the processor uses the network parameters obtained from the default configuration file and the device running parameters obtained from the environment variable partition to restart the home automation control application, and establishes a complete running environment based on multi-source default parameters. In an industrial control device, the processor integrates the communication protocol parameters in the data partition default configuration and the system log parameters in the environment variable partition to restart the production line monitoring application, ensuring that the production system recovers to a safe running state in a complete configuration environment.
[0041] In one or more possible embodiments, further comprising: S5, after the application is successfully started, a partition health monitoring process is started, and the partition health monitoring process is used for periodically detecting abnormalities of the data partition; S6, if it is detected that the data partition has an abnormality, a repair process is started to perform the repair process.
[0042] Specifically, in step S5, after the application is successfully started, the processor starts a separate partition health monitoring process. The monitoring process runs in the form of a background service and is responsible for periodically detecting the health status of the data partition. The monitoring process checks the storage integrity, data readability, and file system status of the data partition through a preset detection mechanism, thereby achieving early detection and early warning of potential abnormalities in the data partition.
[0043] For example, in a smart home gateway device, the processor starts a partition health monitoring process after the home control application is normally running. The process performs an integrity scan on the data partition at fixed time intervals to check the structural integrity and access permissions of the configuration file.
[0044] In step S6, when the partition health monitoring process detects an abnormality in the data partition, the processor immediately starts a repair process to perform the repair process. Abnormalities include, but are not limited to, file system errors, data verification failures, or storage block damage. The repair process is described in the description, and will not be described here. By performing a complete repair process, the normal state of the data partition is restored, ensuring the continuous and stable operation of the embedded device.
[0045] For example, in the process of running the smart home gateway, when the monitoring process finds that the configuration file index of the data partition is damaged, the processor automatically triggers the repair process to perform data partition erasure and default configuration file recovery operation. In the industrial controller application scenario, if the monitoring process detects that the read-write error rate of the data partition storage block exceeds the threshold, the processor immediately starts the repair process to rewrite the default process parameters from the root file system partition, ensuring the continuous and stable operation of the production system.
[0046] In one possible embodiment, the partition health monitoring process is configured to periodically perform anomaly detection on the data partition, including: S51, when detecting that the integrity check of the data partition fails, determining that the data partition is abnormal; or S52, listening to the kernel log, and when detecting that the kernel log includes IO error information of the data partition, determining that the data partition is abnormal; or S53, calculating the health score of the data partition, and when the health score is less than the score threshold, determining that the data partition is abnormal.
[0047] In S51, in the process of periodically performing anomaly detection on the data partition by the partition health monitoring process, when detecting that the integrity check of the data partition fails, the processor will determine that the data partition is abnormal. The integrity check is a process of verifying the storage content of the data partition by using a cyclic redundancy check algorithm or a hash check algorithm. The cyclic redundancy check algorithm verifies data integrity by calculating the polynomial remainder of the data, and the hash check algorithm generates a data digest by using a one-way hash function for comparison. These check algorithms aim to ensure the integrity and correctness of the configuration parameters and file system structure stored in the data partition. When the check calculation result does not match the expected baseline value, it indicates that the data partition may have data damage or storage error, and at this time the processor will determine that the data partition is abnormal.
[0048] For example, in the process of running the smart home gateway device, the partition health monitoring process verifies the integrity of the configuration file in the data partition by using the cyclic redundancy check algorithm. Specifically, the CRC32 algorithm is used to calculate the checksum of the configuration parameters, and when the calculation result does not match the standard value stored in advance, the processor determines that the data partition has data anomaly. In the industrial control device, the monitoring process uses the SHA-256 hash algorithm to generate a 256-bit hash value for integrity check of the process parameter file in the data partition, and if the generated hash value does not match the expected baseline value, it is confirmed that the data partition has storage anomaly, and at this time the processor will start the corresponding repair mechanism.
[0049] In S52, during the running of the partition health monitoring process, the processor simultaneously performs a continuous monitoring operation on the system kernel log. The monitoring operation monitors whether the input / output error information related to the data partition is contained in the log information generated during the running of the kernel by real-time analysis of the log information. When the processor identifies the input / output error record directly pointing to the data partition in the monitored kernel log, it is determined that the data partition is abnormal. These input / output error information usually shows the specific forms of read / write operation failure, storage access timeout or medium access error, which directly reflects the fault state of the data partition in the underlying storage access process.
[0050] In S53, in the partition health monitoring process, the processor quantitatively evaluates the running state of the data partition by calculating the health score of the data partition. The health score is the comprehensive calculation result based on multiple evaluation indexes, and the processor uses a weighted calculation formula to comprehensively evaluate each index.
[0051] The read / write error rate refers to the frequency of read / write operation errors of the data partition per unit time, which is specifically the ratio of the number of read / write failure operations to the total number of operations, and this parameter directly reflects the basic read / write function state of the data partition.
[0052] The number of verification failures refers to the cumulative number of data errors or checksum mismatches found in the integrity verification process, and this parameter reflects the reliability and integrity of the stored data in the data partition.
[0053] The storage block damage ratio refers to the ratio of the number of storage blocks marked as unusable to the total number of storage blocks in the data partition, and this parameter reflects the degree of wear of the physical storage medium of the data partition.
[0054] The access response delay refers to the average time length required for the processor to obtain a response after initiating an access request to the data partition, and this parameter represents the access performance state of the data partition.
[0055] The processor comprehensively calculates the above indexes by using a weighted calculation formula S=W1xA1+W2xA2+W3xA3+W4xA4, A1 represents the read / write error rate, A2 represents the number of verification failures, A3 represents the storage block damage ratio, and A4 represents the access response delay, wherein W1 to W4 are weight coefficients corresponding to the indexes. When the calculated health score is lower than the preset score threshold, the processor determines that the data partition is abnormal.
[0056] The determination process of the score threshold is based on the statistical analysis result of long-term running characteristics of the data partition. The processor first collects score samples of the data partition in various working states, including score distribution in normal state and abnormal state, in the device trial running stage. Through statistical analysis on these sample data, the processor determines the critical score value that can effectively distinguish the normal state from the abnormal state, and sets the critical value as the score threshold.
[0057] In one or more possible embodiments, the mounting operation performed on the readable and writable data partition includes: S11, reading partition layout data of the NOR flash memory, the partition layout data recording the start address and capacity size of each functional partition in the NOR flash memory; S12, determining the storage location of the data partition according to the partition layout data, and loading the file system driver of the data partition according to the storage location; S13, after successful loading, issuing a mounting instruction to the operating system, the mounting instruction being used to associate the data partition to a file system directory.
[0058] Specifically, in the startup process of the embedded device, the processor first reads the partition layout data stored in the NOR flash memory. These partition layout data record the start address and capacity size information of each functional partition in the NOR flash memory in detail, constituting a complete storage space distribution atlas. The processor establishes accurate knowledge of the overall organization structure of the NOR flash memory by analyzing these basic data, and provides necessary spatial positioning basis for subsequent operations on specific partitions.
[0059] For example, in a smart home gateway device, the processor reads the partition layout table from the fixed position of the NOR flash memory, which explicitly records that the bootloader partition has a start address of 0x00000000 and a capacity of 128KB, and the data partition has a start address of 0x00700000 and a capacity of 448KB. In an industrial control device, the processor obtains the start address of the kernel partition as 0x00030000 and the capacity as 2000KB by analyzing the partition layout data, laying a foundation for subsequent accurate positioning of the data partition.
[0060] After obtaining the partition layout data, the processor determines the specific storage location information of the data partition according to these data. Based on the determined storage location of the data partition, the processor further loads the file system driver matched with the data partition. The file system driver is a software module used to analyze and access a specific file format, and its correct loading is a prerequisite for ensuring that the data partition can be normally recognized and accessed.
[0061] After the file system driver is successfully loaded, the processor initiates a mounting instruction to the operating system. The mounting instruction contains key parameters such as the device identifier of the data partition and the target mounting point path, and its core function is to associate the data partition with a specific directory in the embedded device file system. Through this association operation, the files and configuration parameters in the data partition can be accessed and used by the application program through the standard file system interface.
[0062] In one or more possible embodiments, the writing of the default configuration file into the data partition comprises: performing integrity verification on the default configuration file; if the verification is passed, detecting whether the format of the default configuration file is compatible with the data partition; if not, performing format conversion on the default configuration file; writing the format-converted default configuration file into the data partition.
[0063] Specifically, in the process of writing the default configuration file into the data partition, the processor first performs integrity verification on the default configuration file read from the root file system partition. The integrity verification adopts a cyclic redundancy check algorithm or a hash check algorithm, wherein the cyclic redundancy check algorithm calculates a check code through polynomial division, and the hash check algorithm generates a fixed-length message digest through a one-way hash function.
[0064] The specific verification process of the cyclic redundancy check algorithm includes: first regarding the data to be verified as a binary polynomial, then performing modulo-2 division operation using a specific generator polynomial, and finally obtaining the remainder as the check code. The processor compares the calculated check code with the pre-stored reference check code to verify the integrity of the data.
[0065] The specific verification process of the hash check algorithm includes: grouping the configuration file data through a hash function, performing multiple rounds of logical operations and shift operations, and finally generating a fixed-length hash value. The processor strictly compares the calculated hash value with the reference hash value to confirm that the configuration file has not been tampered with or damaged during transmission.
[0066] If the verification result meets the expectation, the processor continues to detect whether the format of the default configuration file is compatible with the file system format of the data partition. When detecting that the formats are incompatible, the processor starts a format conversion process to convert the default configuration file into a format supported by the data partition. Finally, the processor writes the format-converted default configuration file into the data partition that has completed the erasing operation.
[0067] For example, in a smart home gateway device, the processor uses the CRC32 cyclic redundancy check algorithm to verify the integrity of the default configuration file. The verification process first divides the configuration file data into multiple data blocks, performs polynomial division operation on each data block to generate a 32-bit check code, and finally compares all check codes with the reference value pre-stored in the root file system. After verification, if the configuration file format is found to be incompatible with the data partition, the corresponding format conversion operation is performed.
[0068] In one or more possible embodiments, the recording of the error description data of the mounting operation into the log file comprises: obtaining original error data including error code and error description text from the operating system kernel; adding a timestamp and a device identifier to the original error data to generate structured error description data; writing the error description data into a log file in a non-volatile storage area.
[0069] When the mounting operation fails, the processor performs an error information recording process. First, the processor obtains original error data from the operating system kernel, which contains specific error codes and corresponding error description texts. The error code is a numerical identifier returned by the operating system kernel, and the error description text is a detailed textual description of the error code.
[0070] Subsequently, the processor adds a timestamp and a device identifier to the original error data to generate structured error description data. The timestamp records the precise time information of the error occurrence, and the device identifier is used to uniquely identify the embedded device where the error occurs. This step integrates the scattered error information into structured data with complete context.
[0071] Finally, the processor writes the structured error description data into a log file stored in a non-volatile storage area. The non-volatile storage area ensures the long-term preservation of error records, and the error information will not be lost even after the device is powered off. The log file organizes these error records in a specific format, facilitating subsequent problem analysis and system diagnosis.
[0072] The following is an embodiment of the device of the present application, which can be used to execute the method embodiment of the present application. For details not disclosed in the device embodiment of the present application, please refer to the method embodiment of the present application.
[0073] Please refer to Figure 3 which shows the structure diagram of the starting device of the embedded device provided by an exemplary embodiment of the present application, hereinafter referred to as device 3. The device 3 can be realized by software, hardware or a combination of the two to become all or part of the embedded device. The device 3 comprises: The mounting unit 301 is configured to perform a mounting operation on a data partition of the NOR flash memory when the embedded device is powered on. The acquisition unit 302 is configured to acquire a mounting result of the data partition. The repair unit 303 is configured to, if the mounting result is a mounting failure, record error description data of the mounting operation into a log file, and start a repair process for performing a repair procedure, the repair procedure including: unmounting the data partition, performing an erasing operation on the data partition, reading a default configuration file in a root file system partition of the NOR flash memory, writing the default configuration file into the data partition, after successfully writing the default configuration file, remounting the data partition, and when the data partition is mounted successfully, restarting the application according to a default parameter in the default configuration file. The starting unit 304 is configured to, if the mounting result is a mounting success, normally start the application by using a configuration parameter in the data partition.
[0074] In one or more possible embodiments, the restarting the application according to the default parameter in the default configuration file includes: determining storage location information of all starting parameters of the application in the NOR flash memory, and determining starting parameters located in the data partition according to the storage location information; querying a corresponding default parameter in the default configuration file according to the default parameter; restarting the application according to the default parameter.
[0075] In one or more possible embodiments, the method further includes: The monitoring unit is configured to, after the application is successfully started, start a partition health monitoring process, the partition health monitoring process being configured to periodically detect an exception of the data partition. If it is detected that the data partition has an exception, a repair process is started to perform the repair procedure.
[0076] In one or more possible embodiments, the partition health monitoring process periodically detecting an exception of the data partition includes: detecting that the data partition has an exception when it is detected that an integrity check of the data partition fails; or detecting that the data partition has an exception when it is detected that IO error information of the data partition is included in a kernel log; or calculating a health score of the data partition, determining that the data partition is abnormal when the health score is less than a score threshold; S = W1 x A1 + W2 x A2 + W3 x A3 + W4 x A4, S represents the health score of the data partition, A1 represents a read-write error rate, A2 represents a number of check failures, A3 represents a storage block damage ratio, A4 represents an access response delay, and W1 to W4 are weight coefficients corresponding to the indexes.
[0077] In one or more possible embodiments, the mounting operation is performed on the read-write data partition, including: reading partition layout data of the NOR flash memory, the partition layout data indicating start addresses and capacity sizes of respective functional partitions in the NOR flash memory; determining a storage location of a data partition according to the partition layout data, and loading a file system driver of the data partition according to the storage location; after successful loading, issuing a mounting instruction to an operating system, the mounting instruction being used to associate the data partition to a file system directory.
[0078] In one or more possible embodiments, the writing of the default configuration file into the data partition includes: performing integrity verification on the default configuration file; if the verification is passed, detecting whether a format of the default configuration file is compatible with the data partition; if not, performing format conversion on the default configuration file; writing the format-converted default configuration file into the data partition.
[0079] In one or more possible embodiments, the recording of the error description data of the mounting operation into a log file includes: obtaining original error data including an error code and an error description text from an operating system kernel; adding a time stamp and a device identifier to the original error data to generate structured error description data; writing the error description data into a log file of a non-volatile storage area.
[0080] It should be noted that the apparatus 3 provided in the above embodiments is only used as an example for dividing the above functional modules when the starting method of the embedded device is executed, and in actual applications, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above functions. In addition, the starting apparatus of the embedded device and the starting method of the embedded device provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.
[0081] The above sequence numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.
[0082] Referring to Figure 4 FIG. 1 is a schematic diagram of a computer storage medium provided by an embodiment of the present application, which can store a plurality of instructions (i.e. Figure 4 the computer program shown in the figure), which are suitable for being loaded and executed by a processor to implement the method steps of the embodiment shown in Figure 2 FIG. 2, and the specific implementation process can be referred to the specific description of the embodiment shown in FIG. 3, which will not be repeated here. Figure 2
[0083] The present application also provides a computer program product, which stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the starting method of the embedded device as described in each of the above embodiments.
[0084] Referring to Figure 5 , an embedded device provided by an embodiment of the present application is shown in a structural schematic diagram. As Figure 5 shown, the embedded device 500 can include at least one processor 501, at least one network interface 504, a user interface 503, a memory 505, and at least one communication bus 502.
[0085] The communication bus 502 is used to realize the connection and communication between the components.
[0086] The user interface 503 is used to communicate with the user interaction device, and the interaction device includes a mouse, a keyboard, a display screen, a touch screen, etc.
[0087] The network interface 504 can optionally include a standard wired interface, a wireless interface (such as a WI-FI interface).
[0088] The processor 501 can include one or more processing cores. The processor 501 connects various parts within the entire embedded device 500 by various interfaces and lines, and performs various functions of the embedded device 500 and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 505, and calling data stored in the memory 505. Alternatively, the processor 501 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 501 can integrate a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes operating systems, user interfaces, and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; and the modem is used for processing wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 501, but can be realized by a separate chip.
[0089] The memory 505 can include a random access memory (RAM) and can also include a read-only memory (ROM). Optionally, the memory 505 includes a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 505 can include a program storage area and a data storage area, wherein the program storage area can store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area can store data involved in the above-mentioned various method embodiments, etc. The memory 505 can also be at least one storage device located away from the aforementioned processor 501. As shown in the figure, the memory 505 as a computer storage medium can include an operating system, a network communication module, a user interface module, and an application program. Figure 5 As shown in the figure, the memory 505 as a computer storage medium can include an operating system, a network communication module, a user interface module, and an application program.
[0090] In Figure 5In the embedded device 500 shown, the user interface 503 is mainly used to provide an interface for the user to input, and obtain data input by the user; and the processor 501 can be used to call an application stored in the memory 505, and specifically execute the method as shown in Figure 2 The specific process can refer to the method shown in Figure 2 The specific process can refer to the method shown in
[0091] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by a computer program instructing related hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it can include the processes of the above-mentioned embodiments of the method. The storage medium can be a magnetic disc, an optical disc, a read-only memory or a random access memory, etc.
[0092] The above only discloses the preferred embodiments of the present application, and of course cannot limit the scope of the rights of the present application, so equivalent changes made according to the claims of the present application are still within the scope of the present application.
Claims
1. A method of starting an embedded device, characterized by, The application comprises the following steps: When the embedded device is powered on, a mounting operation is performed on a data partition of a NOR flash memory; A mounting result of the data partition is obtained; If the mounting result is a mounting failure, error description data of the mounting operation is recorded in a log file, and a repair process for performing a repair procedure is started, the repair procedure comprising: unmounting the data partition, performing an erasing operation on the data partition, reading a default configuration file in a root file system partition of the NOR flash memory, writing the default configuration file into the data partition, after successfully writing the default configuration file, remounting the data partition, and restarting the application according to default parameters in the default configuration file when the data partition is successfully mounted; If the mounting result is a mounting success, the application is normally started by using configuration parameters in the data partition.
2. The method of claim 1, wherein, The application comprises the following steps: All starting parameters of the application are determined in the storage location information in the NOR flash memory, and starting parameters located in the data partition are determined according to the storage location information; The corresponding default parameters are queried in the default configuration file; The application is restarted according to the default parameters.
3. The method according to claim 1 or 2, characterized in that, The application further comprises the following steps: After the application is successfully started, a partition health monitoring process is started, which is used for periodically detecting abnormalities of the data partition; If it is detected that the data partition has an abnormality, a repair process is started to perform the repair procedure.
4. The method of claim 3, wherein, The partition health monitoring process is used for periodically detecting abnormalities of the data partition, comprising the following steps: When it is detected that the data partition fails in integrity check, it is determined that the data partition has an abnormality; or Kernel logs are listened to, and when it is detected that the kernel logs include IO error information of the data partition, it is determined that the data partition has an abnormality; or A health score of the data partition is calculated, and when the health score is less than a score threshold, it is determined that the data partition has an abnormality; S=W1×A1+W2×A2+W3×A3+W4×A4, S represents the health score of the data partition, A1 represents a read-write error rate, A2 represents a number of check failures, A3 represents a storage block damage ratio, A4 represents an access response delay, and W1 to W4 are weight coefficients corresponding to the indexes.
5. The method of claim 4, wherein, The mounting operation is performed on the data partition which can be read and written, comprising the following steps: Partition layout data of the NOR flash memory is read, the partition layout data indicating starting addresses and capacity sizes of various functional partitions in the NOR flash memory; A storage location of the data partition is determined according to the partition layout data, and a file system driver of the data partition is loaded according to the storage location; After successful loading, a mounting instruction is initiated to an operating system, the mounting instruction being used for associating the data partition to a file system directory.
6. The method according to claim 4 or 5, characterized in that, The default configuration file is written into the data partition, comprising the following steps: The default configuration file is subjected to integrity check; If the check is passed, it is detected whether the format of the default configuration file is compatible with the data partition; If not, the default configuration file is format-converted; The format-converted default configuration file is written into the data partition.
7. The method of claim 6, wherein, The error description data of the mounting operation is recorded into a log file, including: Raw error data including error code and error description text is obtained from an operating system kernel; A timestamp and a device identifier are added to the raw error data to generate structured error description data; The error description data is written into a log file in a non-volatile storage area.
8. A startup device for an embedded device, characterized in that, Including: A mounting unit is configured to perform a mounting operation on a data partition of a NOR flash memory when the embedded device is powered on; An obtaining unit is configured to obtain a mounting result of the data partition; If the mounting result is a mounting failure, the error description data of the mounting operation is recorded into a log file, and a repair process for performing a repair procedure is started, the repair procedure including: unmounting the data partition, performing an erasing operation on the data partition, reading a default configuration file in a root file system partition of the NOR flash memory, writing the default configuration file into the data partition, after successfully writing the default configuration file, remounting the data partition, and when the data partition is mounted successfully, restarting the application according to default parameters in the default configuration file; If the mounting result is a mounting success, a starting unit is configured to normally start the application by using configuration parameters in the data partition.
9. A computer storage medium, characterized in that The computer storage medium stores a plurality of instructions, the instructions being adapted to be loaded and executed by a processor to perform the method steps of any one of claims 1-7.
10. An embedded device, characterized by Including: A processor and a memory; wherein the memory stores a computer program, the computer program being adapted to be loaded and executed by the processor to perform the method steps of any one of claims 1-7.