A fast recovery method under uncorrectable particle errors in a space environment

Abstract

The application provides a fast recovery method under uncorrectable particle errors in a space environment, and belongs to the field of data processing. The application can use a standby kernel takeover mode to make the system recover from a kernel crash state to a runnable state in a short time, has a low-overhead capture capability for a crash site, saves error logs as much as possible before the operating system crashes, retains key fault information in a persistent storage device, and can actively isolate a conflict memory area before recovery to improve the reliability of the system after recovery.

Description

Technical Field

[0001] This invention belongs to the field of data processing, and in particular relates to a fast recovery method for uncorrectable particle errors in a space environment. Background Technology

[0002] Space computer systems operate in high-energy particle radiation environments, and single-event effects are a major cause of system failures. When errors accumulate or multiple bit flips occur that exceed the corrective capabilities of error-correcting codes, uncorrectable errors (UEs) are formed. If such errors occur in the operating system kernel code, critical data structures, or memory mapping relationships, they often directly lead to system crashes, deadlocks, or hangs, resulting in task interruptions, data loss, and in severe cases, even system failure.

[0003] Current recovery methods for uncorrectable errors in aerospace environments mainly include hardware-level lockstep processors, triple-mode redundancy, and software-level watchdog resets. While hardware redundancy can shield some errors, it significantly increases area, power consumption, and cost. Traditional watchdog resets are essentially a complete cold boot, requiring multiple stages such as firmware self-test, bootloader loading, and hardware reinitialization, which is typically time-consuming and unacceptable for high real-time tasks such as attitude control and data windows. Furthermore, a simple system reboot will lose fault context information in volatile memory, hindering subsequent fault analysis.

[0004] In recent years, the Linux kernel's fast kernel switching mechanism (kexec) has enabled the direct loading and startup of a new kernel while the current kernel is running, skipping the underlying firmware and hardware initialization process, thus achieving kernel switching speeds from milliseconds to seconds. This mechanism has been used in the field of terrestrial servers to achieve fast reboots and hot kernel upgrades.

[0005] For ground server scenarios, the core design goal of existing fast kernel switching mechanisms is to optimize reboot time by skipping firmware initialization. However, they lack protection against uncorrectable errors caused by particle radiation in a space environment (such as memory bit flips and page table corruption), and also fail to implement fault scene capture and storage mechanisms. The shortcomings of existing technologies are as follows: When the crash log saving window is short, critical evidence of the failure is easily lost; Traditional fast kernel switching mechanisms cannot reliably recover when the current environment has a "crash that occurs on a non-zero core" or "inconsistent state of some cores", resulting in incomplete or even failed startup of the backup kernel.

[0006] When the isolation between reserved memory and safe memory in the recovery path is insufficient, accidental overwriting can easily occur, triggering secondary anomalies. Summary of the Invention

[0007] To address the aforementioned shortcomings in existing technologies, this invention provides a fast recovery method for uncorrectable particle errors in a space environment, solving the following problems: 1. In the event of a system crash, save critical crash logs with the least dependent path to reduce the probability of log loss; 2. Improve the success rate of rapid multi-core restart of backup kernels in complex crash scenarios caused by particle errors; 3. Avoid conflicts between the recovery path and the reserved memory area and safe memory area to improve recovery stability; 4. Establish an integrated mechanism that can "both restore quickly and preserve the fault scene".

[0008] To achieve the above objectives, the technical solution adopted by this invention is: a fast recovery method for uncorrectable particle errors in a space environment, comprising the following steps: Establish a fixed retention area required for system crash recovery. The fixed retention area includes at least a processor takeover control area, a crash log snapshot area, and a security area. Record the fixed physical address, length, access attributes, and verification information of the processor takeover control area, crash log snapshot area, and security area. S2. When an uncorrectable particle error is detected in a space environment and triggers a system crash, the system enters the crash handling path. In the crash handling path, first-level evidence preservation is performed, writing the current kernel log snapshot to the crash log snapshot area and refreshing the cache. Then, second-level evidence preservation is performed, collecting the processor exception context, memory error correction status, and high-speed peripheral error status, and writing them to the black box persistent partition. At the same time, the register context of the crashed processor is saved. S3. Based on whether the backup kernel image has been preloaded, whether the backup kernel reserved parameters are valid, whether the backup kernel switching image is available, and whether the fixed reserved area is complete and without address conflicts, determine whether the conditions for backup kernel switching are met. If not all conditions are met, use the offline evidence of the black box persistent partition and combine it with the logs in the crash log snapshot area to generate a fault analysis report and end the process. If all conditions are met, proceed to S4. S4. Based on the processor takeover control area, start the multi-core takeover mechanism, match the physical identity of each processor with the takeover slot, register the processor status, boot entry address and serial number in the corresponding slot, and publish the backup kernel boot entry to the non-master processor. S5, based on the takeover slot, processor status and serial number formed by S4, executes the crash state waiting strategy extension, so that the non-master processor continuously listens to the takeover control area in the waiting event state, and jumps to the backup kernel from the kernel boot entry after the boot entry address and serial number are valid. S6. Based on the defined fixed reserved area and the multi-core wait event state formed by S5, the memory and safe area required for recovery are protected and reconstructed during the backup kernel startup process to prevent the backup kernel from overwriting the crash log snapshot area, the processor takeover control area and the safe memory occupied by the trusted execution environment. S7. Based on the memory and security region reconstruction results, rebuild critical interrupt resources after the backup kernel starts, and read the crash log snapshot and black box persistent evidence saved by S2, output fault analysis information, enable the system to enter a stable operating state after recovery, and end the process.

[0009] Furthermore, the fixed reserved area uses a fixed physical address, including: The processor takeover control area is used to take over control information through a multi-core processor before and after a system crash. The crash log snapshot area is used to write kernel log snapshots when the system crashes, and it uses the "disable ordinary kernel mapping" attribute to prevent ordinary memory allocators from occupying it. The security zone is used to protect the secure memory occupied by the Trusted Execution Environment (TEE) and prevent misuse of the backup kernel.

[0010] Furthermore, the step of first performing level-one evidence preservation in the crash handling path, writing the current kernel log snapshot to the crash log snapshot area and refreshing the cache, includes the following steps: When an uncorrectable particle error is detected in a space environment and triggers a system crash, a log snapshot is performed when the system enters the main crash path; the log is saved again before the system is ready to switch to the backup kernel, overwriting the case where the main crash path saving failed or the log buffer continued to grow during the crash process; Extract the log content prior to the crash from the current kernel log buffer to determine the data source to be saved; Write the data to be saved into the crash log snapshot area according to the preset header format. After the write operation is complete, the data cache is flushed to ensure that the data is consistent when the backup kernel reads it from the same physical address.

[0011] Furthermore, the execution of secondary evidence preservation includes the following steps: Collect in-depth fault evidence information on processor exception context, memory error correction register status, reliability, availability and maintainability modules, and high-speed peripheral expansion units for each error state; The collected deep fault evidence is written to the crash handling path via the crash log writing mechanism. The crash log and register data are written to the black box partition through the crash state storage write function, and the integrity is verified.

[0012] Furthermore, step S4 includes the following steps: Initialize the processor takeover control area; Send interrupt instructions to all processors in the processor mask except the crashed core; after each non-master core saves the register context of the crashed processor, it enters a wait event instruction waiting loop and registers the current processor physical identity and register physical identity in its own takeover slot; After performing a log snapshot and saving the extended crash context, the crash state quick switch function is called to jump to the standby kernel; After the standby kernel starts, it obtains the physical identity of the target core processor, performs slot matching in the processor takeover control area, registers the processor status in the corresponding slot, writes the physical address of the kernel boot entry point to the matching slot and increments the sequence number, and wakes up the waiting core; during the standby kernel boot process, it keeps the addresses of the processor takeover control area, crash log snapshot area and security area fixed and prevents them from being misallocated. When the waiting non-master core detects that the magic number identifier is valid and the sequence number is non-zero, it reads the entry physical address and executes the processor software restart function to jump to the backup kernel slave kernel boot entry, and publishes the backup kernel slave kernel boot entry to the non-master core; in this process, the backup kernel will expand the waiting window to ensure the stability of the multi-core takeover timing.

[0013] Furthermore, step S6 includes the following steps: During the boot process of the standby kernel, fix the physical addresses of the processor takeover control area, crash log snapshot area, and security area in the device tree, and set the attribute to disable normal kernel mapping; Based on the defined fixed reserved area and the multi-core wait event state formed by S5, the restrictions on ordinary memory pruning are relaxed for crash recovery scenarios during the initialization of backup kernel memory. Based on the relaxed results, the crash recovery scenario is adapted in the initialization path of the secure execution environment; Based on the adaptation results, it is prohibited to misinterpret a secure shared area as ordinary allocatable memory.

[0014] Furthermore, S7 includes the following steps: Based on the completed memory and security region reconstruction results, after the standby kernel boot process, the entries required for interrupt control are placed into the reserved physical memory window; Based on the constraints of the backup kernel, the interrupt disabling, stable waiting and interrupt table initialization processes are reconstructed, and the crash log snapshot and black box persistent evidence saved by S2 are read to output fault analysis information, so that the system can enter a stable operating state after recovery. Once the system has completed interrupt recovery and entered a stable operating state, it reads the log snapshot saved before the crash through the crash log reading node exported by the system, and then ends the process.

[0015] The beneficial effects of this invention are: Compared to existing fast kernel switching mechanisms, the main difference lies in the fact that this invention does not only focus on "switching kernels after a crash," but also designs "log preservation, reserved area isolation, multi-core takeover, interrupt recovery, and safe zone protection" as a complete recovery chain, making it more suitable for high-uncertainty crash scenarios in aerospace environments. The main differences in key capabilities between existing fast kernel switching processes and the fast recovery mechanism proposed in this invention are described below: (1) Differences in log saving: The original fast kernel switching mechanism (kexec) mainly relies on continuing to print after a crash or on subsequent flash memory writing, resulting in late log saving and susceptibility to environmental anomalies after a crash. This invention, on the other hand, writes a kernel log snapshot to a fixed retention area before entering the standby kernel, and supplements it with black box logs for additional saving.

[0016] (2) Differences in multi-core recovery; The original fast kernel switching mechanism (kexec) process usually follows the conventional assumption of booting from the CPU, and crashes are prone to failure when the CPU is not in a zero-core state or the CPU state is abnormal. This invention improves the success rate of multi-core recovery of the backup kernel by fixing the processor takeover control area, matching the processor physical identity, cleaning up obsolete states and extending the wait window.

[0017] (3) Differences in interrupt recovery: In the existing process, the reallocation and initialization of critical interrupt tables still rely on ordinary memory and regular timing, which is prone to anomalies in crash recovery scenarios. This invention places critical interrupt tables in reserved windows and adopts strategies adapted to crash recovery scenarios for closing, rebuilding and recovering them.

[0018] (4) Differences in reserved area protection: The original process lacks a unified physical isolation design for the log area, security area, and processor takeover area. This invention avoids the backup kernel from accidentally overwriting critical areas through a cooperative layout of fixed physical addresses, explicit reservation, and prohibition of ordinary mapping.

[0019] In summary, this invention utilizes a backup kernel takeover method to enable the system to recover from a kernel crash state to a runnable state in a short time. It also has the ability to capture the crash scene with low overhead, save error logs as much as possible before the operating system crashes, and retain critical fault information in persistent storage devices. Furthermore, it can proactively isolate conflicting memory areas before recovery to improve the reliability of the system after recovery, increase the success rate of crash log preservation, improve the success rate and recovery speed of backup kernel startup, enhance the operational availability of the backup kernel (CrashKerne), improve the fault traceability capability in the aerospace environment, and reduce dependence on untrusted operating environments. This invention is suitable for the engineering deployment of aerospace missions. Attached Figure Description

[0020] Figure 1 This is a flowchart of the method of the present invention.

[0021] Figure 2 This is a system framework diagram of the present invention. Detailed Implementation

[0022] The specific embodiments of the present invention are described below to enable those skilled in the art to understand the present invention. However, it should be understood that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the present invention as defined and determined by the appended claims. All inventions utilizing the concept of the present invention are protected.

[0023] Before describing the present invention, the following terms and abbreviations will be explained. Table 1 is a term explanation table, and Table 2 is a abbreviation explanation table.

[0024] Table 1

[0025] Table 2

[0026] like Figure 1 As shown, this invention provides a fast recovery method for uncorrectable particle errors in a space environment, and its implementation method is as follows: S1. Establish a fixed retention area required for system crash recovery. The fixed retention area includes at least the processor takeover control area, the crash log snapshot area, and the security area. Record the fixed physical address, length, access attributes, and verification information of the processor takeover control area, the crash log snapshot area, and the security area. The processor takeover control area is used to take over control information through a multi-core processor before and after a system crash. The crash log snapshot area is used to write kernel log snapshots when the system crashes, and it uses the "disable ordinary kernel mapping" attribute to prevent ordinary memory allocators from occupying it. The security zone is used to protect the secure memory occupied by the Trusted Execution Environment (TEE) and prevent the backup kernel from being misused. S2. When an uncorrectable particle error is detected in a space environment and triggers a system crash, the system enters the crash handling path. In the crash handling path, a kernel log snapshot is first written to the crash log snapshot area established in S1. Then, the processor exception context, memory error correction status, and high-speed peripheral error status are written to the black box persistent partition, and the crash processor register context is saved. In the crash handling path, first-level evidence preservation is performed, writing the current kernel log snapshot to the crash log snapshot area and flushing the cache, including the following steps: When an uncorrectable particle error is detected in a space environment and triggers a system crash, a log snapshot is performed when the system enters the main crash path; a save is performed again before the system prepares to switch to the standby kernel (CrashKerne) to overwrite the case where the main crash path save failed or the log buffer continued to grow during the crash; the log content before the crash is extracted from the current kernel log buffer to determine the data source to be saved; the data to be saved is written to the crash log snapshot area with the kernel log content according to the preset header format; after writing is completed, the data cache is flushed to ensure that the data is consistent when the standby kernel reads it through the same physical address; The second-level evidence preservation process includes the following steps: collecting information such as the processor exception context, memory error correction register status, global status register, identification register, control register, error status register, and error address register of each error group in the reliability, availability, and maintainability modules and high-speed peripheral expansion units; writing the collected data to the crash handling path through the crash log writing mechanism; writing the crash log and register data to the black box partition through the crash state storage write function; and verifying the integrity. S3. Based on whether the backup kernel image has been preloaded, whether the backup kernel reserved parameters are valid, whether the backup kernel switching image is available, and whether the fixed reserved area is complete and without address conflicts, determine whether the conditions for backup kernel switching are met. If not all conditions are met, use the offline evidence of the black box persistent partition and combine it with the logs in the crash log snapshot area to generate a fault analysis report and end the process. If all conditions are met, proceed to S4. S4. Based on the processor takeover control area, a multi-core takeover mechanism is initiated. The physical identity of each processor is matched with the takeover slot. The processor status, boot entry address, and serial number are registered in the corresponding slot. A backup kernel boot entry is then issued to the non-master processor. The implementation method is as follows: Initialize the processor takeover control area; Send interrupt instructions to all processors in the processor mask except the crashed core; after each non-master core saves the register context of the crashed processor, it enters the Wait for Instruction Event (WFE) waiting loop and registers the current physical identity in its own takeover slot; After performing a log snapshot and saving the extended crash context, the crash state quick switch function is called to jump to the standby kernel; After the standby kernel starts, it obtains the physical identity of the target core processor, performs slot matching in the processor takeover control area, registers the processor status in the corresponding slot, writes the physical address of the kernel boot entry point to the matching slot and increments the sequence number, and wakes up the waiting core; during the standby kernel boot process, it keeps the addresses of the processor takeover control area, crash log snapshot area and security area fixed and prevents them from being misallocated. When the waiting non-master core detects that the magic number identifier is valid and the sequence number is non-zero, it reads the entry physical address and executes the processor software restart function to jump to the backup kernel slave kernel boot entry, and publishes the backup kernel slave kernel boot entry to the non-master core; among them, the backup kernel will expand the waiting window to ensure the stability of the multi-core takeover timing; S5, based on the takeover slot, processor status and serial number formed by S4, executes the crash state waiting strategy extension, so that the non-master processor continuously listens to the takeover control area in the waiting event state, and jumps to the backup kernel from the kernel boot entry after the boot entry address and serial number are valid. S6. Based on the defined fixed reserved area and the multi-core wait event state formed in S5, the memory and safe area required for recovery are protected and reconstructed during the backup kernel startup process to prevent the backup kernel from overwriting the crash log snapshot area, the processor takeover control area, and the safe memory occupied by the trusted execution environment; the implementation method is as follows: During the boot process of the standby kernel, fix the physical addresses of the processor takeover control area, crash log snapshot area, and security area in the device tree, and set the attribute to disable normal kernel mapping; Based on the defined fixed reserved area and the multi-core wait event state formed by S5, the restrictions on ordinary memory pruning are relaxed for crash recovery scenarios during the initialization of backup kernel memory. Based on the relaxed results, the crash recovery scenario is adapted in the initialization path of the secure execution environment; Based on the adaptation results, it is prohibited to misinterpret the secure shared area as ordinary allocatable memory; S7. Based on the memory and security region reconstruction results, after the backup kernel starts, critical interrupt resources are rebuilt, and the crash log snapshot and black box persistent evidence saved in S2 are read. Fault analysis information is output, enabling the system to enter a stable operating state after recovery, and the process ends. The implementation method is as follows: Based on the completed memory and security region reconstruction results, after the standby kernel boot process, the entries required for interrupt control are placed into the reserved physical memory window; Based on the constraints of the backup kernel, the interrupt disabling, stable waiting and interrupt table initialization processes are reconstructed, and the crash log snapshot and black box persistent evidence saved by S2 are read to output fault analysis information, so that the system can enter a stable operating state after recovery. Once the system has completed interrupt recovery and entered a stable operating state, it reads the log snapshot saved before the crash through the crash log reading node exported by the system, and then ends the process.

[0027] The following uses the D2000V chip platform as an example to illustrate the implementation of this invention.

[0028] like Figure 2As shown, starting from the main operating system, after anomaly detection and crash entry point decision-making, two parallel data paths are formed: "evidence preservation" and "backup kernel switchover," which ultimately converge at the business recovery unit. The functions and data flow of each unit are as follows: (1) Main operating system (Linux main kernel + multi-core CPU) Function: The normal operating platform of the system, carrying business processes, drivers, and interrupt services.

[0029] Data flow: Continuously outputs operating status to the upstream anomaly detection unit; provides crash triggering context to the downstream crash entry control unit.

[0030] (2) Anomaly detection unit (UE / ECC / RAS events) Function: Monitor uncorrectable errors (UE), error correction code anomalies (ECC), and reliability / availability / maintainability (RAS) events to determine if the system has entered an unrecoverable abnormal state.

[0031] Data flow: Abnormal event signals are sent to the crash entry control unit; at the same time, metadata such as fault type and fault address are provided for subsequent evidence preservation.

[0032] (3) Crash entry control unit (crash handling process / backup kernel decision) Function: Upon detecting an uncorrectable particle error in a space environment, trigger the crash handling process and determine whether to enter the backup kernel switching path based on the backup kernel image, reserved parameters, and the integrity of the fixed reserved area.

[0033] Data flow: As a three-way distribution hub: a) issue log snapshot instructions to the first-level evidence preservation unit; b) issue deep forensics instructions to the second-level evidence preservation unit; c) issue switching instructions to the backup kernel switching unit when the switching conditions are met.

[0034] (4) Level 1 Evidence Preservation Unit Functionality: Writes kernel log snapshots to fixed-retention memory with minimal dependencies in the main crash path, achieving millisecond-level preservation of volatile evidence.

[0035] Corresponding partition: Log storage address is 8320000 (device tree node dmesg_log@83200000), size is 2MiB, physically isolated from the spare kernel and processor takeover area.

[0036] Data flow: Receive instructions from the crash entry control unit → extract data from the kernel log buffer → write to the crash log snapshot area according to the preset header format → refresh the data cache → make it available for the log export unit to read.

[0037] (5) Crash log snapshot area Function: A fixed physical storage window that carries Level 1 evidence, using the "Disable ordinary kernel mapping" attribute to prevent ordinary memory allocators from occupying it.

[0038] Data flow: Receives crash log snapshot data written by the Level 1 Evidence Preservation Unit; provides a read-only data source to the Log Export Unit.

[0039] (6) Secondary evidence preservation unit (persistent storage of black box) Function: Writes deep fault evidence, such as processor exception context, memory error correction register status, reliability, availability and maintainability modules, and the status and address of each error group in the high-speed peripheral expansion unit, into a persistent black box partition to achieve traceability after power failure.

[0040] Corresponding partition: Memory Technology Device partition in flash memory (gp1_2M), bound through the memory technology device crash log writing mechanism, dedicated to the persistence of crash logs and register information.

[0041] Data flow: Receives instructions from the crash entry control unit → calls the extended context acquisition interface → writes to the black box persistent partition via the crash state optimized write channel → is read by the fault tracing and analysis unit.

[0042] (7) Black box persistent partitioning Function: Non-volatile storage medium that can retain the fault scene after system crash or power failure.

[0043] Data flow: Receives log and register data written by the secondary evidence preservation unit; provides offline analysis data source to the fault tracing and analysis unit.

[0044] (8) Backup kernel switching unit (fast kernel switching mechanism switching) Function: In the current kernel crash state, load the backup kernel image into the reserved backup kernel memory area and perform a jump, skipping the firmware-level cold boot.

[0045] Data flow: Receive crash entry control unit switching instruction → save crash CPU register context → execute fast kernel switching mechanism jump → trigger multi-core takeover control unit.

[0046] (9) Multi-core takeover control unit (processor physical identity slot matching / entry release) Function: Maintain the processor takeover control block at a fixed physical address, complete slot matching with the processor's physical identity, and issue a backup kernel boot entry point to non-main cores.

[0047] Corresponding partition: Address 83000000 (device tree node crash_cpu_handover@83000000), size 64KiB.

[0048] Data flow: Receive standby kernel switching unit trigger → clean and initialize takeover control block → non-master core enters wait-to-takeover state and registers processor physical identity identifier (MPIDR) → standby kernel matches slot according to processor physical identity identifier (MPIDR) and publishes entry address → drives non-master core start-up unit.

[0049] (10) Memory reconstruction and isolation unit (crash area / log area / trusted execution environment area protection) Function: During the boot process of the standby kernel, keep the addresses of the processor takeover control area, crash log snapshot area, and open source trusted execution environment in the safe area fixed and prevent them from being misallocated, thus preventing secondary overwriting.

[0050] Corresponding partitions: spare kernel reserved area, log storage area, secure memory area of ​​secure execution environment with address fc000000, and shared memory area of ​​secure execution environment with address fe200000.

[0051] Data flow: After receiving the switchover completion signal from the multi-core takeover control unit, the reserved area address verification, the spare kernel memory policy relaxation, the explicit reservation of the security area and the prohibition of normal mapping are completed in sequence, and the processing results are provided to the critical interrupt recovery unit and the log export unit.

[0052] (11) Critical interrupt recovery unit (interruption translation service / message signal interruption reserved window reconstruction) Function: Allocate the third-generation general interrupt controller, interrupt translation service / local peripheral interrupt related entries from the reserved physical memory window, reconstruct the interrupt disable, stable wait and message signal interrupt (MSI) recovery process, so that the standby kernel can generate message signal interrupt normally after recovery.

[0053] Corresponding partition: Local Specific Peripheral Interrupt (LPI) physical address window (e.g., 0x217f000000–0x2180000000), which is reserved during the startup phase through the early memory reservation function.

[0054] Data flow: After memory reconstruction and isolation are completed, the process proceeds as follows: → Interrupt Translation Service (ITS) entries are allocated within the reserved window → Local specific peripheral interrupt / message signal interrupt paths are rebuilt → Interrupt service capabilities are provided for the business recovery unit.

[0055] (12) Non-core start-up unit (waiting to be taken over and come online) Function: Drives a non-master processor that has stopped in a crash state to enter a waiting takeover loop. After receiving the entry address, it jumps to the backup kernel entry point and completes the online state.

[0056] Data flow: The multi-core takeover control unit obtains an entry point and publishes the data → each non-master core waits for and consumes the takeover command → the processor software restart function is executed and jumps to the business recovery and operation unit.

[0057] (13) Log export unit (process virtual file system snapshot reading interface) Function: After the standby kernel boots, the log snapshots stored in memory will be exported through the process virtual file system node for user space to read.

[0058] Data flow: Mapping and parsing the header from the crash log snapshot area → Outputting to the outside through the crash log export node → Simultaneously providing first-level evidence to the fault tracing and analysis unit.

[0059] (14) Fault tracing and analysis unit Function: Links the primary memory snapshot with the secondary black box persistent partition to achieve fault recovery with "quick overview + in-depth forensics".

[0060] Data flow: Obtain volatile snapshots from the log export unit → Obtain register-level in-depth evidence from the black box persistent partition → Output a complete fault analysis report.

[0061] (15) Business recovery and operation unit Function: The final running state after the system completes memory protection, interrupt recovery, multi-core restart and log preservation, business processes can be rebuilt in this environment.

[0062] Data flow: The data converges the outputs of the memory reconstruction and isolation unit, the critical interrupt recovery unit, the non-main core restart unit, and the log export unit, and enters the business operation state after recovery.

[0063] In this embodiment, the present invention mainly includes the following: Content (1) Establish a dedicated memory layout for crash recovery, and reserve and fix the area in the device tree.

[0064] Content (2) Construct a log preservation mechanism that prioritizes memory snapshots when the system crashes, and inject log snapshot actions into the main crash path and the path before the backup kernel takes over.

[0065] Content (3) Preserve persistent black box log channels and enhance write reliability in crash conditions.

[0066] Content (4) Establish a multi-core recovery takeover mechanism based on processor physical identity.

[0067] Content (5) Extended CPU stop and wait strategies in crash scenarios.

[0068] Content (6) Fix the availability of critical interrupt subsystems in the standby kernel.

[0069] Content (7) Optimize backup kernel memory strategy, security zone isolation and log reading after recovery.

[0070] Content (8) Log reading and fault review after recovery.

[0071] In content (1), establish the fixed retention area required for system crash recovery. The fixed area is as follows: The processor takeover control area is used to take over control information through a multi-core processor before and after a system crash.

[0072] Crash log snapshot area, used to quickly write kernel log snapshots when the system crashes.

[0073] The security zone is used to protect the secure memory occupied by the Trusted Execution Environment (TEE) and prevent misuse of the backup kernel.

[0074] The fixed reserved area uses a fixed physical address to avoid complex allocation under the crash path; it is clearly stated that each area does not overlap to avoid conflicts between the backup kernel and the log area. Through the above design, the processor takeover control area, crash log area and safe area are physically isolated during the system startup phase, which achieves the effects of avoiding dynamic allocation failure after a crash, avoiding the overlapping of critical areas, and improving the determinism of the recovery path.

[0075] In content (2), based on the fixed retention area established in content (1), a fast log snapshot saving method is implemented in the kernel crash handling process state, so that the system can save the key kernel message log information to a dedicated memory area before entering the standby kernel.

[0076] A "memory snapshot-first" log preservation mechanism is implemented to prevent system crashes. Log snapshot actions are injected into the main crash path and the path before the backup kernel takes over, including: Method (1) When there are uncorrectable particle errors in the space environment, a crash log snapshot is saved when the system enters the main crash path; Method (2) performs a save again as a fallback before the system is ready to switch to the standby kernel; Method (3) extracts the log content prior to the crash from the current kernel log buffer; Method (4) Write the crash log snapshot area according to the preset header format; Method (5) refreshes the cache after writing to ensure that the backup kernel can read correctly.

[0077] Using the above methods, even if the persistent storage write path is limited, logs can still be quickly preserved in memory.

[0078] The above methods (1) to (5) are a combination structure of "dual timing trigger + single-time save pipeline".

[0079] Method (1) and Method (2) are trigger timing layers. Method (1) immediately performs a log snapshot when the system enters the main crash path, which is the first priority and the main path is saved; Method (2) performs a save again before the system is ready to switch to the standby kernel, which is a fallback save and covers the situation where the main path save fails or the log buffer continues to grow during the crash. The two are two independent triggers of the same save pipeline and are logically complementary.

[0080] Methods (3) to (5) form a single-save execution chain. Each time a save is triggered, the execution proceeds in the following order: Method (3) extracts the log content before the crash from the current kernel log buffer (logbuf) to determine the data source to be saved; Method (4) Write the log content to the crash log snapshot area according to the preset header format (magic number DMES, version number, effective length); Method (5): After the data is loaded, the data cache is refreshed to ensure that the data is consistent when the backup kernel reads the data through the same physical address.

[0081] The three constitute a progressive chain of “data retrieval → disk (memory) → consistency guarantee”. The overall logic from method (1) to method (5) can be expressed as: {method (1) or method (2)} → {method (3) → method (4) → method (5)}, that is, the timing condition determines when to save, and then a complete snapshot is completed each time according to a fixed pipeline.

[0082] In this embodiment, for content (3) – retaining the persistent black box log channel and enhancing write reliability in a crash state, while saving the log during the kernel crash handling process, extended saving of the crash critical context is performed. The context includes CPU exception context, fault address related information, error correction code register information, reliability / availability / maintainability register information; high-speed serial computer extended bus standard (PCIe) and direct memory access (DMA) register information. The context is written to the persistent storage partition through the extended black box log mechanism to supplement the snapshot in the retained memory, thereby achieving a two-layer evidence preservation of "fast saving + deep forensics".

[0083] This step comprises two related but distinct sub-goals: preserving the persistent black-box log channel and enhancing crash-state write reliability; and performing extended save of crash-critical contexts. Their logical relationship is as follows: "Channel reliability" is the infrastructure of "extended storage"—extended context storage relies on the black box persistence channel to write the acquired register data to disk; if the channel is unreliable in a crash state, the content of extended storage cannot be fully persisted. Conversely, extended storage is the specific content of the channel service—the channel is designed to carry richer in-depth forensic data than the first-level snapshot. The two constitute a synergistic relationship of "channel-assured transmission + content-filled forensics," jointly achieving a two-layer evidence preservation of "fast storage + in-depth forensics."

[0084] When the system has the conditions for switching to a backup kernel, the kernel log is preferentially written to reserved memory (to avoid the time-consuming write to flash memory during a crash that would block the switch); register-level deep evidence can still be written to storage devices through the black box channel or printed in the serial port path for retrieval on the ground. When the conditions for switching are not met, the black box channel assumes all responsibility for evidence preservation.

[0085] The persistent black-box log channel is preserved and write reliability is enhanced in crash conditions, as follows: Triggered Acquisition: In the kernel crash handling path, the exception display routine calls the ARM64 exception context printing function to collect the CPU exception context, including ESR_EL1 (exception synthesis register), FAR_EL1 (fault address register), MPIDR_EL1 (processor physical identity), ELR_EL1 / SPSR_EL1 (exception return status), and memory management related registers (TTBR / TCR / MAIR / SCTLR, etc.); at the same time, the (memory) DDR register information printing function is called to collect the memory controller error correction code related registers.

[0086] Register classification acquisition: Read and format by category through a dedicated acquisition interface: a) Error correction code register: Reads the address and data register of uncorrectable / correctable errors via the indirect access path of the memory controller; b) Reliability / Availability / Maintainability Registers: Read the GSR (Global Status Register), IDR (Identifier Register), CTLR (Control Register), STATUS (Status Register), ADDR (Address Register), and other registers for each error group in the fault reliability, availability, and maintainability module / high-speed peripheral expansion unit; c) High-speed serial computer expansion bus standard (PCIe) registers: Read PCIe controller configuration, interrupt / error status and direct memory access channel registers.

[0087] Data organization: The collected results are organized into the write buffer in the order of "64KB kernel log + error correction code segment + reliability / availability / maintainability segment + high-speed serial computer extended bus standard (PCIe) segment". The offset of each segment is aligned to 4 bytes to meet the write constraints of the underlying storage device.

[0088] Reliable crash state write: The crash write path is executed through the memory technology device crash log write mechanism: a) Select the memory technology device crash state write function interface (which can break locks, allows delays to ensure successful write, and cannot sleep); b) Execute Flash chip selection switching via the Flash switching function, switch to the target Flash chip before writing, and restore the original chip selection after writing; c) Write in segments and verify the return length of each segment. If any segment is not completely written, an error is returned to avoid marking used pages incorrectly, which would cause subsequent readbacks to be empty; d) Write the black box log partition in 64KB pages in a loop, and support ground tools to parse page by page after power failure.

[0089] In conjunction with the first-level snapshot: If the backup kernel path is already active, the kernel log will no longer be repeatedly written to Flash (the memory snapshot will take over), and the black box channel will focus on the persistence of register-level deep evidence, avoiding Flash writes from blocking kernel switching timing.

[0090] In this embodiment, a multi-core recovery takeover mechanism based on processor physical identity is established. Before the system enters the backup kernel, the multi-core takeover mechanism completes the multi-core switching preparation before and after the crash. A processor takeover control block is maintained at a fixed physical address; each non-master processor in the original running system enters a waiting-to-takeover state after receiving a stop instruction; the control block records the processor's physical identity identifier, execution sequence number, and restart entry address; after the backup kernel starts, it accurately matches the corresponding control slot based on the processor's physical identity identifier; a new boot entry is published to the corresponding slot, causing the target processor to jump to the backup kernel's slave processor entry. This step avoids the CPU boot failure problem caused by simply relying on logical CPU number mapping. This step constitutes a progressive chain of "in place → matching → publishing". The complete switchover preparation process is as follows: Preparation Phase P1 - Takeover Area Initialization: In the crash state multi-core stop notification function, the magic number flag of the processor takeover control block (located at 0x83000000) is cleared, and the physical identity flag, serial number, and entry physical address of the processor in each slot are cleared, eliminating the residual state of the previous crash.

[0091] Preparation Phase P2—Non-Master Core Stop and Wait: Sends an interrupt to all processors in the possible processor mask except for the crashed core; after saving the register context, each non-master core calls the crash state takeover wait jump function to enter the wait instruction event (WFE) wait loop and registers the current physical identity in its own slot.

[0092] Preparation Phase P3—Crash Kernel Evidence Preservation and Switching: After the crash kernel execution log snapshot and extended saving are completed, the crash state fast switch function is called to jump to the standby kernel.

[0093] Preparation Phase P4—Backup Kernel Slot Matching and Entry Release: After the backup kernel starts up, when each slave core is pulled up, it obtains the physical identity of the target core processor's physical identity register, accurately matches the slot in the takeover control block, writes the slave core's boot entry physical address to the matched slot and increments the sequence number, and wakes up the waiting core by sending an event command.

[0094] Preparation Phase P5—Core Jump and Online Status: After the waiting non-master core detects that the magic number identifier is valid and the serial number is non-zero, it reads the entry physical address and executes the processor software restart function to jump to the backup kernel slave core entry; the backup kernel extends the waiting window to 5 seconds (originally 1 second) to ensure the stability of the multi-core takeover timing.

[0095] In this embodiment, the non-master core entering the waiting takeover state is a prerequisite—only when the non-master core stops and enters the waiting loop can subsequent matching and deployment have an execution object; Matching the target slot based on the processor's physical identity is the location method—finding the control slot that corresponds one-to-one with the physical processor in the takeover control block; The process of releasing the kernel boot entry point is to execute—write the backup kernel entry point address to the located slot and trigger a wake-up.

[0096] In this embodiment, there are two methods for saving crash logs: 1) A fast snapshot method in memory, used for first-priority log preservation in system crash states. This method directly performs log snapshot actions in the crash path, writing the logs to a fixed crash log snapshot area, avoiding the use of complex locks, scheduling, and long waits. It is suitable for scenarios that require immediate switching to a standby kernel. 2) An extended black box persistent preservation method. This method is used to supplement the preservation of deep fault evidence. It writes the logs and key register information to a persistent partition and uses a low-level writing method optimized for crash states to ensure writability even in abnormal states. It is suitable for long-term preservation after a crash, tracing after power failure, and ground analysis. Through the synergy of 1) and 2), a dual-channel log preservation mechanism of "fast first, then comprehensive" is achieved.

[0097] In this embodiment, during the backup kernel boot process, the memory and security regions required for recovery are protected and reconstructed. The specific implementation method is as follows: The addresses of the processor takeover control area, crash log area, and secure area are kept fixed and cannot be occupied by ordinary allocation paths; during the initialization of the backup kernel memory, the restrictions on ordinary memory pruning are relaxed for crash recovery scenarios to avoid excessive compression of available backup kernel memory; the initialization path for the secure execution environment is adapted to crash recovery scenarios to reduce reliance on normal system integrity detection conditions; and the backup kernel is prevented from mistakenly resolving the secure shared area as ordinary allocatable memory. These four protection measures together form a protection chain between the backup kernel memory and the secure area. Maintaining fixed addresses for the processor takeover control area, crash log area, and security area, and preventing them from being occupied by ordinary allocation paths, is the basic constraint layer. This involves fixing the physical addresses of the processor takeover control area, crash log snapshot area, and trusted execution environment security area in the reserved memory nodes of the device tree, and setting the attribute to prohibit ordinary kernel mapping. This provides address boundaries for all subsequent protection measures and is a prerequisite for subsequent protection measures.

[0098] During standby kernel memory initialization, the normal memory pruning restrictions for crash recovery scenarios are relaxed to a resource guarantee layer: when the standby kernel determination function determines it to be a standby kernel, the pruning of available memory by memory limit parameters is skipped, and the reduction of the memory range by the device tree memory range is canceled, ensuring that the standby kernel obtains sufficient memory to complete recovery. This relies on the clearly defined reserved area boundaries of the basic constraint layer to avoid covering critical areas when relaxing the pruning.

[0099] In the secure execution environment initialization path, a compatibility adaptation layer is implemented to accommodate crash recovery scenarios. Under the backup kernel, the trusted execution environment detection process is adapted—skipping strict interface sequence number verification (because the secure world state may be incomplete after a crash), ensuring the backup kernel's initialization is not interrupted due to trusted execution environment detection failure. This relies on the basic constraint layer's reserved protection for the trusted execution environment area and sufficient memory space provided by the resource guarantee layer.

[0100] Preventing the misrepresentation of secure shared areas as ordinary allocatable memory is an isolated enclosed layer: This involves explicitly reserving secure memory areas and shared memory areas within the secure execution environment (SEEnvironment) through the device tree, and ensuring that these areas are not occupied by buddy system allocators or early memory management module merging operations during memory initialization. This is a specific execution guarantee of the basic constraint layer, relying on the address planning and initialization strategy formed by the first three items.

[0101] Overall progressive logic: Fixed address planning → Guarantee available memory → Adapt to a secure environment → Close and isolate a secure zone.

[0102] In this embodiment, after the backup kernel starts, critical interrupt recovery and crash log reading are completed. The specific implementation method is as follows: the entries required for critical interrupt control are placed in the reserved physical memory window; based on the special constraints under the backup kernel, the interrupt disabling, stable waiting, and interrupt table initialization processes are reconstructed; the log snapshot saved before the crash is read through the crash log reading node exported by the system; and detailed fault information is read in conjunction with the persistent black box partition to achieve fault linkage analysis.

[0103] The crash log reading is implemented as follows: display the crash log reading file exported by the system; print the log snapshot content saved in memory; use the file export capability provided by the kernel; and call the read capability after retaining the memory mapping.

[0104] The implementation method for crash log reading nodes is as follows: Locate the preset crash log reservation area node in the device description information; map out the corresponding reserved memory; parse and load according to the custom header format; export for reading through the process virtual file system node during system runtime.

[0105] In this embodiment, this step links the three capabilities of the backup kernel recovery process into a logical chain of "first stabilize the environment, then restore capabilities, and finally export evidence": (i) Optimizing the standby kernel memory strategy (a continuation of relaxing the restrictions on ordinary memory pruning for crash recovery scenarios during standby kernel memory initialization): After the reserved area is fixed and the safe area is isolated, the standby kernel obtains a definite memory layout. At this time, it is necessary to ensure that the standby kernel area, log snapshot area, and trusted execution environment area are not dynamically allocated or destroyed, so as to provide a stable physical address space for subsequent interrupt initialization and log mapping. This is a prerequisite for memory access for log reading.

[0106] (ii) Security Zone Isolation (maintaining fixed addresses for the processor takeover control area, crash log area, and security zone, and preventing the standby kernel from mistakenly resolving the security shared area as ordinary allocatable memory): Security zone isolation ensures that the standby kernel will not overwrite the Trusted Execution Environment (OP-TEE) security world memory during recovery, avoiding triggering secondary security exceptions. After isolation is completed, the system is in a state where interrupt reconstruction and process virtual file system node registration can be safely performed, which is a prerequisite for system stability in log reading.

[0107] (III) Critical Interrupt Recovery: After memory and the safe zone are ready, interrupt translation service table entries are allocated from the reserved local peripheral interrupt physical window, and the local peripheral interrupt configuration table and message signal interrupt path of the third-generation general interrupt controller are reconstructed. Interrupt recovery enables the standby kernel to have normal peripheral response capabilities (including network, storage, etc.), and the system enters the runnable state. This is a prerequisite for the availability of log reading functionality—the normal operation of the process virtual file system and interrupt driver both depend on the recovery of the interrupt subsystem.

[0108] (iv) Log reading after recovery: After the system completes interrupt recovery and enters a stable operating state, the memory crash log module executes the following during the kernel's late initialization call phase: Locate the Phytium crash log device tree node → Memory-mapped crash log snapshot area → Verify the magic number and version → Create a crash log export node to export the log content. User space can read the first-level snapshot by viewing the crash log export node, and simultaneously obtain second-level in-depth evidence by reading the black box log partition through memory technology device tools, thus achieving fault linkage analysis.

[0109] Logical relationship summary: memory strategy and security zone isolation (environment preparation) → critical interrupt recovery (capability recovery) → log reading (evidence export). Log reading uses the first-level log snapshot written by S2, and fault review uses the second-level black box evidence written by S2. The three are progressively dependent and cannot be skipped.

[0110] Next, taking "automatically switching to the backup kernel and restoring the business environment after the system crash is triggered by an uncorrectable particle error" as an example, the workflow of the fast recovery mechanism proposed in this invention will be explained.

[0111]

Start and Trigger Step S1

[0112]

Step S2

[0113] [Extension of Step S2] Perform Level 2 Evidence Preservation: Collect register information such as global status, identification, control, error status, and error address of each error group in the processor exception context, memory error correction register status, reliability, availability, maintainability module, and high-speed peripheral expansion unit, and write it to the black box log partition; if the backup kernel path is subsequently entered, this partition will serve as evidence for in-depth analysis after recovery; if the backup kernel path cannot be entered, this partition will serve as evidence for offline tracing.

[0114]

Judgment Step S3

[0115]

Step S4

[0116]

Step S5

[0117]

Step S6

[0118]

Step S7

[0119] [End] After the system completes critical interruption recovery, log export, and fault evidence association, it enters the restored business operation state.

[0120] In summary, the present invention includes at least the following steps: fixed reserved area construction, rapid saving of kernel crash handling process logs, extended recording of crash context, multi-core takeover recovery based on processor physical identity, protection of backup kernel memory and safe zone, critical interrupt recovery, and reading of logs after crash.

[0121] Critical interrupt recovery is a process performed after backup kernel memory and secure zone protection are completed. Its purpose is to enable the system to have normal interrupt response capabilities after crash recovery, especially message interrupts from PCIe devices.

[0122] The crash log reading process is performed after the system recovers from the interruption and enters a stable operating state. Its purpose is to export the two levels of evidence saved before the crash for fault analysis.

[0123] In this embodiment, before entering the standby kernel, the kernel log snapshot is preferentially written to a reserved memory area with a fixed physical address, and the standby kernel can be directly read after startup by pre-setting header organization and cache refresh, thus forming a fast log preservation scheme that is different from one that only relies on persistent writing.

[0124] In this embodiment, a processor takeover control area is established at a fixed physical address. The control slot is matched using the processor's physical identity. The restart entry point from the processor is published by combining the execution sequence number and the boot entry address, thereby realizing multi-core takeover boot from the original running system to the backup kernel.

[0125] In this embodiment, fixed addresses are reserved for the processor takeover area, log snapshot area, and secure execution environment reserved area. Explicit reservation and prohibition of normal mapping are used to prevent the backup kernel from accidentally overwriting or misallocating critical areas.

[0126] In this embodiment, critical interrupt-related entries are allocated from the reserved physical window, and the interrupt disabling, stable waiting, interrupt table enabling, and message interrupt recovery processes are reconstructed under the standby kernel, reducing the dependence on ordinary memory allocators and conventional boot environments.

[0127] In this embodiment, the memory snapshot is used as the first priority fast storage channel, the black box persistent log is used as the second priority deep storage channel, and the error correction status, reliability status and high-speed peripheral register information are combined to achieve complete preservation of crash evidence.

[0128] In this embodiment, the system-exported crash log reading node maps, parses, and exports the log snapshots retained in memory to support rapid log viewing and fault analysis after system recovery.

Claims

1. A fast recovery method for uncorrectable particle errors in a space environment, characterized in that, Includes the following steps: S1. Establish a fixed retention area required for system crash recovery. The fixed retention area includes at least the processor takeover control area, the crash log snapshot area, and the security area. Record the fixed physical address, length, access attributes, and verification information of the processor takeover control area, the crash log snapshot area, and the security area. S2. When an uncorrectable particle error is detected in a space environment and triggers a system crash, the system enters the crash handling path. In the crash handling path, first-level evidence preservation is performed, writing the current kernel log snapshot to the crash log snapshot area and refreshing the cache. Then, second-level evidence preservation is performed, collecting the processor exception context, memory error correction status, and high-speed peripheral error status, and writing them to the black box persistent partition. At the same time, the register context of the crashed processor is saved. S3. Based on whether the backup kernel image has been preloaded, whether the backup kernel reserved parameters are valid, whether the backup kernel switching image is available, and whether the fixed reserved area is complete and without address conflicts, determine whether the conditions for backup kernel switching are met. If not all conditions are met, use the offline evidence of the black box persistent partition and combine it with the logs in the crash log snapshot area to generate a fault analysis report and end the process. If all conditions are met, proceed to S4. S4. Based on the processor takeover control area, start the multi-core takeover mechanism, match the physical identity of each processor with the takeover slot, register the processor status, boot entry address and serial number in the corresponding slot, and publish the backup kernel boot entry to the non-master processor. S5, based on the takeover slot, processor status and serial number formed by S4, executes the crash state waiting strategy extension, so that the non-master processor continuously listens to the takeover control area in the waiting event state, and jumps to the backup kernel from the kernel boot entry after the boot entry address and serial number are valid. S6. Based on the defined fixed reserved area and the multi-core wait event state formed by S5, the memory and safe area required for recovery are protected and reconstructed during the backup kernel startup process to prevent the backup kernel from overwriting the crash log snapshot area, the processor takeover control area and the safe memory occupied by the trusted execution environment. S7. Based on the memory and security region reconstruction results, rebuild critical interrupt resources after the backup kernel starts, and read the crash log snapshot and black box persistent evidence saved by S2, output fault analysis information, enable the system to enter a stable operating state after recovery, and end the process.

2. The fast recovery method for uncorrectable particle errors in a space environment according to claim 1, characterized in that, The fixed reserved area uses a fixed physical address, including: The processor takeover control area is used to take over control information through a multi-core processor before and after a system crash. The crash log snapshot area is used to write kernel log snapshots when the system crashes, and it uses the "disable ordinary kernel mapping" attribute to prevent ordinary memory allocators from occupying it. The security zone is used to protect the secure memory occupied by the Trusted Execution Environment (TEE) and prevent misuse of the backup kernel.

3. The fast recovery method for uncorrectable particle errors in a space environment according to claim 1, characterized in that, The step of first performing level-one evidence preservation in the crash handling path, writing the current kernel log snapshot to the crash log snapshot area and refreshing the cache, includes the following steps: When an uncorrectable particle error is detected in a space environment and triggers a system crash, a log snapshot is performed when the system enters the main crash path; the log is saved again before the system is ready to switch to the backup kernel, overwriting the case where the main crash path saving failed or the log buffer continued to grow during the crash process; Extract the log content prior to the crash from the current kernel log buffer to determine the data source to be saved; Write the data to be saved into the crash log snapshot area according to the preset header format. After the write operation is complete, the data cache is flushed to ensure that the data is consistent when the backup kernel reads it from the same physical address.

4. The fast recovery method for uncorrectable particle errors in a space environment according to claim 1, characterized in that, The execution of the second-level evidence preservation includes the following steps: Collect in-depth fault evidence information on processor exception context, memory error correction register status, reliability, availability and maintainability modules, and high-speed peripheral expansion units for each error state; The collected data is written to the crash handling path via the crash log writing mechanism. The crash log and register data are written to the black box partition through the crash state storage write function, and the integrity is verified.

5. The fast recovery method for uncorrectable particle errors in a space environment according to claim 1, characterized in that, S4 includes the following steps: Initialize the processor takeover control area; Send interrupt instructions to all processors in the processor mask except the crashed core; after each non-master core saves the register context of the crashed processor, it enters a wait event instruction waiting loop and registers the current processor physical identity and register physical identity in its own takeover slot; After performing a log snapshot and saving the extended crash context, the crash state quick switch function is called to jump to the standby kernel; After the standby kernel starts, it obtains the physical identity of the target core processor, performs slot matching in the processor takeover control area, registers the processor status in the corresponding slot, writes the physical address of the kernel boot entry point to the matching slot and increments the sequence number, and wakes up the waiting core; during the standby kernel boot process, it keeps the addresses of the processor takeover control area, crash log snapshot area and security area fixed and prevents them from being misallocated. When the waiting non-master core detects that the magic number identifier is valid and the sequence number is non-zero, it reads the entry physical address and executes the processor software restart function to jump to the backup kernel slave kernel boot entry, and publishes the backup kernel slave kernel boot entry to the non-master core; in this process, the backup kernel will expand the waiting window to ensure the stability of the multi-core takeover timing.

6. The fast recovery method for uncorrectable particle errors in a space environment according to claim 1, characterized in that, S6 includes the following steps: During the boot process of the standby kernel, fix the physical addresses of the processor takeover control area, crash log snapshot area, and security area in the device tree, and set the attribute to disable normal kernel mapping; Based on the defined fixed reserved area and the multi-core wait event state formed by S5, the restrictions on ordinary memory pruning are relaxed for crash recovery scenarios during the initialization of backup kernel memory. Based on the relaxed results, the crash recovery scenario is adapted in the initialization path of the secure execution environment; Based on the adaptation results, it is prohibited to misinterpret a secure shared area as ordinary allocatable memory.

7. The fast recovery method for uncorrectable particle errors in a space environment according to claim 1, characterized in that, S7 includes the following steps: Based on the completed memory and security region reconstruction results, after the standby kernel boot process, the entries required for interrupt control are placed into the reserved physical memory window; Based on the constraints of the backup kernel, the interrupt disabling, stable waiting and interrupt table initialization processes are reconstructed, and the crash log snapshot and black box persistent evidence saved by S2 are read to output fault analysis information, so that the system can enter a stable operating state after recovery. Once the system has completed interrupt recovery and entered a stable operating state, it reads the log snapshot saved before the crash through the crash log reading node exported by the system, and then ends the process.

Images