Crash dump method, system, electronic device, medium and product of embedded system

Abstract

The application discloses a crash dump method and system of an embedded system, an electronic device, a medium and a product. The method comprises the following steps: when a first kernel crashes and the first kernel is a real-time preemption kernel, executing a localized crash shutdown process; after the execution of the localized crash shutdown process is completed, switching the control right of a current CPU to a second kernel; after the second kernel is started, executing a safe initialization process of inheriting the interrupt state of a peripheral device in the first kernel on a target peripheral device; wherein the target peripheral device is a hardware device that needs to be initialized by the second kernel for saving a crash memory image; and after the execution of the safe initialization process is completed, storing a crash memory virtual file in a proc file system into a storage partition. The method can effectively avoid the first kernel from crashing and jumping to be deadlocked and the second kernel from crashing again due to a left interrupt, thereby significantly improving the success rate of saving the crash memory image.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a crash dump method, system, electronic device, readable storage medium, and computer program product for an embedded system. Background Technology

[0002] Embedded systems are widely deployed in mission-critical scenarios such as industrial control, autonomous driving, robotics, and medical devices. To meet high real-time requirements, real-time preemptive kernels are increasingly being adopted to reduce task scheduling and interrupt response latency. Existing crash dumping methods typically perform a shutdown operation on the first kernel of the embedded system when it crashes, and then switch to the second kernel for memory saving. However, in practice, it has been found that while a stop signal is sent to all other CPUs and global interrupts are masked during the shutdown operation to ensure hardware consistency before the jump, in high real-time embedded scenarios, other CPUs may be executing time-sensitive interrupt tasks. This can cause the shutdown process of the first kernel to be blocked for a long time while waiting for responses from these CPUs, preventing the first kernel from switching to the second kernel and ultimately failing to complete the crash dump. Summary of the Invention

[0003] In view of the above problems, this application provides a crash dumping method, system, electronic device, readable storage medium and computer program product for embedded systems, which can solve the problem that after the first kernel crashes, it is unable to jump to the second kernel to complete the crash dump because it is waiting for other CPUs to respond.

[0004] Firstly, this application provides a crash dumping method for an embedded system, comprising: When the first kernel crashes and is a real-time preemptive kernel, a localized crash shutdown procedure is executed. After the localized crash shutdown process is completed, control of the current CPU is switched to the second kernel; After the second kernel starts, a security initialization process that inherits the peripheral interrupt state in the first kernel is executed on the target peripheral; wherein, the target peripheral is a hardware device that the second kernel needs to initialize in order to save the crash memory image; After the security initialization process is completed, the crash memory virtual file in the proc file system is stored to the storage partition.

[0005] In the above technical solution, this method can effectively avoid the real-time preemptive kernel from getting stuck during the crash shutdown phase due to waiting for other CPUs or real-time locks, thereby significantly improving the success rate of crash jump; at the same time, by performing interrupt state security initialization inherited from the first kernel on the target peripheral after the second kernel starts, the risk of secondary crash caused by residual interrupts is eliminated, ensuring that the crash memory virtual file can be stably and completely saved to the storage partition, providing a reliable data foundation for subsequent fault location.

[0006] In some embodiments, the method further includes: When the first kernel boots normally, memory is reserved for crash dumps based on the boot parameters; When the enable flag of the reserved crash dump memory is detected, the current hardware description of the first kernel runtime is obtained; The second kernel preload command is invoked to load the current second kernel image file, the current captured initramfs, and the current hardware description into the crash dump memory; The current second kernel image file is used to run as the second kernel after the first kernel crashes; The currently captured initramfs encapsulates a crash image generation tool and a crash saving tool; the crash saving tool is invoked after the second kernel starts up, and the crash image generation tool and the crash saving tool are not configured in the normal operating environment of the first kernel; The current hardware description is used to ensure that the second kernel maintains the same hardware configuration as the first kernel at startup.

[0007] In the above technical solution, this method can pre-complete the memory reservation for crash dump, the loading of the second kernel image and hardware description during the normal operation of the system, avoiding the failure of dump due to the unavailability of storage devices or the time-consuming dynamic loading when a crash occurs; at the same time, by obtaining the current hardware description of the first kernel at runtime, the second kernel inherits a completely consistent hardware configuration view, eliminating the deviation of memory layout and device nodes caused by dynamic correction of firmware or boot program, and ensuring that the second kernel can start reliably; in addition, the crash image generation tool and the saving tool are encapsulated in the capture initramfs (a very small temporary file system that is loaded into memory for use in the early stage of Linux kernel startup) rather than integrated into the production root file system, which can reduce the size and interference of the production environment, and ensure the strong binding between the crash saving dependencies and the second kernel, thereby avoiding version coupling and tool conflicts between the production system and the capture environment.

[0008] In some implementations, after the second kernel preload command is invoked to load the current second kernel image file, the current captured initramfs, and the current hardware description into the crash dump memory, the method further includes: When the first kernel starts normally, check whether the current second kernel image file in the crash dump memory, the current captured initramfs, or the current hardware description has changed; If changes occur, unload the currently loaded second kernel image file from the crash dump memory, and clear the loaded content in the crash dump memory corresponding to the currently captured initramfs and the current hardware description; Check if the loading status flag of the second kernel is in an unloaded state; If it is not loaded, the updated target second kernel image file, the updated target capture initramfs, and the updated target hardware description are reloaded into the crash dump memory; Detect whether the loading status flag is in a loaded state; If the target second kernel image file is already loaded, the image information is recorded; wherein the image information includes one or more of the following: summary and version information.

[0009] In the above technical solution, this method can automatically detect whether the second kernel image, initramfs or hardware description has changed during the normal operation of the first kernel. After the change, it actively unloads the old loaded content, clears the corresponding memory area, and then reloads the updated files and descriptions. This ensures that the image used by the second kernel at the time of the crash is the latest version that is completely matched with the current system. At the same time, by checking the loading status flag, it confirms that the unloading and loading operations have been completed correctly and records the summary or version information of the loaded image for subsequent maintenance or debugging. This effectively avoids the problem of version mismatch or startup failure caused by relying solely on the loading status flag (kexec_crash_loaded=1) to misjudge "loaded is latest". This improves the overall reliability of the crash dump link.

[0010] In some embodiments, the method further includes: When the first kernel crashes, detect the real-time preemption configuration flag of the first kernel; If the real-time preemption configuration flag indicates that the first kernel is a real-time preemption kernel, the step of executing the localized crash shutdown process is triggered; If the real-time preemption configuration flag indicates that the first kernel is a non-real-time preemption kernel, then the general crash shutdown procedure is executed.

[0011] In the above technical solution, this method can automatically identify the kernel type by detecting the real-time preemption configuration flag when the first kernel crashes, and select a matching crash shutdown procedure accordingly. Specifically, for real-time preemptive kernels, a localized fast shutdown strategy is adopted to avoid being stuck while waiting for other CPUs or real-time locks; for non-real-time preemptive kernels, a general shutdown procedure is used to ensure complete acquisition of register states. Therefore, this method can effectively improve the success rate of crash jumps in real-time kernel scenarios without affecting the quality of crash dumps for non-real-time kernels.

[0012] In some implementations, the execution of the localized crash shutdown procedure includes: Disable local interrupts on the current CPU and save the crash context of the current CPU; wherein, the current CPU is the processor core that triggered the first kernel crash and executed the crash handling process; It does not perform the operation of sending a stop signal to other CPUs, nor does it perform the operation of traversing all interrupt chips to perform global masking.

[0013] In the above technical solution, the method can effectively avoid system freeze caused by waiting for other CPUs or global interrupt masking when the real-time kernel crashes, thereby significantly improving the success rate of crash jump, so that the crash dump process can smoothly enter the second kernel for execution.

[0014] In some implementations, the step of switching control of the current CPU to the second core includes: The CPU soft reset function is called through a kernel jump function to reset the current CPU to an initial state suitable for the second kernel to start; The kernel jump function is used to point the current CPU's instruction pointer to the entry address of the second kernel; The entry address of the second kernel is the entry address of the current second kernel image file loaded into the crash dump memory.

[0015] In the above technical solution, the method can reset the current CPU to the initial state required by the second kernel and directly jump to its entry address, realizing a fast switch from the crashed kernel to the captured kernel, avoiding startup failure due to incomplete reset or incorrect entry address, and ensuring that the second kernel can reliably take over execution in the reserved memory.

[0016] In some implementations, the step of performing a security initialization process on the target peripheral that inherits the peripheral interrupt state in the first kernel includes: Based on the current hardware description loaded in the crash dump memory, obtain the peripheral information of the target peripheral; wherein, the crash dump memory is a storage area reserved when the first kernel starts normally, used to store the current second kernel image file, the current captured initramfs and the current hardware description; the peripheral information includes register base address, interrupt number, working clock signal and reset control signal; The target peripheral device is hardware reset according to the reset control signal, and the working clock signal is enabled. Clear or disable the suspend interrupts and enable interrupts left over from the first kernel; Assign a device-private data structure to the target peripheral and initialize the critical runtime context of the target peripheral; After the critical runtime context initialization is completed, the interrupt handling function is registered according to the interrupt number; After the interrupt handler function is triggered, it is checked whether the critical runtime context has been initialized. If the critical runtime context has not been initialized, the currently arriving interrupt signal is determined to be an early interrupt signal, and the early interrupt signal is cleared or masked. If the critical runtime context has been initialized, then the corresponding interrupt handling operation is executed according to the interrupt handling function.

[0017] In the above technical solution, the method can effectively distinguish between normal interrupts and early interrupts left over from the first kernel by adding a context readiness detection mechanism at the entry point of the interrupt handling function, and promptly clear or mask early interrupts, thereby avoiding secondary crashes of the second kernel caused by accessing uninitialized memory or null pointers, and thus enabling the complete execution of the process of saving the crashed memory image.

[0018] In some implementations, when the first kernel starts normally, it reserves crash dump memory to store the current second kernel image file, the current captured initramfs, and the current hardware description; the current captured initramfs encapsulates crash image generation tools and crash saving tools; The step of storing the crashed memory virtual file in the proc file system to the storage partition includes: The crash saving tool checks whether a crash memory virtual file exists in the proc file system; wherein, the crash saving tool mounts the proc file system, the system file system, and the device file system; If it exists, when the storage partition is detected to be available, the crash dump start flag is written to the storage partition by the crash saving tool; Invoke the crash image generation tool to generate the target crash memory image file based on the crash memory virtual file; The target crash memory image file is stored in the storage partition using the crash saving tool. After the crash image generation tool completes its execution, the crash saving tool writes a crash dump completion flag and the execution log file of the crash image generation tool to the storage partition.

[0019] In the above technical solution, the method can isolate all the tools required for crash saving from the production environment, thereby avoiding the production system from carrying irrelevant dependencies; at the same time, through the writing mechanism of start flag and completion flag, a reliable status basis is provided for identification and export after restart, so that the saving process is traceable and verifiable.

[0020] In some implementations, storing the target crash memory image file to the storage partition includes: Scan the existing historical crash memory image files in the storage partition; Obtain the total number of files in the historical crash memory image files and the current available space of the storage partition; Based on the total number of files, the current available space, and the space retention policy, historical crash memory image files are partially deleted in chronological order of file creation time, so that the remaining available space of the storage partition is not less than a preset space threshold. The target filename of the target crash memory image file is generated according to the filename anti-overwrite policy, and the crash image generation tool is called to store the target crash memory image file to the storage partition.

[0021] In the above technical solution, the method can automatically scan the existing historical files in the storage partition before saving the target crash memory image file, and delete some historical files in the order of creation time according to the total number of files, the current available space, and the preset space retention policy, so as to ensure that the remaining available space of the storage partition is not lower than the preset threshold, thereby avoiding the failure to save the current crash image due to the exhaustion of storage space; at the same time, by generating non-conflicting target file names through the file name anti-overwriting policy, it can also effectively prevent the image files generated by multiple crashes from overwriting each other, ensuring that the on-site data of each crash can be independently preserved, providing a complete historical basis for subsequent fault reproduction and problem localization.

[0022] In some implementations, generating the target filename of the target crash memory image file according to the filename anti-overwrite policy includes: Generate the base filename for the target crash memory image file; wherein, the base filename includes the current crash memory image identifier and the currently available time information; Determine whether the base file name exists in the storage partition; If it exists, the base file name is processed according to the file name anti-overwriting strategy to obtain the target file name.

[0023] In the above technical solution, the method can automatically detect whether a file with the same name already exists in the storage partition after generating the basic file name, and process it according to the file name anti-overwriting strategy when it exists, thereby effectively avoiding the problem of duplicate name overwriting caused by the lack of a reliable time source or timestamp rollback in the system. This allows the image file generated by each crash to be saved independently, preserving a complete on-site historical record for subsequent fault analysis.

[0024] In some implementations, after storing the crashed memory virtual file from the proc filesystem to a storage partition, the method further includes: Perform a system reboot and restart the first kernel; After the first kernel restarts, the storage partition is mounted in read-only mode; Check the crash dump completion flag and the target crash memory image file in the storage partition; If the crash dump completion flag indicates success and the target crash memory image file is detected, then the storage partition is kept mounted in read-only mode, and a dump success message is output.

[0025] In the above technical solution, the method can automatically restart the system after the crash memory image is saved, so that the device can be restored to normal production status; after restarting the first kernel, the storage partition is mounted in read-only mode to avoid the production environment from accidentally modifying or deleting the saved crash scene data; by checking whether the crash dump completion flag and the image file exist, it is confirmed whether the previous round of crash dump was successful, and a prompt message is output when successful, providing a clear export and analysis entry point for operation and maintenance personnel, ensuring that the crash scene data can be obtained in a timely and complete manner.

[0026] In some embodiments, the method further includes: If the crash dump completion flag indicates failure, or if the target crash memory image file is not detected, then the storage partition is unmounted and remains unmounted during normal operation of the first kernel.

[0027] In the above technical solution, the method can automatically unmount the storage partition when it is detected that the crash dump is unsuccessful or the target image file is missing, and keep it in an unmounted state during the normal operation of the first kernel. This effectively avoids the production system from making erroneous read and write operations on the storage partition, prevents residual or damaged files in the storage partition from interfering with normal business operations, and thus improves the overall reliability of the system.

[0028] Secondly, this application provides a crash dump system for embedded systems, comprising: The crash shutdown module is used to execute a localized crash shutdown process when the first kernel crashes and the first kernel is a real-time preemptive kernel. The second kernel startup module is used to switch control of the current CPU to the second kernel after the localized crash shutdown process is completed, so that the second kernel can start running. A security initialization module is used to perform a security initialization process on a target peripheral device after the second kernel starts, inheriting the peripheral interrupt state in the first kernel; wherein, the target peripheral device is a hardware device that the second kernel needs to initialize in order to save a crashed memory image; The storage module is used to store the crashed memory virtual file in the proc file system to the storage partition after the security initialization process is completed.

[0029] In the above technical solution, the system can effectively avoid the real-time preemptive kernel from getting stuck during the crash shutdown phase due to waiting for other CPUs or real-time locks, thereby significantly improving the success rate of crash jumps. At the same time, by performing interrupt state security initialization inherited from the first kernel on the target peripheral after the second kernel starts, the risk of secondary crashes caused by residual interrupts is eliminated, ensuring that the crashed memory virtual file can be stably and completely saved to the storage partition, providing a reliable data foundation for subsequent fault location.

[0030] Thirdly, this application provides an electronic device including a memory and a processor, the memory storing a computer program, and the processor running the computer program to cause the electronic device to perform the crash dumping method of the embedded system described in any one of the first aspects.

[0031] Fourthly, this application provides a readable storage medium storing a computer program, which, when executed by a processor, performs the crash dumping method for an embedded system as described in any one of the first aspects.

[0032] Fifthly, this application provides a computer program product comprising a computer program that, when executed by a processor, performs the crash dumping method for an embedded system as described in the first aspect.

[0033] The beneficial effects of this application are as follows: By using the PREEMPT_RT dedicated minimal crash shutdown process, the first kernel can avoid getting stuck in the panic path while waiting for other CPUs or real-time locks, thus improving the success rate of jumping to the second kernel; by performing safe initialization of peripheral interrupt states after the second kernel starts, pending interrupts left over from the first kernel can be cleared or masked before registering interrupt handlers, preventing the second kernel from crashing again due to accessing an uninitialized context; by using runtime hardware description to load the second kernel, the problem of startup failure caused by inconsistencies between static hardware description and actual startup memory layout can be solved; by decoupling the crash saving tool from the production system and encapsulating it in the captured initramfs, the production system can be kept lightweight; through filename anti-overwriting strategies and dynamic storage space cleanup mechanisms when there is no reliable time source, mutual overwriting of vmcore files and storage partition filling can be avoided; through the post-reboot identification mechanism, clear confirmation and export entry points for dump results can be provided to operations and maintenance personnel. In summary, the above mechanisms together form a complete closed loop from crash jump, safe startup of the second kernel to user-mode saving, thereby systematically reducing the overall failure rate of crash dumping in real-time embedded scenarios. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a schematic diagram of a crash dump architecture for an embedded system in some embodiments of this application; Figure 2 This is a flowchart illustrating a crash dumping method for an embedded system according to some embodiments of this application; Figure 3 This is a core process for PREEMPT_RT crash jump in some embodiments of this application; Figure 4 This is a schematic diagram of the structure of a crash dump system for an embedded system according to some embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device in some embodiments of this application. Detailed Implementation

[0036] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0038] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more (including two), similarly, "multiple sets" refers to two or more sets (including two sets), and "multiple pieces" refers to two or more pieces (including two pieces) unless otherwise explicitly defined.

[0039] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0040] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0041] In PREEMPT_RT embedded systems, standard kdump is prone to getting stuck during the crash jump phase due to waiting for other CPUs or real-time locks. During the kernel startup capture phase, it is prone to secondary crashes due to peripheral interrupts left over from the first kernel. Furthermore, issues such as static hardware description, tool coupling, file overwriting, and space exhaustion further affect the reliability of the dump.

[0042] To address the aforementioned technical issues, this application provides a crash dumping method for an embedded system. This method aims to: break through two key breakpoints in the PREEMPT_RT device crash dumping chain: First, after the first kernel panics, it must stably enter machine_kexec using a minimized crash shutdown method; Second, after the second kernel starts, it must use a safe initialization method that inherits the hardware state to avoid panicking again due to residual interrupts.

[0043] For details, please refer to [link / reference]. Figure 1 , Figure 1 A schematic diagram of the crash dump architecture of an embedded system is shown.

[0044] like Figure 2 As shown, some embodiments of this application provide a crash dump method for an embedded system, which includes: S400 executes a localized crash shutdown procedure when the first kernel crashes and is a real-time preemptive kernel.

[0045] In this embodiment, the first kernel is the production kernel, which is the Linux kernel used when the system is running normally.

[0046] In this embodiment, the real-time preemptive kernel is the PREEMPT_RT kernel, which is a Linux kernel compiled with the real-time preemptive patch (PREEMPT_RTpatch) that supports interrupt threading and real-time scheduling strategies.

[0047] In this embodiment, the localized crash shutdown process is a minimal crash shutdown process. That is, in the panic path (i.e., the kernel crash handling path, which refers to the execution flow starting from the panic() function and passing through the crash_kexec(), __crash_kexec(), and machine_crash_shutdown() functions in sequence), only the local interrupts of the current CPU (i.e., the processor core that triggered the first kernel crash and executed the crash handling process) are shut down, the crash context of the current CPU is saved, and the operation of sending stop signals to other CPUs and the operation of traversing all interrupt chips for global masking are skipped. This is to avoid waiting for other CPUs or real-time locks in the panic context (i.e., the execution environment when the kernel crashes, in which the system state may be inconsistent, some kernel services may be unavailable, and some operations may lead to deadlock or infinite waiting, which could cause the system to freeze).

[0048] After the S500 completes the localized crash shutdown process, it switches control of the current CPU to the second kernel.

[0049] In this embodiment, "execution complete" means that all operations in the localized crash shutdown process (disabling local interrupts, saving the current CPU crash context, skipping cross-CPU stop and global interrupt masking) have been completed, and the system is ready to jump to the second kernel.

[0050] In this embodiment, the current CPU refers to the processor core that triggered the first kernel crash and executed the crash handling process, that is, the CPU core that executes functions such as crash_kexec, __crash_kexec and machine_crash_shutdown in the panic path.

[0051] In this embodiment, control refers to the CPU's instruction execution flow control, that is, the CPU's program counter (PC) and current execution context switch from the code segment of the first kernel to the code segment of the second kernel. After that, the CPU starts executing the instructions of the second kernel instead of the instructions of the first kernel.

[0052] In this embodiment, the second kernel is a capture kernel, which is a dedicated Linux kernel pre-loaded into the crash dump memory and used to take over the CPU and perform the task of saving the crash memory image after the first kernel crashes.

[0053] S600: After the second kernel starts, it performs a security initialization process that inherits the peripheral interrupt state in the first kernel for the target peripheral; the target peripheral is a hardware device that the second kernel needs to initialize in order to save the crash memory image.

[0054] In this embodiment, the second kernel startup refers to the process whereby, after the second kernel image file is loaded into the crash dump memory, the current CPU jumps to the entry address of the image file to start executing the initialization code of the second kernel and completes the early kernel initialization (including basic memory management, interrupt controller initialization and driver initialization framework preparation). At this time, the second kernel is capable of performing subsequent save tasks.

[0055] In this embodiment, the target peripheral refers to the hardware device that the second kernel needs to initialize to save the crash memory image. Specifically, in order to complete the saving of the crash memory image, the second kernel needs to initialize at least the storage controller (such as SDHCI, MMC, SATA controller, etc.) to write the generated crash memory image file to the non-volatile storage partition.

[0056] In this embodiment, SDHCI (Secure Digital Host Controller Interface) is an industry-standard host controller interface specification for connecting storage devices such as SD cards and eMMC. It defines the communication protocol and register interface between the host controller and the SD / eMMC device.

[0057] In this embodiment, eMMC (embedded MultiMediaCard) is an embedded solid-state storage medium based on NAND Flash. The MMC Host Controller is a host-side hardware module on the processor side used to communicate with the eMMC device, and is responsible for handling operations such as block read / write, erase, and command transmission.

[0058] In this embodiment, SATA (Serial Advanced Technology Attachment) is a storage interface standard for connecting hard disk drives (HDDs) and solid-state drives (SSDs). The SATA controller is a hardware module on the host side that implements SATA protocol communication and is responsible for managing the read and write operations and command queue scheduling of storage devices.

[0059] All three controllers mentioned above are storage device controllers that the second kernel may need to initialize to save the crash memory image. The second kernel gains access to the non-volatile storage partition by initializing at least one of these controllers, thereby writing the crash memory image to the storage partition.

[0060] In this embodiment, the crash memory image refers to the complete copy of the entire physical memory at the time of the first kernel crash, obtained by reading / proc / vmcore ( / proc / vmcore is a virtual file exposed by the Linux kernel through the proc file system under the kdump mechanism, used to allow the capturing kernel to read the physical memory image of the first kernel after the system crashes). This copy contains the kernel data structure, process context, stack information and hardware state snapshot at the time of the crash, which is the basis for subsequent fault location analysis.

[0061] In this embodiment, hardware devices refer to physical peripherals that interact with the CPU in an embedded system, including but not limited to memory controllers, ADCs (Analog-to-Digital Converters), GPIOs (General-Purpose Input / Output), DMA (Direct Memory Access) controllers, I2C / SPI controllers, temperature sensors, PMICs, and watchdogs. These devices exchange data with the CPU through interrupts, register read / write operations, and other means during system operation.

[0062] In this embodiment, the security initialization process refers to the following steps during the initialization of the target peripheral driver in the second kernel: before registering the interrupt handler function (request_irq), a hardware reset or power-on operation is performed, pending interrupts and enabled interrupts left over from the first kernel are cleared or masked, and the allocation and initialization of the device's private data structures and critical runtime contexts are completed. Then, the interrupt handler function is registered. Simultaneously, a context readiness detection mechanism is added at the entry point of the interrupt handler function. If the critical context is not ready, only the interrupt is cleared or masked, and the process returns without accessing uninitialized members. This process is used to prevent secondary crashes caused by premature triggering of interrupts left over from the first kernel before the second kernel context is ready. The target peripheral may include the MMC host controller.

[0063] S700: After the security initialization process is completed, the crash memory virtual file in the proc file system is stored to the storage partition.

[0064] In this embodiment, the proc filesystem is a virtual filesystem provided by the Linux kernel. It is usually mounted in the / proc directory and is used to present kernel runtime data in the form of a file interface.

[0065] / proc / vmcore is the interface file exposed by the kernel crash dump mechanism. Reading this file is equivalent to reading the complete contents of the entire physical memory at the time of the first kernel crash, including kernel data structures, process context and hardware state snapshots. It is the data source for generating crash memory images.

[0066] In this embodiment, the crash memory virtual file is the / proc / vmcore interface file, which is a virtual file generated by the kdump or kexec mechanism after a kernel crash.

[0067] This file does not actually exist on the storage medium; instead, it is dynamically generated by the kernel through the proc filesystem and serves as an access interface to the first kernel physical memory data. User-space tools (such as makedumpfile) read this file to obtain memory data from the crash scene.

[0068] In this embodiment, the storage partition is a non-volatile storage partition used to store historical crash memory image files. This partition is pre-allocated when the device starts up, and its file system type is typically FAT, ext4, or other persistent file systems supported by embedded devices.

[0069] This partition is not normally open to write permissions in the production system; it is only mounted and used when the capture kernel performs crash saving to prevent accidental contamination of the crash site data in the production environment.

[0070] In the above embodiments, the method can effectively avoid the real-time preemptive kernel from getting stuck during the crash shutdown phase due to waiting for other CPUs or real-time locks, thereby significantly improving the success rate of crash jumps. At the same time, by performing interrupt state security initialization inherited from the first kernel on the target peripheral after the second kernel starts, the risk of secondary crashes caused by residual interrupts is eliminated, ensuring that the crash memory virtual file can be stably and completely saved to the storage partition, providing a reliable data foundation for subsequent fault location.

[0071] In some embodiments, prior to step S400, the method may further include: S100: When the first kernel starts normally, reserve crash dump memory according to the boot parameters.

[0072] In this embodiment, the crash dump memory is the crashkernel contiguous physical memory (crashkernel contiguous physical memory refers to a segment of physical addresses that are reserved by the Linux kernel boot parameter crashkernel and are not used when the first kernel is running normally), which is used to configure the memory area required for crash dump when the system starts.

[0073] S200: When the enable flag of the crash dump memory is detected, obtain the current hardware description of the first kernel running.

[0074] In this embodiment, the current hardware description is the runtime hardware description, which is obtained through the production kernel export interface, so that the memory layout seen by the second kernel is consistent with the actual startup state of the current device.

[0075] In this embodiment, the hardware description can come from the FDT (Flattened Device Tree) exported at runtime, or from an equivalent hardware description dynamically generated by the bootloader or firmware.

[0076] S300 invokes the second kernel preload command to load the current second kernel image file, the current captured initramfs, and the current hardware description into the crash dump memory.

[0077] In this embodiment, the current second kernel image file is used to run as the second kernel after the first kernel crashes; The current initramfs capture package includes a crash image generation tool and a crash saving tool; the crash saving tool is called after the second kernel boots, and the crash image generation tool and crash saving tool are not configured in the normal operating environment of the first kernel; The current hardware description is used to ensure that the second kernel maintains the same hardware configuration as the first kernel at startup.

[0078] In this embodiment, the second kernel preloading command is kexec-p (a command option of the kexec tool provided by the Linux kernel), which is used to load the second kernel (capture kernel), the captured initramfs (initial RAM filesystem), and the runtime hardware description into the reserved memory.

[0079] In this embodiment, the currently captured initramfs is a temporary file system that encapsulates a crash image generation tool and a crash saving tool. The crash image generation tool is makedumpfile, and the crash saving tool is kdump-save.

[0080] In this embodiment, the current hardware description is a runtime hardware description, which is used to ensure that the hardware configuration of the second kernel is consistent with that of the first kernel at startup. This avoids the second kernel still using an outdated hardware description and causing startup failure after the bootloader or firmware has made runtime corrections to the memory, reserved areas, interrupt controllers or device nodes.

[0081] As an alternative implementation, the second kernel can use a trimmed-down dedicated capture kernel or the same image as the production kernel.

[0082] To ensure that the image used by the second kernel is the latest version that is fully compatible with the current system when a crash occurs, the method may further include the following after step S300 and before step S400: S310: When the first kernel starts normally, check whether the current second kernel image file, the current captured initramfs, or the current hardware description in the crash dump memory has changed.

[0083] In this embodiment, the objects detected are the second kernel image file (capture kernel), the captured initramfs, and the runtime hardware description.

[0084] In this embodiment, the detection is used to re-execute the kexec-p loading process after changes to the second kernel, the captured initramfs, or the runtime hardware description, to avoid running the old second kernel or the old initramfs after a panic.

[0085] S320. If changes occur, unload the currently loaded second kernel image file from the crash dump memory and clear the loaded content in the crash dump memory corresponding to the currently captured initramfs and the current hardware description.

[0086] In this embodiment, the unload operation is to stop the current kexec crash kernel, and the clear operation is to clear the corresponding loaded content in the crash dump memory.

[0087] S330. Check if the loading status flag of the second kernel is in an unloaded state. If yes, proceed to step S340; otherwise, end this process.

[0088] In this embodiment, ending this process means that the uninstallation failed, and the old content or abnormal state still remains in the crash dump memory, so the operation cannot continue and a safe exit is required.

[0089] In this embodiment, the loading status flag is kexec_crash_loaded. An unloaded status means that the unloading has been successful.

[0090] S340: Reload the updated target second kernel image file, the updated target capture initramfs, and the updated target hardware description into the crash dump memory.

[0091] In this embodiment, reloading means re-executing the kexec-p loading process.

[0092] S350. Check if the loading status flag is in the loaded state. If yes, proceed to step S360; otherwise, end this process.

[0093] In this embodiment, ending the process means loading failure, that is, the new content was not successfully loaded or the status is abnormal, so the operation cannot continue and a safe exit is required.

[0094] In this embodiment, the loaded status is kexec_crash_loaded=1.

[0095] S360 records the image information of the target's second kernel image file; wherein, the image information includes one or more of the following: summary and version information.

[0096] In this embodiment, a summary or version information of the image information is recorded to confirm that the latest file in the current file system is loaded, thus solving the problem of judging whether kdump has been correctly updated based solely on kexec_crash_loaded=1. This is because this status only indicates that "a crash kernel has been loaded," but it cannot prove that the latest file in the current file system is loaded.

[0097] In this embodiment, the kexec reload consistency check can be implemented using file digest, version number, load timestamp, kernel export status, or a dedicated log file.

[0098] In this embodiment, the save script is not placed in the production rootfs, but rather embedded in the capture initramfs. This way, the production system only needs to load the second kernel, and all the tools and dependencies required for crash saving are encapsulated in the second kernel environment, reducing the size of the production system image and runtime interference.

[0099] In this embodiment, this stage only requires the production rootfs to carry the kexec tool, and does not require the makedumpfile to be carried.

[0100] In this embodiment, the key point of this stage is that the production system only undertakes the responsibilities of "preloading" and "status checking", and the fault saving tool is encapsulated in the capture initramfs.

[0101] In the above embodiments, the method can pre-complete the memory reservation for crash dumping, the loading of the second kernel image and hardware description during the normal operation of the system, avoiding the failure of dumping due to the unavailability of storage devices or the time-consuming dynamic loading when a crash occurs; at the same time, by obtaining the current hardware description of the first kernel at runtime, the second kernel inherits a completely consistent hardware configuration view, eliminating the deviation of memory layout and device nodes caused by dynamic correction of firmware or boot program, ensuring that the second kernel can start reliably; in addition, the crash image generation tool and the saving tool are encapsulated in the capture initramfs (a very small temporary file system that is loaded into memory for use in the early stage of Linux kernel startup) rather than integrated into the production root file system, which can reduce the size and interference of the production running environment, and ensure the strong binding between the crash saving dependencies and the second kernel, thereby avoiding version coupling and tool conflicts between the production system and the capture environment.

[0102] In some embodiments, please refer to Figure 3 , Figure 3 A schematic diagram of the PREEMPT_RT crash jump core process is shown. Based on this process, step S400 may include: S410 detects the real-time preemption configuration flag of the first kernel when the first kernel crashes.

[0103] In this embodiment, the real-time preemption configuration flag is the PREEMPT_RT configuration flag, which is used to identify whether the current kernel is a real-time preemption kernel.

[0104] S420: If the real-time preemption configuration flag indicates that the first kernel is a real-time preemption kernel, execute the localized crash shutdown procedure.

[0105] In this embodiment, the localized crash shutdown process is a minimized crash shutdown, used to avoid waiting for other CPUs or IRQ threads in the panic context in the PREEMPT_RT scenario.

[0106] To prevent system freezes caused by waiting for other CPUs or global interrupt masking when a real-time kernel crashes, step S420 may include: S421. Disable local interrupts on the current CPU and save the crash context of the current CPU; where the current CPU is the processor core that triggered the first kernel crash and executed the crash handling process.

[0107] In this embodiment, the current CPU is the processor core that triggered the first kernel crash and executed the crash handling process.

[0108] In this embodiment, disabling local interrupts means disabling local interrupts of the current CPU, and saving the crash context means saving the crash context of the current CPU.

[0109] S422: It does not perform the operation of sending a stop signal to other CPUs, nor does it perform the operation of traversing all interrupt chips to perform global masking.

[0110] In this embodiment, not sending a stop signal to other CPUs is skipping the cross-CPU stop process, and not performing a global masking of all interrupt chips is skipping the IRQ chip masking process.

[0111] In this embodiment, this process can avoid waiting for other real-time tasks, IRQ threads, or real-time locks in a panic context, thereby improving the success rate of the jump.

[0112] In this embodiment, the design trade-off is that, in the event of a real-time kernel crash, rather than pursuing a complete acquisition of all CPU register states that would prevent the second kernel from starting, it is better to prioritize ensuring that the system can actually jump into the second kernel and retain the critical memory image.

[0113] S430: If the real-time preemption configuration flag indicates that the first kernel is a non-real-time preemption kernel, then the general crash shutdown procedure is executed.

[0114] In this embodiment, the general crash shutdown procedure is the ordinary kdump shutdown procedure. This is prior art and therefore will not be described in detail.

[0115] In the above embodiments, this method can automatically identify the kernel type by detecting the real-time preemption configuration flag when the first kernel crashes, and select a matching crash shutdown procedure accordingly. Specifically, for real-time preemptive kernels, a localized fast shutdown strategy is adopted to avoid being stuck while waiting for other CPUs or real-time locks; for non-real-time preemptive kernels, a general shutdown procedure is used to ensure complete acquisition of register states. Therefore, this method can effectively improve the success rate of crash jumps in real-time kernel scenarios without affecting the quality of crash dumps for non-real-time kernels.

[0116] In some embodiments, step S500 may include: S510 calls the CPU soft reset function through the kernel jump function to reset the current CPU to an initial state suitable for the second kernel to start.

[0117] In this embodiment, the kernel jump function is machine_kexec, and the CPU soft reset function is cpu_soft_restart.

[0118] S520: Through the kernel jump function, the instruction pointer of the current CPU is pointed to the entry address of the second kernel; where the entry address of the second kernel is the entry address of the current second kernel image file loaded into the crash dump memory.

[0119] In this embodiment, the entry address of the second kernel is the entry address of the current second kernel image file loaded into the crash dump memory. This operation is used to enter the capture kernel.

[0120] In the above embodiments, the method can reset the current CPU to the initial state required by the second kernel and directly jump to its entry address, realizing a fast switch from the crashed kernel to the captured kernel, avoiding startup failure due to incomplete reset or incorrect entry address, and ensuring that the second kernel can reliably take over execution in the reserved memory.

[0121] In some embodiments, step S600 may include: S610. Obtain the peripheral information of the target peripheral based on the current hardware description loaded in the crash dump memory. The crash dump memory is a storage area reserved when the first kernel starts normally, used to store the current second kernel image file, the current captured initramfs, and the current hardware description. The peripheral information includes the register base address, interrupt number, working clock signal, and reset control signal.

[0122] In this embodiment, the target peripheral is a hardware device that the second kernel needs to initialize to save the crashed memory image.

[0123] In this embodiment, the peripheral information includes the register base address (regs), interrupt number (irq), working clock signal (clk), and reset control signal (reset).

[0124] S620 performs a hardware reset operation on the target peripheral device according to the reset control signal and enables the working clock signal.

[0125] In this embodiment, the hardware reset operation is a peripheral reset, and the working clock signal is clk.

[0126] S630 clears or masks the suspend interrupts and enable interrupts left over from the first kernel.

[0127] In this embodiment, the pending interrupt and the enabled interrupt are called pending interrupt and enabled interrupt, respectively. The clear or mask operation is used to eliminate the peripheral interrupt state left over from the first kernel.

[0128] S640. Allocate a device private data structure to the target peripheral and initialize the critical runtime context of the target peripheral.

[0129] In this embodiment, the critical operating context refers to the critical operating context of the peripheral device, the waiting object, and the channel status.

[0130] S650: After the critical runtime context initialization is completed, register the interrupt handler function according to the interrupt number.

[0131] In this embodiment, the interrupt handling function is registered as request_irq.

[0132] In this embodiment, secure initialization can be achieved by delaying request_irq, explicitly clearing interrupt callbacks, ISR context determination, disabling specified peripherals in the device tree, or a combination thereof.

[0133] S660. After the interrupt handler is triggered, check whether the critical running context has been initialized. If yes, execute step S680; otherwise, execute step S670.

[0134] In this embodiment, the detection is performed by checking whether the critical context is ready through the ISR (Interrupt Service Routine).

[0135] S670. Determine that the currently arriving interrupt signal is an early interrupt signal, and clear or mask the early interrupt signal.

[0136] In this embodiment, an early interrupt signal (Early IRQ) refers to an interrupt signal that arrives within the time window when the interrupt handler function has been registered but the critical runtime context has not yet been initialized; the interrupt signal is determined to be an early interrupt signal because its arrival time is earlier than the context readiness time.

[0137] In this embodiment, if the critical context is not ready, the interrupt is simply cleared or masked and the process returns without accessing uninitialized members or waking up non-existent waiters.

[0138] S680. If the critical runtime context has been initialized, then the corresponding interrupt handling operation is executed according to the interrupt handling function.

[0139] In this embodiment, if the context is ready, the normal interruption process will be followed.

[0140] One additional point to note is that, prior to this proposal, the failure mechanisms that had been validated could be as follows: Taking SARADC as an example, before the first kernel crashes, a SARADC pending interrupt is left behind. After the system enters the capture kernel through kexec, the SARADC driver requests IRQ too early before the critical context is initialized, causing the PREEMPT_RT threaded IRQ to be triggered prematurely. The ISR accesses the uninitialized last_chan and other contexts, causing the capture kernel to panic twice, and / proc / vmcore can no longer be saved.

[0141] Based on this, it is clear that the root cause of the problem with the conventional solution is that after the second kernel starts, it directly follows the normal driver initialization order without considering the fact that the peripheral interrupt state may be inherited by the first kernel. However, the safe initialization solution proposed in step S600 of this application can perform peripheral reset, clear or mask legacy interrupts, complete critical context initialization, and then register the interrupt handling function before request_irq, thereby fundamentally avoiding the above problems. Moreover, this solution is not limited to the single SARADC peripheral, but is applicable to all target peripherals that need to be initialized in the second kernel.

[0142] In the above embodiments, this method can effectively distinguish between normal interrupts and early interrupts left over from the first kernel by adding a context readiness detection mechanism at the entry point of the interrupt handling function, and promptly clear or mask early interrupts, thereby avoiding secondary crashes of the second kernel caused by accessing uninitialized memory or null pointers, and thus ensuring that the process of saving the crashed memory image can be executed completely. Specifically, this method can also perform source cleanup on stale IRQs, timeouts, and error paths to prevent the second kernel from evolving from a single panic into an IRQ storm; and the capture kernel's inherited interrupt state safe initialization is applicable to SARADC, GPIO, DMA, I2C, SPI, temperature acquisition, PMIC, watchdog, or other peripherals.

[0143] In some embodiments, when the first kernel boots normally, it reserves crash dump memory to store the current second kernel image file, the currently captured initramfs, and the current hardware description; the currently captured initramfs encapsulates a crash image generation tool and a crash saving tool; wherein, step S700 may include: S710 checks whether a crash memory virtual file exists in the proc file system using a crash save tool; the crash save tool mounts the proc file system, the system file system, and the device file system.

[0144] In this embodiment, the virtual memory file for crashes is / proc / vmcore. The crash saving tool is the kdump-save script.

[0145] In this embodiment, the crash saving tool mounts the proc file system (proc), the system file system (sysfs), and the device file system (devtmpfs).

[0146] S720: If a crash memory virtual file exists in the proc file system, a crash dump start flag is written to the storage partition using the crash saving tool when the storage partition is detected to be available.

[0147] In this embodiment, the crash dump start flag is the kdump-started flag.

[0148] S730 invokes the crash image generation tool to generate the target crash memory image file based on the crash memory virtual file.

[0149] In this embodiment, the crash image generation tool is makedumpfile, and the target crash memory image file is the vmcore file.

[0150] In this embodiment, the crash saving tool is not limited to makedumpfile, but can also be other tools with vmcore reading, compression, and trimming capabilities.

[0151] S740 uses the crash save tool to store the target crash memory image file to the storage partition.

[0152] To avoid failure to save the current crash image due to running out of storage space, step S740 may also include: S741, Scan the storage partition for existing historical crash memory image files.

[0153] In this embodiment, the storage partition is a non-volatile storage partition / dump partition.

[0154] S742. Obtain the total number of historical crash memory image files and the current available space of the storage partition.

[0155] In this embodiment, this operation is used to determine the space reservation strategy.

[0156] S743. Based on the total number of files, the current available space, and the space retention policy, partially delete historical crash memory image files in chronological order of file creation time to ensure that the remaining available space of the storage partition is not lower than the preset space threshold.

[0157] In this embodiment, the space retention strategy is to set a maximum number of vmcores to be retained and a minimum remaining space threshold. When the number of files exceeds the limit or the remaining space is lower than the threshold, old vmcores are cleaned up by time or file sequence, and a cleanup log is recorded.

[0158] In this embodiment, the space reservation strategy can be implemented based on a combination of file number, total file size, remaining space ratio, file time order, or fault level.

[0159] S744. Generate the target filename of the target crash memory image file according to the filename anti-overwrite policy, and call the crash image generation tool to store the target crash memory image file to the storage partition.

[0160] In this embodiment, the filename anti-overwriting strategy is to append an incrementing sequence number to the vmcore file with the same name when there is no reliable time source.

[0161] In this embodiment, filename anti-overwriting can be achieved by using incremental suffixes, monotonic counters, persistent serial numbers, or device unique identifiers plus serial numbers.

[0162] For example, possible target file names are as follows: vmcore-19700101-000007, vmcore-19700101-000007-1, vmcore-19700101-000007-2.

[0163] As an optional implementation, the target filename for generating the target crash memory image file according to the filename anti-overwrite policy includes: The base filename for generating the target crash memory image file; where the base filename includes the current crash memory image identifier and the currently available time information; Determine if the base filename exists in the storage partition; If it exists, the base filename is processed according to the filename anti-overwriting policy to obtain the target filename.

[0164] In this embodiment, the target filename for generating the target crash memory image file according to the filename anti-overwriting strategy includes: Generate a base filename DUMP_BASE, which includes the vmcore identifier and currently available time information; initialize the target filename DUMP_FILE to DUMP_BASE; check if DUMP_FILE already exists; if it does, append an incrementing sequence number and regenerate DUMP_FILE until a conflict-free target filename is obtained.

[0165] S750: After the crash image generation tool finishes execution, the crash saving tool writes a crash dump completion flag and the execution log file of the crash image generation tool to the storage partition.

[0166] In this embodiment, the crash dump completion flag is the kdump-done flag, and the execution log file is makedumpfile.log.

[0167] In the above embodiments, this method isolates all tools required for crash saving from the production environment, thereby avoiding the production system carrying irrelevant dependencies. Simultaneously, the write mechanism of start and completion flags provides a reliable state basis for identification and export after a reboot, making the saving process traceable and verifiable. Specifically, compared to directly applying the general crash dump mechanism (kdump), this method significantly reduces the probability of the system crashing and getting stuck in the first kernel, the second kernel crashing again, the second kernel failing to boot, the vmcore being overwritten, the dump partition being filled, and the difficulty in identifying the dump results after a reboot.

[0168] In some embodiments, after step S700, the method may include: S810 performs a system reboot and restarts the first kernel.

[0169] In this embodiment, the system restart operation is to restart back to the production kernel.

[0170] After the first kernel reboot, the S820 mounts the storage partition in read-only mode.

[0171] In this embodiment, the storage partition is a dump partition, which is mounted in read-only mode for export analysis.

[0172] S830. Check the crash dump completion flag and target crash memory image file in the storage partition, and then proceed to step S840 or S850.

[0173] In this embodiment, checking the crash dump completion flag is done by checking the kdump-done flag.

[0174] In this embodiment, the post-reboot identification mechanism can be implemented using methods such as flag files, partition metadata, dedicated status blocks, log records, or device management service reporting.

[0175] S840. If the crash dump completion flag indicates success and the target crash memory image file is detected, then keep the storage partition mounted in read-only mode and output a dump success message.

[0176] In this embodiment, the output dump success message is a prompt to export analysis.

[0177] S850 If the crash dump completion flag indicates failure, or if the target crash memory image file is not detected, the storage partition is unmounted and remains unmounted during normal operation of the first kernel.

[0178] In this embodiment, unloading the storage partition means unloading the dump partition to keep it in an isolated state.

[0179] By adopting the above implementation method, this mechanism can avoid the production system from reading and writing dump partitions for a long time during normal business operations, while providing a clear operation and maintenance entry point after kdump is successful.

[0180] In the above embodiments, the method can automatically restart the system after the crash memory image is saved, so that the device can be restored to normal production status; after restarting the first kernel, the storage partition is mounted in read-only mode to avoid the production environment from accidentally modifying or deleting the saved crash scene data; by checking whether the crash dump completion flag and the image file exist, it is confirmed whether the previous round of crash dump was successful, and a prompt message is output when successful, providing a clear export and analysis entry point for operation and maintenance personnel, ensuring that the crash scene data can be obtained in a timely and complete manner.

[0181] like Figure 4 As shown, some embodiments of this application provide a structural schematic diagram of a crash dump system for an embedded system. It should be understood that this system is related to... Figure 1 The method executed in the middle corresponds to the steps involved in the aforementioned method. The specific functions and effects of the system can be found in the description above. To avoid repetition, detailed descriptions are omitted here.

[0182] The crash dump system of this embedded system includes: The crash shutdown module 910 is used to execute a localized crash shutdown process when the first kernel crashes and the first kernel is a real-time preemptive kernel. The second kernel boot module 920 is used to switch control of the current CPU to the second kernel after the localized crash shutdown process is completed, so that the second kernel can start running. The security initialization module 930 is used to perform a security initialization process on the target peripheral after the second kernel starts up, inheriting the peripheral interrupt state in the first kernel; wherein, the target peripheral is a hardware device that the second kernel needs to initialize in order to save the crash memory image; Storage module 940 is used to store the crashed memory virtual file in the proc filesystem to the storage partition after the security initialization process is completed. In some embodiments, the specific implementation of each module in the crash dump system of the embedded system corresponds one-to-one with the steps in the aforementioned method embodiments, and will not be elaborated here.

[0183] like Figure 5 As shown, this application provides an electronic device 1000, which includes a processor 1001 and a memory 1002. The processor 1001 and the memory 1002 are interconnected and communicate with each other through a communication bus 1003 and / or other forms of connection mechanism (not shown). The memory 1002 stores a computer program that can be executed by the processor 1001. When the computer program is run, the processor 1001 executes the computer program to perform the method in any of the aforementioned optional implementations.

[0184] This application provides a readable storage medium storing a computer program, which, when executed by a processor, performs the method in any of the aforementioned optional implementations.

[0185] The readable storage medium is a computer-readable storage medium, which can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0186] This application provides a computer program product, which includes a computer program that, when run by a processor, executes the method in any of the aforementioned optional implementations.

[0187] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A crash dump method for an embedded system, characterized in that, include: When the first kernel crashes and is a real-time preemptive kernel, a localized crash shutdown procedure is executed. After the localized crash shutdown process is completed, control of the current CPU is switched to the second kernel; After the second kernel starts, a security initialization process that inherits the peripheral interrupt state in the first kernel is executed on the target peripheral; wherein, the target peripheral is a hardware device that the second kernel needs to initialize in order to save the crash memory image; After the security initialization process is completed, the crash memory virtual file in the proc file system is stored to the storage partition; The step of performing a security initialization process on the target peripheral that inherits the peripheral interrupt state in the first kernel includes: Based on the current hardware description loaded in the crash dump memory, obtain the peripheral information of the target peripheral; wherein, the crash dump memory is a storage area reserved when the first kernel starts normally, used to store the current second kernel image file, the current captured initramfs and the current hardware description; the peripheral information includes register base address, interrupt number, working clock signal and reset control signal; The target peripheral device is hardware reset according to the reset control signal, and the working clock signal is enabled. Clear or disable the suspend interrupts and enable interrupts left over from the first kernel; Assign a device-private data structure to the target peripheral and initialize the critical runtime context of the target peripheral; After the critical runtime context initialization is completed, the interrupt handling function is registered according to the interrupt number; After the interrupt handler function is triggered, it is checked whether the critical runtime context has been initialized. If the critical runtime context has not been initialized, the currently arriving interrupt signal is determined to be an early interrupt signal, and the early interrupt signal is cleared or masked. If the critical runtime context has been initialized, then the corresponding interrupt handling operation is executed according to the interrupt handling function.

2. The crash dumping method for an embedded system according to claim 1, characterized in that, The method further includes: When the first kernel boots normally, memory is reserved for crash dumps based on the boot parameters; When the enable flag of the reserved crash dump memory is detected, the current hardware description of the first kernel runtime is obtained; The second kernel preload command is invoked to load the current second kernel image file, the current captured initramfs, and the current hardware description into the crash dump memory; The current second kernel image file is used to run as the second kernel after the first kernel crashes; The currently captured initramfs encapsulates a crash image generation tool and a crash saving tool; the crash saving tool is invoked after the second kernel starts up, and the crash image generation tool and the crash saving tool are not configured in the normal operating environment of the first kernel; The current hardware description is used to ensure that the second kernel maintains the same hardware configuration as the first kernel at startup.

3. The crash dumping method for an embedded system according to claim 2, characterized in that, After the second kernel preload command is invoked to load the current second kernel image file, the current captured initramfs, and the current hardware description into the crash dump memory, the method further includes: When the first kernel starts normally, check whether the current second kernel image file in the crash dump memory, the current captured initramfs, or the current hardware description has changed; If changes occur, unload the currently loaded second kernel image file from the crash dump memory, and clear the loaded content in the crash dump memory corresponding to the currently captured initramfs and the current hardware description; Check if the loading status flag of the second kernel is in an unloaded state; If it is in an unloaded state, the updated target second kernel image file, the updated target capture initramfs, and the updated target hardware description are reloaded into the crash dump memory; Detect whether the loading status flag is in a loaded state; If the target second kernel image file is already loaded, the image information is recorded; wherein the image information includes one or more of the following: summary and version information.

4. The crash dumping method for an embedded system according to claim 1, characterized in that, The method further includes: When the first kernel crashes, detect the real-time preemption configuration flag of the first kernel; If the real-time preemption configuration flag indicates that the first kernel is a real-time preemption kernel, the step of executing the localized crash shutdown process is triggered; If the real-time preemption configuration flag indicates that the first kernel is a non-real-time preemption kernel, then the general crash shutdown procedure is executed.

5. The crash dumping method for an embedded system according to claim 1, characterized in that, The execution of the localized crash shutdown process includes: Disable local interrupts on the current CPU and save the crash context of the current CPU; wherein, the current CPU is the processor core that triggered the first kernel crash and executed the crash handling process; It does not perform the operation of sending a stop signal to other CPUs, nor does it perform the operation of traversing all interrupt chips to perform global masking.

6. The crash dumping method for an embedded system according to claim 1, characterized in that, The step of switching control of the current CPU to the second core includes: The CPU soft reset function is called through a kernel jump function to reset the current CPU to an initial state suitable for the second kernel to start; The kernel jump function is used to point the current CPU's instruction pointer to the entry address of the second kernel; The entry address of the second kernel is the entry address of the current second kernel image file loaded into the crash dump memory.

7. The crash dumping method for an embedded system according to claim 1, characterized in that, When the first kernel starts normally, it reserves crash dump memory to store the current second kernel image file, the current captured initramfs, and the current hardware description; the current captured initramfs contains crash image generation tools and crash saving tools. The step of storing the crashed memory virtual file in the proc file system to the storage partition includes: The crash saving tool checks whether a crash memory virtual file exists in the proc file system; wherein, the crash saving tool mounts the proc file system, the system file system, and the device file system; If it exists, when the storage partition is detected to be available, the crash dump start flag is written to the storage partition by the crash saving tool; Invoke the crash image generation tool to generate the target crash memory image file based on the crash memory virtual file; The target crash memory image file is stored in the storage partition using the crash saving tool. After the crash image generation tool completes its execution, the crash saving tool writes a crash dump completion flag and the execution log file of the crash image generation tool to the storage partition.

8. The crash dumping method for an embedded system according to claim 7, characterized in that, The step of storing the target crash memory image file to the storage partition includes: Scan the existing historical crash memory image files in the storage partition; Obtain the total number of files in the historical crash memory image files and the current available space of the storage partition; Based on the total number of files, the current available space, and the space retention policy, historical crash memory image files are partially deleted in chronological order of file creation time, so that the remaining available space of the storage partition is not less than a preset space threshold. The target filename of the target crash memory image file is generated according to the filename anti-overwrite policy, and the crash image generation tool is called to store the target crash memory image file to the storage partition.

9. The crash dumping method for an embedded system according to claim 8, characterized in that, The target filename for generating the target crash memory image file according to the filename anti-overwrite policy includes: Generate the base filename for the target crash memory image file; wherein, the base filename includes the current crash memory image identifier and the currently available time information; Determine whether the base file name exists in the storage partition; If it exists, the base file name is processed according to the file name anti-overwriting strategy to obtain the target file name.

10. The crash dumping method for an embedded system according to claim 1, characterized in that, After storing the crashed memory virtual file in the proc filesystem to the storage partition, the method further includes: Perform a system reboot and restart the first kernel; After the first kernel restarts, the storage partition is mounted in read-only mode; Check the crash dump completion flag and the target crash memory image file in the storage partition; If the crash dump completion flag indicates success and the target crash memory image file is detected, then the storage partition is kept mounted in read-only mode, and a dump success message is output.

11. The crash dumping method for an embedded system according to claim 10, characterized in that, The method further includes: If the crash dump completion flag indicates failure, or if the target crash memory image file is not detected, then the storage partition is unmounted and remains unmounted during normal operation of the first kernel.

12. A crash dump system for an embedded system, characterized in that, The crash dump system includes: The crash shutdown module is used to execute a localized crash shutdown process when the first kernel crashes and the first kernel is a real-time preemptive kernel. The second kernel startup module is used to switch control of the current CPU to the second kernel after the localized crash shutdown process is completed, so that the second kernel can start running. A security initialization module is used to perform a security initialization process on a target peripheral device after the second kernel starts, inheriting the peripheral interrupt state in the first kernel; wherein, the target peripheral device is a hardware device that the second kernel needs to initialize in order to save a crashed memory image; The storage module is used to store the crashed memory virtual file in the proc file system to the storage partition after the security initialization process is completed; Specifically, the security initialization module is used for: Based on the current hardware description loaded in the crash dump memory, obtain the peripheral information of the target peripheral; wherein, the crash dump memory is a storage area reserved when the first kernel starts normally, used to store the current second kernel image file, the current captured initramfs and the current hardware description; the peripheral information includes register base address, interrupt number, working clock signal and reset control signal; The target peripheral device is hardware reset according to the reset control signal, and the working clock signal is enabled. Clear or disable the suspend interrupts and enable interrupts left over from the first kernel; Assign a device-private data structure to the target peripheral and initialize the critical runtime context of the target peripheral; After the critical runtime context initialization is completed, the interrupt handling function is registered according to the interrupt number; After the interrupt handler function is triggered, it is checked whether the critical runtime context has been initialized. If the critical runtime context has not been initialized, the currently arriving interrupt signal is determined to be an early interrupt signal, and the early interrupt signal is cleared or masked. If the critical runtime context has been initialized, then the corresponding interrupt handling operation is executed according to the interrupt handling function.

13. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory being used to store a computer program, and the processor running the computer program to cause the electronic device to perform the crash dumping method of the embedded system according to any one of claims 1 to 11.

14. A readable storage medium, characterized in that, The readable storage medium stores a computer program, which, when executed by a processor, performs the crash dumping method of the embedded system according to any one of claims 1 to 11.

15. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, performs the crash dumping method for the embedded system according to any one of claims 1 to 11.

Images