System partition compression method and device for automobile traveling data recorder

Abstract

The embodiment of the application discloses a kind of system partition compression method and device of automobile driving recorder, method includes: obtaining system data, according to the time point of whether mounting external safe storage is divided into first data and second data;First data is compressed to generate system partition mirror image, so that the system partition capacity of internal nonvolatile flash memory is reduced to target value;Second data is deployed to external safe storage, and the target partition layout of internal flash memory is constructed to store the corresponding part of first data.The application is divided into two levels with the time point of mounting external storage as boundary, the key content is retained internally, and the non-key content is migrated to external.Combining the compression strategy, the internal flash memory capacity is reduced, and the external storage is integrated into the system architecture to form an internal-external collaboration.Under the premise of ensuring normal startup and operation, the hardware cost is reduced, the storage utilization efficiency is improved, and the embedded storage requirements of automobile driving recorder with high reliability and low cost are met.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing technology, and in particular to a system partition compression method and apparatus for an automotive driving recorder. Background Technology

[0002] Vehicle driving recorders are core devices for monitoring the operation of commercial vehicles. Their storage systems typically consist of internal non-volatile flash memory and external storage devices. This architecture allows for physical separation of the operating system and business data, which helps reduce the risk of single points of failure.

[0003] However, traditional storage architectures store all system content entirely in internal non-volatile flash memory, requiring significant capacity. The cost per unit capacity of non-volatile flash memory is far higher than that of NAND flash memory or embedded multimedia cards, resulting in persistently high hardware costs. System partitions contain a large amount of runtime-only accessed content, permanently occupying scarce flash memory space; external storage is only used as audio and video data storage media and is not integrated into the system storage architecture, leading to a lack of coordination between internal and external resources. Furthermore, securely offloading system components to external storage involves complex startup dependencies and timing issues. Traditional storage architectures lack effective mechanisms for rationally classifying and dynamically migrating system content, causing internal flash memory to always carry all system functions, making it difficult to improve storage resource utilization efficiency. Summary of the Invention

[0004] This application provides a system partition compression method and apparatus for a vehicle driving recorder. The method achieves a two-level partitioning based on the availability of external secure storage, ensuring that critical startup content is retained in internal flash memory while non-critical content is migrated to external storage. Combining this with compression processing reduces the system partition capacity. This significantly reduces the internal flash memory capacity requirement and hardware costs; external storage is integrated into the system architecture, creating internal and external synergy, thus improving storage resource utilization efficiency while ensuring normal system startup and operation.

[0005] In a first aspect, embodiments of this application provide a system partition compression method for a vehicle driving recorder, including: The system acquires data from a vehicle driving recorder, which includes internal non-volatile flash memory and external secure storage. According to the preset judgment criteria, the system data is divided into first data and second data. The preset judgment criteria are used to characterize the moment when an external secure storage device can be mounted. The first data is compressed to generate a compressed system partition image, so that the capacity of the system partition used to store the first data in the internal non-volatile flash memory of the vehicle driving recorder is reduced to a preset target value. For the second data, it is deployed to an external secure storage, and a target partition layout for the internal non-volatile flash memory is constructed based on the system partition image. Each partition in the target partition layout is used to store the corresponding part of the first data.

[0006] Secondly, embodiments of this application provide a system partition compression device for a vehicle driving recorder, comprising: The content acquisition unit is used to acquire system data from the vehicle driving recorder, which includes internal non-volatile flash memory and external secure memory. The content partitioning unit is used to divide the system data into first data and second data according to a preset judgment standard. The preset judgment standard is used to characterize the moment when an external secure storage can be mounted. The content compression unit is used to perform compression processing on the first data and generate a compressed system partition image so that the capacity of the system partition used to store the first data in the internal non-volatile flash memory of the vehicle driving recorder is reduced to a preset target value. The architecture building unit is used to deploy the second data to an external secure storage and build a target partition layout for the internal non-volatile flash memory based on the system partition image. Each partition in the target partition layout is used to store the corresponding part of the first data.

[0007] Thirdly, embodiments of this application provide a vehicle driving recorder, including a processor, a memory, and one or more programs, the one or more programs being stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps as described in the first aspect of embodiments of this application.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps in the first aspect of embodiments of this application.

[0009] Fifthly, embodiments of this application provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement some or all of the steps described in the first aspect of embodiments of this application.

[0010] As can be seen, in this embodiment, the system content is divided into boot-critical data and non-critical data based on the criterion of whether external secure storage can be mounted. This allows the internal non-volatile flash memory to only carry the necessary bootloader, kernel, and minimal root file system before mounting, while non-critical content such as kernel modules, runtime libraries, business applications, and algorithm libraries are migrated to external secure storage. Simultaneously, combined compression processing is performed on the boot-critical data, significantly reducing the system partition capacity of the internal flash memory. Therefore, while ensuring normal system startup and stable operation, the internal flash memory capacity requirement is greatly reduced, resulting in a significant decrease in hardware costs. External storage is integrated into the system architecture, enabling collaborative work between internal and external storage resources, avoiding the waste of resources by using large-capacity external storage solely as a data warehouse, and comprehensively improving the economy and scalability of the storage architecture. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the structure of a vehicle driving recorder storage system provided in an embodiment of this application; Figure 2 This is a schematic flowchart of a system partition compression method for a vehicle driving recorder provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating a scenario of a two-level symbolic linking and version switching mechanism provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating a scenario of mounting an external security storage device at startup, as provided in an embodiment of this application. Figure 5 This is a schematic diagram of a three-stage differentiated OTA upgrade process provided in an embodiment of this application; Figure 6 This is a functional unit block diagram of a system partitioning compression device for a vehicle driving recorder provided in an embodiment of this application; Figure 7 This is a functional unit block diagram of another vehicle driving recorder system partition compression device provided in the embodiments of this application; Figure 8 This is a structural block diagram of a vehicle driving recorder provided in an embodiment of this application. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0014] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but in some embodiments includes steps or units not listed, or in some embodiments includes other steps or units inherent to these processes, methods, products, or apparatuses.

[0015] 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.

[0016] In the embodiments of this application, "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent the following three situations: A exists alone; A and B exist simultaneously; B exists alone. Among them, A and B can be singular or plural.

[0017] In this embodiment, the symbol " / " can indicate that the preceding and following objects are in an "or" relationship. Alternatively, the symbol " / " can also represent a division sign, i.e., performing a division operation. For example, A / B can mean A divided by B.

[0018] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0019] In the embodiments of this application, "equal to" can be used with "greater than" and is applicable to technical solutions used when "greater than" is used; it can also be used with "less than" and is applicable to technical solutions used when "less than" is used. When "equal to" is used with "greater than", it is not used with "less than"; when "equal to" is used with "less than", it is not used with "greater than".

[0020] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a vehicle driving recorder storage system provided in an embodiment of this application. Figure 1 As shown, the vehicle driving recorder storage system 10 includes an internal non-volatile flash memory 110 and an external secure memory 120. The internal non-volatile flash memory 110 is a NOR flash memory chip used to store critical system startup data. The external secure memory 120 is an embedded Multi Media Card (eMMC) chip that meets protection standards and is used to simultaneously carry non-critical system components and driving record data.

[0021] Specifically, the capacity of the internal non-volatile flash memory 110 (i.e., NOR Flash) is reduced to a preset target capacity value after compression (e.g., reduced to 4MB in one specific embodiment). Its partition layout includes at least a system partition, a bootloader partition, an operating system kernel image partition, a compressed read-only root file system partition, and a miscellaneous partition. Each partition is used to store the corresponding part of the boot-critical content. The external secure memory 120 communicates with the system-on-chip (SoC) 130 via an eMMC interface. Its storage space is divided into a system component area and a data recording area. The system component area is used to store kernel modules, runtime libraries, system management tools, business applications, and artificial intelligence algorithm libraries. The data recording area is used to store driving audio and video data and system parameters. The capacity of the internal non-volatile flash memory can be selected with a larger capacity specification according to the actual system requirements to increase the capacity margin of each partition.

[0022] In the vehicle driving recorder storage system 10, the internal non-volatile flash memory 110 is used to provide bootloader execution and operating system kernel loading after the system is powered on, until the root file system is mounted and has the ability to mount the external secure storage 120. After mounting, the external secure storage 120 is used to transparently redirect access requests for non-boot-critical content to its system component area through a pre-built symbolic link mechanism, realizing internal and external coordination of the system storage architecture. Multiple symbolic links are pre-built in the root file system, pointing to the corresponding versioned storage directories in the external secure storage 120. The versioned storage directories are organized by kernel version, and the symbolic links can switch between the currently active version directory and the new version directory through writable symbolic links to support atomic switching and fault rollback during system upgrades.

[0023] Based on this, the present application provides a system partition compression method for a vehicle driving recorder. The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0024] Please see Figure 2 , Figure 2 This is a flowchart illustrating a system partitioning compression method for a vehicle driving recorder provided in an embodiment of this application. The method is applied to the vehicle driving recorder storage system 10 and includes: Step S201: Obtain system data from the vehicle driving recorder.

[0025] The vehicle driving recorder includes internal non-volatile flash memory and external secure storage. System data refers to all program files and configuration data contained in the operating system and system partition running on the vehicle driving recorder, including but not limited to the bootloader program, operating system kernel image, root file system, kernel modules, system management tools, runtime libraries, business applications, and artificial intelligence algorithm libraries. This step is the initial stage of the entire system partition compression method, and its purpose is to completely acquire the system data set to be processed, providing an operational object for subsequent data classification, compression, and deployment.

[0026] Step S202: According to the preset judgment criteria, the system data is divided into first data and second data.

[0027] The preset judgment criteria characterize the moment when external secure storage can be mounted. According to these criteria, the content required from system power-on until the kernel completes mounting the root file system and is able to mount external secure storage is classified as first data, and the content required to access after external secure storage is mounted is classified as second data. The design principle of this judgment criterion is that the system startup process has different timing stages, and the storage devices that can be accessed differ at different stages. Only by using "whether external storage can be mounted" as an objective judgment boundary can we accurately identify which content must remain in internal flash memory and which content can be safely migrated to external storage, thus providing a reasonable classification basis for subsequent partitioning, compression, and storage coordination.

[0028] The vehicle driving recorder also includes a security device, which is an independent security chip used to store the verification key and perform security authentication operations; the verification key cannot be read out through an external interface.

[0029] In one possible embodiment, the first data includes a bootloader program, a compressed operating system kernel image, a base root file system, and a mount assist tool, an upgrade signature verification key, a security authentication tool, and a base output driver within the base root file system. The operating system kernel image includes a controller driver and a file system driver for an external secure memory embedded in the kernel. The upgrade signature verification key is stored in the base root file system and is used to sign and verify the upgrade package in the bootloader's recovery mode. The security authentication tool does not depend on the kernel module stored in the external secure memory, ensuring that it is executable before the external secure memory is mounted. The security authentication tool is only used to transfer verification ciphertext between the SoC and the security device. The verification key required for authentication is stored inside the security device, and the SoC does not hold the verification key. When authentication fails, it runs in a restricted mode. In the restricted mode, business services that depend on the external secure memory are stopped, and no write operations are performed on the data partitions of the external secure memory.

[0030] Step S203: Perform compression processing on the first data to generate a compressed system partition image, so that the capacity of the system partition used to store the first data in the internal non-volatile flash memory is reduced to a preset target value.

[0031] Compression processing refers to applying a combination of compression techniques, including file system-level compression, kernel image compression, and binary data embedding, to the various components of the first data. This reduces the system data volume and packages it into a unified system partition image. The system partition image is a collection of image files that encapsulates the compressed first data according to the target partition layout, making it suitable for burning to internal non-volatile flash memory. The design principle of this step is that the first data is critical to the boot process and must reside in internal non-volatile flash memory. However, the unit capacity cost of non-volatile flash memory is high. By performing compression processing to reduce its storage capacity, the requirement for non-volatile flash memory capacity can be reduced while ensuring the integrity of the boot function, thereby reducing hardware costs.

[0032] In one possible embodiment, the first data includes a bootloader program, an operating system kernel image, and a root file system; the compression process includes at least: building the root file system into a compressed read-only file system, and embedding the environment variable data required for the bootloader program to run in the bootloader program's binary file at compile time, thereby eliminating the need for a separate environment variable partition; after performing the compression process, if the system partition capacity is still not reduced to the preset target value, then at least one of the remaining compression measures is performed, and the system partition capacity is detected until it is reduced to the preset target value.

[0033] The remaining compression measures include: changing the compression method of the operating system kernel image from the first compression ratio to the second compression ratio, reducing the capacity of the partition where the boot program is located and the miscellaneous partition in the internal non-volatile flash memory, and removing the independent parameter partition in the internal non-volatile flash memory. The second compression ratio is higher than the first compression ratio.

[0034] Furthermore, if the system partition capacity still fails to shrink to the preset target value after all compression measures are performed, an error message will be output and the compression process will be stopped.

[0035] The specific implementation of embedding environment variable data during compilation is as follows: the boot parameters and kernel load address of the bootloader program are defined as constant string arrays, which are stored as part of the read-only data segment in the bootloader program's binary file after compilation and linking; when the root file system is built as a compressed read-only file system, all files and directories corresponding to the second data are removed, and only the first data file is organized as a temporary root directory, and the file system image generation tool is called to package the temporary root directory into a compressed read-only file system image; after the independent parameter partition is removed, the system running parameters originally stored therein are changed to be stored as files in the data partition of the external secure storage; the capacity of the partition where the bootloader program is located and the miscellaneous partition are reduced to release unused storage space, and the reduction boundary is the lower limit of the actual size of the bootloader program binary file and miscellaneous data.

[0036] For example, suppose the original system partition capacity is... The compression contribution of each compression measure is as follows: Execute the first System partition capacity after compression measures satisfy: ; in, The contributions of each compression measure are independent and can be linearly added together. The final capacity after implementing all compression measures is... satisfy: ; After a certain compression measure is implemented ( In this embodiment, a preset target value is used. If the value is 4.0MB, stop performing the remaining compression measures; if all compression measures are performed... n Even after the compression measures, it still exists If the compression fails, an error message will be output.

[0037] As can be seen, in this example, by compiling and embedding environment variables to eliminate the env partition, using a high compression algorithm to reduce the image size of the kernel, simplifying the root file system and building it into a compressed read-only file system, reducing the size of the boot partition and miscellaneous partitions, and removing the independent param partition, each measure contributes independently and effectively reduces the system partitions, lowers the capacity requirements of the internal NOR Flash, and thus allows the use of lower-cost NOR Flash chips.

[0038] In one possible embodiment, the root file system is a read-only file system, and the writable directories required at runtime are handled in the following way: the temporary file directory is mounted as a memory file system; the log directory, the variable data directory, and the configuration files that need to be modified at runtime are stored in corresponding locations in external secure storage and accessed through pre-built file-level symbolic links in the root file system.

[0039] Writable symbolic links used for version switching point to dynamic directory paths in external secure storage organized by kernel version (e.g., / lib / modules points to / mnt / safemem / lib / modules / 5.10.222 / ). These paths change during system version upgrades to reflect the new version's directory structure. File-level symbolic links point to fixed-function directory paths in external secure storage (e.g., / var / log points to / mnt / safemem / var / log), and these paths remain unchanged with version updates. File-level and writable symbolic links point to different branches of the same path in the directory tree, and their paths do not intersect to avoid access errors caused by path overlap during symbolic link resolution.

[0040] The temporary file directory is / tmp, the log directory is / var / log, the variable data directory is / var / lib, and the configuration directory is / etc. Files in the / tmp directory only need to exist temporarily during system operation and can be discarded after system power failure, so they are mounted to the memory file system. Log files in the / var / log directory and persistent state data in the / var / lib directory need to be retained after system power failure, so they are redirected to external secure storage. Configuration files in the / etc directory (such as network configuration and OTA (Over-The-Air) public keys) may need to be modified during system operation due to changes in the network environment or OTA updates. Since the root file system is read-only and cannot be written, it is also redirected to external secure storage.

[0041] Here, the root file system is assumed to be a read-only file system. The external secure storage mount point is The mount point for the memory file system is The temporary file directory is The log directory is Variable data directory is The configuration file directory is The actual storage locations of each directory satisfy the following mapping relationship: ; ; ; ; When an application initiates a read / write request through any of the aforementioned directory paths, the operating system's Virtual File System (VFS) resolves the original path to the redirected target path based on pre-built symbolic link records in the root file system. The application itself does not need to be aware of the change in the target path. The write operation request is then routed to the corresponding physical storage medium based on the resolved target path prefix: The initial request lands on the memory file system, to The initial request landed in external secure storage, and the root file system itself remained in a read-only state without receiving any write requests.

[0042] As can be seen in this example, by mounting / tmp to the memory file system and redirecting / var / log, / var / lib, and / etc to external secure storage via symbolic links, the symbolic link resolution mechanism of the operating system's VFS layer automatically distributes the application's access requests to these four directories to the corresponding physical storage media. This ensures both the read-only integrity of the root file system and meets the differentiated storage requirements of runtime data on different storage media. At the same time, separating the file-level symbolic links used for redirecting functional directories from the writable symbolic links used for version switching avoids path resolution anomalies caused by chaotic symbolic link pointers.

[0043] Step S204: For the second data, deploy it to an external secure storage and construct the target partition layout of the internal non-volatile flash memory based on the system partition image.

[0044] The deployment process involves writing the components of the second data into a designated directory on an external secure storage device as files. This allows the external secure storage device to not only hold driving record data but also serve as a storage component for non-boot-critical system components, becoming an integral part of the system's storage architecture. The target partition layout refers to the partition structure obtained by dividing the internal non-volatile flash memory storage space according to functional requirements. Each partition in this layout matches the size and location of the system partition mirror, and is used to store the corresponding portion of the first data. The design principle of this step is that the internal non-volatile flash memory has freed up some storage space after compression. This space needs to be allocated to the boot-critical content partitions in a reasonable manner by replanning the partition layout, while simultaneously enabling the external secure storage device to perform the storage function of the second data. This forms a coordinated internal and external system architecture, thereby optimizing the allocation of storage resources while ensuring normal system startup and operation.

[0045] In one possible embodiment, deploying the second data to an external secure storage device includes: configuring the external secure storage device to simultaneously hold the second data and driving record data captured by the vehicle driving recorder; storing system parameters that need to be accessed after the external secure storage device is mounted in the data partition of the external secure storage device; pre-creating symbolic links in the root file system image, the symbolic links pointing to writable symbolic links in the external secure storage device; mounting the external secure storage device; and after the external secure storage device is mounted, the symbolic links redirect access requests to a target path in the currently active version directory via the writable symbolic links.

[0046] The writable symbolic link is used to switch the directory from the currently active version to the new version's file directory during system version upgrades of the vehicle dashcam. The external secure storage is a protective embedded multimedia card compliant with relevant vehicle dashcam standards. Its internal logical area is divided into a system component area and a data recording area. The system component area stores non-boot-critical content, while the data recording area stores driving record data. Both share the protection capabilities of the same physical storage medium. This embodiment uses the external secure storage for both system component storage and driving record data storage, sharing the fireproof, waterproof, and pressure-resistant protection capabilities of the same physical storage medium. This meets the protection requirements for critical data storage media in relevant vehicle dashcam standards without adding additional storage chips.

[0047] Specifically, the pre-built symbolic links in the root file system include at least the mappings to the following non-boot-critical paths: / opt / ko points to / mnt / safemem / opt / ko, / opt / app points to / mnt / safemem / opt / app, / opt / ailib points to / mnt / safemem / opt / ailib, / opt / tools points to / mnt / safemem / opt / tools, / usr / local / lib points to / mnt / safemem / usr / local / lib, / lib / modules points to / mnt / safemem / lib / modules, and / data points to / mnt / safemem / data. These symbolic links are used to redirect access requests from kernel modules, business applications, algorithm libraries, system tools, and runtime libraries to external secure storage.

[0048] In this system, the pre-built symbolic links in the root file system image do not directly point to the final target file or directory, but rather to writable symbolic links in external secure storage, forming a two-level symbolic link structure: the first level consists of static symbolic links in the root file system. The second level consists of writable symbolic links in external secure storage. Let the original access path be... The path resolution process is as follows: ; ; in, This is the path to the currently active version directory. The actual access path after merging. for: ; in Remove from the original path The remaining subpaths after the overridden prefix. During system version upgrades, new version files are deployed to the new version directory. Then The pointer is from Updated to ,Right now: ; This update operation only modifies writable symbolic link files in external secure storage and static symbolic links in the root file system. No modifications are required. Since the root file system is read-only, if a single-level symbolic link (the root file system symbolic link directly points to the versioned directory) is used, the root file system image needs to be rebuilt every time a version upgrade is performed. However, this embodiment uses a two-level symbolic link structure, so when switching versions, only the writable symbolic link in the external secure storage needs to be modified, without modifying the read-only root file system.

[0049] For example, please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating a scenario of a two-level symbolic linking and version switching mechanism provided in an embodiment of this application. For example... Figure 3 As shown, the scenario involves the root file system and external secure storage of a vehicle dashcam. The root file system resides in internal non-volatile flash memory and is a read-only file system. The external secure storage is mounted at the mount point / mnt / safemem within the root file system. The root file system contains pre-built static symbolic links. This includes, but is not limited to, mappings such as / opt / ko pointing to / mnt / safemem / opt / ko, / opt / app pointing to / mnt / safemem / opt / app, / usr / local / lib pointing to / mnt / safemem / usr / local / lib, and / lib / modules pointing to / mnt / safemem / lib / modules. Writable symbolic links are stored in the external secure storage. And multiple versioned directories, with the ability to write symbolic links. This is used to switch from the currently active version directory to the new version file directory when the system version is upgraded. The versioned directory is organized by kernel version.

[0050] like Figure 3 As shown, the application accesses the original path. When an access request is made (e.g., / opt / ko / driver.ko), it is made via a static symbolic link in the root file system. The first level of resolution is performed, resolving the original access path into a writable symbolic link in external secure storage. ; then via writable symbolic links Based on the currently pointed-to activation version directory The second level of parsing reveals the target access path as / mnt / safemem / opt / ko / / driver.ko, thus completing target access. During system version upgrades, new version files are deployed to the new version directory. After that, you only need to add the writable symbolic link. The pointer is from Updated to Static symbolic links No modifications are needed.

[0051] As can be seen, in this example, by simultaneously carrying the second data and driving record data in the external secure storage, unified utilization of storage resources is achieved; by storing system parameters in the data partition of the external storage, the separate partitioning for parameters in the internal NOR Flash is avoided; and through the two-level symbolic link structure composed of first-level and second-level resolution, the modification operations required for version switching are transferred from the read-only root file system to the writable symbolic links in the external secure storage, so that target access does not need to rebuild the root file system image during version upgrade, simplifying the upgrade process.

[0052] In one possible embodiment, mounting the external secure storage includes: before mounting the external secure storage, the target path ultimately pointed to by the symbolic link via the writable symbolic link does not exist, the symbolic link is in a dangling state, and the mount point of the external secure storage is an empty directory before mounting; the startup script is executed in a preset numbered order; the mount script calls a mount auxiliary tool located in the root file system to perform the mounting of the external secure storage; before the external secure storage is mounted, the startup script does not access the target path pointed to by the symbolic link.

[0053] The mount script for mounting external secure storage executes before all subsequent scripts that might access the target path pointed to by the symbolic link. The startup scripts execute in a pre-defined numerical order: each startup script's filename contains a numerical number, and they are executed sequentially from smallest to largest during system startup; the mount script's number is smaller than the numbers of all startup scripts accessing the target path pointed to by the symbolic link. When the mount script executes, it first checks if the external secure storage device node exists. If it does, it calls a mount utility to mount the data partition of the external secure storage to the mount point. After successful mounting, the symbolic link changes from a dangling state to a valid state, and subsequent scripts can then access the target path normally through the symbolic link. The mount utility is the `mount` command from BusyBox (an embedded Linux toolkit), which is compiled to support file system types for external secure storage. The executable file for this `mount` command is located in the root file system and can be called before the external secure storage is mounted. A dangling state means that the underlying storage device corresponding to the target path pointed to by the symbolic link is not yet mounted, but the symbolic link itself exists as file system metadata in the root file system.

[0054] For example, let the symbolic link be Its target path is... The mount point of the external security storage is The currently mounted file systems set is Before the mounted script is executed, ,and ,at this time It is in a suspended state; after the mount script executes the mount operation, ,and , The status changes from suspended to active. The numbering order of the startup scripts ensures that during the execution phase of startup scripts with numbers lower than the mounted scripts (such as device node creation, basic network initialization, etc.), there is no access. The scripts in the above stages only perform operations within the root file system; the startup scripts with numbers greater than the mount scripts (such as kernel module loading, business application startup, etc.) are executed in the following stages. It is ready and access can proceed normally.

[0055] For example, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating a scenario of mounting an external secure storage device at startup, as provided in an embodiment of this application. Figure 4 As shown, the scenario involves the complete startup process of the vehicle driving recorder from system power-on to the completion of the external security storage mounting and entry into normal operation.

[0056] After the system powers on, it first enters Phase 1: Boot Read-Only Memory (BootROM) is loaded to execute the initial boot code. Subsequently, GSL (Generic Second-stage Loader) and U-Boot (Universal Bootloader) are executed sequentially. U-Boot loads the operating system kernel image and initializes the controller driver for the external secure memory (i.e., kernel loading). During this phase, the external secure memory is not yet mounted, and all symbolic links in the root filesystem pointing to the mount point / mnt / safemem are in a dangling state.

[0057] Then, the second phase begins: After the operating system kernel mounts the root file system, which is a compressed read-only file system (Squash File System, SquashFS), the scripts are executed sequentially according to the numerical numbers contained in their filenames (i.e., ...). Figure 4The startup scripts in the file system are executed sequentially. Specifically, the process includes the following: Startup scripts with numbers lower than the mount scripts (e.g., S00devs, S40network) are executed first. These scripts create device nodes and initialize the network. They only read from SquashFS and do not write to the root file system. These scripts do not access any symbolic link target paths pointing to the external secure storage. Next, the mount script, numbered S50safemem, is executed. It calls a mount utility located in the root file system to mount the data partition of the external secure storage to / mnt / safemem (i.e., mount the external eMMC). After successful mounting, the symbolic link changes from a dangling state to a valid state.

[0058] Then, in Phase 3, subsequent startup scripts with numbers greater than S50safemem (such as S51modules and S60app) are executed sequentially to load kernel modules and start business applications. Since the external secure storage has been mounted and the symbolic link is valid, the subsequent startup scripts can access the target path in the external secure storage through the symbolic link, and the system enters normal operation.

[0059] As can be seen in this example, by controlling the numerical order of the startup scripts, the mount script is scheduled to be executed before the script that accesses the target path of the symbolic link. This ensures that the mount operation precedes any access operation to the target path, avoiding access failure due to the symbolic link being dangling because the external secure storage is not mounted. The mount helper tool located in the root file system ensures that the mount operation can be executed before the external secure storage is mounted, without creating premature dependency on the external storage.

[0060] In one possible embodiment, the method further includes: mounting the temporary file directory generated at runtime as a memory file system before mounting the external secure storage; pre-creating file-level symbolic links in the root file system image, the file-level symbolic links pointing to fixed-function directory paths in the external secure storage, the fixed-function directory paths not changing with version changes; the file-level symbolic links and the pre-created symbolic links pointing to writable symbolic links in the root file system point to different path branches in the directory tree of the root file system, and there is no path intersection between the two; before mounting the external secure storage, the target path pointed to by the file-level symbolic links does not exist, the file-level symbolic links are in a dangling state, and the startup script does not access the target path pointed to by the file-level symbolic links before the external secure storage is mounted; after mounting the external secure storage, the variable data directory and configuration file directory that need to be persistently saved at runtime are redirected to the data partition of the external secure storage through file-level symbolic links; write operation requests initiated by the application are distributed by the operating system's virtual file system to the memory file system or the external secure storage according to the path prefix of the write operation request pointed to by the file-level symbolic links, and the read-only file system itself does not receive any write requests.

[0061] To achieve flexible writing and persistence of data during system runtime while maintaining the read-only nature of the root file system, this application proposes a write-time splitting mechanism. Specifically, during each version build, fixed-function directory entries in the root file system image are stored at fixed offsets. When switching versions, only the file content pointed to by variable-function directories is updated, without rebuilding the path structure of fixed-function directories. This ensures that the path of the fixed-function directory pointed to by file-level symbolic links does not change with version changes. Simultaneously, file-level symbolic links and symbolic links pointing to writable symbolic links are established in different subdirectory branches of the root file system directory tree. For example, file-level symbolic links are located in the / var branch, and symbolic links pointing to writable symbolic links are located in the / opt branch. They do not have the same path prefix and there is no secondary link mapping. Therefore, the resolution results of the two types of symbolic links do not overlap, avoiding errors caused by path intersections during pre-mount access.

[0062] After mounting to external secure storage, the variable data directory and configuration file directory that need to be persistently stored at runtime are redirected to the data partition of external secure storage via file-level symbolic links. Write requests initiated by the application are routed by the virtual file system to either the memory file system or external secure storage based on the path prefix pointed to by the file-level symbolic links. When the path prefix of a write request does not fall into any redirected path, the virtual file system directly rejects the write request based on the read-only attribute of the root file system, thus preventing the read-only file system itself from receiving any write requests. In this way, temporary data is guided to the memory file system, persistent data is guided to external secure storage, and the root file system remains read-only, avoiding flash memory wear and ensuring the stability of system startup and operation.

[0063] As can be seen, in this example, the collaborative use of file-level symbolic links and the memory file system enables the distribution and management of write operations, which satisfies the data persistence requirements, protects the integrity of the root file system, and improves system reliability and storage efficiency.

[0064] In one possible embodiment, the method further includes: performing an over-the-air upgrade on the system partition in the internal non-volatile flash memory using a first upgrade method, and performing an over-the-air upgrade on the second data in the external secure storage using a second upgrade method; after the external secure storage is mounted and security authentication is successful, obtaining the upgrade package, temporarily storing the upgrade package in the temporary storage area of ​​the external secure storage, and copying the upgrade package from the temporary storage area to a removable storage medium; setting a recovery mode boot flag and restarting to enter the recovery mode of the bootloader program; after completing the system partition upgrade of the internal non-volatile flash memory, exiting the recovery mode and restarting to enter the runtime environment after the bootloader program starts the operating system kernel image, activating and deploying the second data in the external secure storage from the temporary storage area; the second data is stored in the external secure storage in directories according to kernel version, with symbolic links pointing to writable symbolic links, and writable symbolic links pointing to the currently active version directory; when the second data fails, the writable symbolic links are rolled back to the currently active version directory before the switch, and the vehicle driving recorder continues to operate in basic function mode.

[0065] The first upgrade method involves performing a full partition erase and write upgrade on the system partition in the internal non-volatile flash memory through the recovery mode of the bootloader program. The second upgrade method involves performing file-level incremental updates on the second data in the external secure storage after the external secure storage has been mounted and successfully authenticated, in the runtime environment after the bootloader program starts the operating system kernel image. The recovery mode is the runtime mode in which the bootloader program does not start the operating system kernel image. The first and second upgrade methods are bound to the same upgrade package version, and the basic function mode is to retain only the driving record function.

[0066] For example, let the upgrade package be It contains NOR partition mirror sets. and external storage component set The kernel version number is The kernel module version number in the external storage component is The version binding relationship is as follows: ; Or it can be expressed as: ; That is, within the same upgrade package, the kernel version in the NOR partition image is completely identical to the kernel module version in the external storage component.

[0067] For example, please refer to Figure 5 , Figure 5 This is a schematic diagram illustrating a three-stage differentiated OTA upgrade process provided in an embodiment of this application. For example... Figure 5 As shown, the scenario involves the complete process of performing over-the-air upgrades using the same upgrade package on the system partition in the internal non-volatile flash memory and the second data in the external secure storage memory, respectively, using different upgrade methods.

[0068] Phase A is the preparation and staging phase, executed within the normal Linux environment. The system downloads the upgrade package upgrade.img from the network and stores it in the staging area of ​​external secure storage: / mnt / safemem / .ota_staging / . The upgrade package also includes a NOR partition image set. (including the new kernel) ) and the new root filesystem rootfs ( )) and external storage component set (Including the new kernel module / opt / ko / ) / and new apps / opt / app / / etc), kernel version number Kernel module version number in external storage components satisfy During this phase, no active components are modified, and the old kernel and old components remain version consistent.

[0069] Phase B is the NOR system partition upgrade phase. The system copies the upgrade package from the scratchpad to the removable storage medium (SD card), sets the recovery mode boot flag, and restarts into recovery mode (i.e.,...). Figure 5(In Recovery mode). In Recovery mode, the bootloader reads upgrade.img from the SD card, verifies the signature and cyclic redundancy check (CRC). If the verification passes, it performs a full partition erase and write upgrade on the system partition of the internal non-volatile flash memory. After successful upgrade, it clears the recovery mode boot flag and reboots. If the NOR upgrade fails, the bootloader abandons the upgrade and reverts to the normal boot process, maintaining version consistency between the old kernel and old components.

[0070] Phase C is the eMMC component activation phase, which is executed in the Linux runtime environment after the new kernel boots. The S51modules startup script detects kernel version changes and deploys the new components from the staging area to the versioned directory / opt / ko / . The system synchronously updates components in / opt / app / , / opt / ailib / , / opt / tools / , and / usr / local / lib / , and adds writable symbolic links. The pointer points to the directory of the currently active version before the switch. Update to the new version directory Old version files will not be deleted for now; they will be retained until the next successful OTA update. If the second data transfer fails, the writable symbolic link will be reverted to the directory of the currently active version before the switch. The new kernel runs together with the old modules (i.e.) Figure 5 The system uses a "new kernel + old modules" approach, allowing the car dashcam to continue operating in basic function mode, meaning that the basic driving recording function of the car dashcam remains available.

[0071] The recovery mode boot flag is stored in a miscellaneous partition of the internal non-volatile flash memory. The bootloader reads the recovery mode boot flag from this partition during startup. If the flag matches a preset value, it enters recovery mode; otherwise, it boots the operating system kernel image normally. After the writable symbolic link reverts to the directory of the currently active version before the switch, the old version files remain in external secure storage until the next successful OTA upgrade, at which point the system will clean them up.

[0072] Furthermore, the upgrade package also includes image files of the system partition in the internal non-volatile flash memory (including the bootloader partition image, kernel partition image, and root file system partition image) and the file set corresponding to the second data in the external secure storage. The kernel version within the same upgrade package matches the kernel module version in the second data. Setting the recovery mode boot flag and restarting specifically involves writing a preset flag value to a specific offset in the miscellaneous partition during normal operation. After restarting, the bootloader reads this flag value, and if it matches the preset value, it enters recovery mode. The temporary storage area in the external secure storage and the activation directory where the second data is located are independent directory paths. The temporary storage area is used to store upgrade packages that have been downloaded but not yet activated, while the activation directory is the path where the second data of the currently running version is located. The existence of the temporary storage area does not affect the normal access to the second data in the currently running version.

[0073] In one possible embodiment, a prompt message is displayed to the user before the upgrade package is copied from the staging area to the removable storage medium, prompting the user to insert the removable storage medium. After detecting that the removable storage medium has been inserted, the upgrade package is copied from the staging area to the removable storage medium.

[0074] For example, suppose the kernel version number of the currently running version is . The new kernel version number is The directory structure organized by kernel version in the external secure storage satisfies: , ; Let writable symbolic links be If it points to the currently active version directory, then the directory before the upgrade would have: ; After the upgrade package is downloaded to the temporary storage area, the second data of the new version is deployed to... Do not modify at this time. The pointer to the NOR partition. After completing the NOR partition upgrade and rebooting into the new kernel, if the new kernel and... If the module version matches, then... Depend on Updated to ,Right now: ; If any component in the second data fails to activate after the new kernel boots (e.g., a new module fails to load, or a new application fails to start), then... Revert to the directory of the currently active version before the switch, i.e.: ; At this time, the new kernel and the old module run together. Some functions that depend on the new module are unavailable, but the modules corresponding to the basic driving recording functions (speed recording, time recording, and location recording) have not changed, so they can still run normally.

[0075] As can be seen, in this example, the NOR system partition and the eMMC secondary data adopt two different upgrade methods: full partition erasure and file-level incremental update, respectively, each adapting to the characteristics of different storage media. The three-stage upgrade process (temporary storage → NOR upgrade → eMMC activation) ensures that no activated eMMC components are changed before the NOR upgrade is successful, avoiding the problem of incompatibility between the old kernel and the new components due to NOR upgrade failure. The kernel version-based directory storage and writable symbolic link rollback mechanism ensure that the system can still run basic functions in a downgraded manner when component activation fails.

[0076] In one possible embodiment, the system partition in the internal non-volatile flash memory is upgraded by performing a full partition erase / write operation via the bootloader's recovery mode. This includes: the recovery mode reading the upgrade package from the removable storage medium and verifying the integrity and signature of the upgrade package according to the upgrade signature verification key stored in the root file system; if the verification passes, the erase / write upgrade is performed; if the verification fails, the bootloader remains in recovery mode and outputs a waiting message; if the system partition upgrade fails, the bootloader remains bootable and can re-enter recovery mode; if the removable storage medium remains valid, the upgrade package is reread from the removable storage medium for retry; if the removable storage medium fails, the bootloader remains in recovery mode and outputs a waiting message.

[0077] The upgrade signature verification key is stored in the root file system, which is located in the internal non-volatile flash memory. In recovery mode, although the root file system is not mounted as a runtime file system by the kernel, the bootloader directly reads the public key data stored in the root file system partition through a predefined flash physical address offset. That is, the bootloader accesses the root file system partition in the internal flash memory to extract the public key file content through raw block read, without mounting any file system or relying on external storage drivers or file systems. The removable storage medium is an SD card. In recovery mode, the upgrade package file under a fixed path on the SD card is directly read through the SDIO interface driver, without relying on the eMMC controller driver or security authentication process of the external secure storage. In recovery mode, the external secure storage may not have completed security authentication and unlocking. Therefore, the upgrade package is transmitted through the removable storage medium rather than being read directly from the external secure storage.

[0078] In recovery mode, after reading the upgrade package from the removable storage medium, the SD card is only used as the transmission medium for the upgrade package in recovery mode. All driving record data captured by the vehicle driving recorder is stored in an external secure storage device, and the SD card is not used as the storage medium for driving record data.

[0079] In one possible embodiment, in recovery mode, the bootloader program directly accesses the system partition storing the root file system by reading raw blocks through a predefined flash physical address offset, extracts the upgrade signature verification key, without mounting any file system and without relying on the driver or file system of the external secure storage; recovery mode directly reads the upgrade package in the removable storage medium through the interface driver corresponding to the removable storage medium, and uses the upgrade signature verification key to perform integrity and signature verification on the upgrade package, without relying on the controller driver and security authentication process of the external secure storage medium.

[0080] To implement the aforementioned raw block reading method, the bootloader program pre-stores the physical address offset of the storage block containing the upgrade signature verification key within the system partition. In recovery mode, the bootloader program directly sends a command to the flash controller to read the key data from the raw storage block of the system partition at the physical address. The entire process does not involve parsing or mounting the file system layer, thus obtaining the key without mounting any file system. Furthermore, since the key is stored in the system partition of the internal non-volatile flash memory, key reading does not involve external secure storage, therefore it does not rely on the driver or file system of external secure storage, nor on its controller driver and security authentication process.

[0081] After obtaining the upgrade signature verification key, the recovery mode directly reads the upgrade package from the removable storage medium via the standard interface driver corresponding to the removable storage medium. This reading process does not rely on the controller driver or security authentication process of the external secure storage. Subsequently, the bootloader program uses the extracted upgrade signature verification key to verify the integrity and signature of the upgrade package. This verification process also does not rely on the driver, file system, controller driver, or security authentication process of the external secure storage. By combining the original block read key with the standard interface driver to read the upgrade package, the recovery mode can still independently complete the acquisition and verification of the upgrade package even when the external secure storage is completely unavailable or unauthenticated.

[0082] As can be seen, in this example, by reading the upgrade package through the original block read key and the standard interface driver, the recovery mode and the external secure storage are completely decoupled, which enhances the reliability and fault tolerance of the upgrade process. Even if the external secure storage fails or is not connected, the system can independently complete the upgrade package verification.

[0083] In one possible embodiment, when the system partition upgrade fails, after the bootloader program remains bootable and can re-enter the recovery mode, the method further includes: when the upgrade of the partition where the bootloader program is located fails, the checksum of the bootloader program does not match, and the BootROM or primary bootloader detects the checksum mismatch and automatically enters the recovery mode, waiting to re-burn the bootloader program through a removable storage medium or communication interface.

[0084] Specifically, the bootloader program partition is checked by BootROM or the primary bootloader. When the upgrade fails and the bootloader program is damaged, it automatically enters recovery mode, ensuring that the device can still be recovered in the event of a bootloader partition upgrade failure, and avoiding the device being completely bricked due to bootloader damage.

[0085] The upgrade package verification process in recovery mode satisfies the following state transition relationship: Let the upgrade package be... Its digital signature is The public key stored in the root file system is The verification function is .

[0086] Furthermore, after the recovery mode is started, it first checks whether the removable storage medium exists; if it does, it reads it. It calculates the integrity check value; if the integrity check fails, it is determined that... Damage; Signature verification is performed after integrity is verified. If the verification passes (returns 1), the erase / write upgrade is performed; if the verification fails (returns 0), the system remains in recovery mode. Let the erase / write operation function be... Its return value is {success, failure}. If the recovery mode fails, it will not continue to erase and write subsequent partitions, but will remain in recovery mode and wait for user intervention. If a power outage occurs during the erasure process, the boot program will detect that the system partition is incomplete when the system is powered on again, automatically re-enter recovery mode and retry the above process.

[0087] As can be seen in this example, by storing the signature verification key in the root file system and allowing the bootloader to access it directly via block read, the dependence on external storage in recovery mode is eliminated; by storing the upgrade package on the SD card instead of external secure storage, read obstacles caused by incomplete security authentication of external secure storage in recovery mode are avoided; when verification fails or the media fails, the bootloader remains in recovery mode and outputs a waiting message, providing the user with a clear indication of the device status; when the system partition upgrade fails, the bootloader remains bootable, ensuring the recoverability of the device.

[0088] In one possible embodiment, the method further includes: before mounting the external secure storage, invoking a security authentication tool located in the root file system to perform security authentication and unlocking. The security authentication tool transfers the verification ciphertext between the system-on-a-chip and the security device. The verification key is stored inside the security device and is not held by the system-on-a-chip, so as to perform security authentication and unlocking of the external secure storage through the security device; after successful authentication, the external secure storage is mounted; if authentication fails, it runs in a restricted mode. In the restricted mode, the authentication failure error message is output through the basic output driver located in the root file system, and only the first data in the internal non-volatile flash memory is available, business services that depend on the external secure storage are stopped, no write operations are performed on the data partition of the external secure storage, and over-the-air upgrade operations are prohibited.

[0089] The verification key is stored internally within the secure device and cannot be read from external interfaces, thus preventing its extraction and tampering at the hardware level. The security authentication tool is compiled using static linking and does not depend on any dynamic libraries or loadable kernel modules stored in external secure storage. The authentication process relies only on the statically linked executable file within the root file system and the interface driver for communicating with the secure device. This interface driver is compiled internally into the operating system kernel image, and its device node is created by the kernel at the initial stage of system startup. The basic output driver is located in the root file system and outputs error information to the serial port and screen through the serial port driver and display driver, respectively. Both the serial port driver and display driver are compiled internally into the kernel and do not depend on any resources on external secure storage, ensuring that error information can be output normally in restricted mode.

[0090] The authentication protocol between the security authentication tool and the security device is a challenge-response protocol. The security device is in a locked state by default after power-on, and its command mode register only accepts authentication commands and rejects any read / write access other than authentication commands. Let the access control state machine of the security device be... Its state space is: .

[0091] Furthermore, prior to the certification process, the security device status is as follows: At this point, all data read and write commands are rejected. The security authentication tool generates a random challenge value. It is then sent to the security device, which uses the authentication key stored within it. Question value Perform cryptographic operations to obtain the response value It then returns the challenge value to the SoC; the security authentication tool is only responsible for transferring the challenge value between the SoC and the security device. and response value It does not participate in key calculations, and the SoC does not hold the verification key. The safety device will internally respond to the value. With its stored verification key Calculated expected response value Perform a comparison, if If so, the authentication is confirmed to be successful.

[0092] Specifically, certification requires meeting the following criteria: internal comparison response value of the security device. Compared with expected response value ,like If authentication is successful, the access control state machine of the security device switches to [the next state]. Otherwise, it will be counted as a failure, and the cumulative count will reach a threshold. Switch to The host can retry authentication before reaching the threshold. Upon successful authentication, the security device state switches to UNLOCKED, and the host gains full data read and write permissions. The entire authentication process is executed no later than the mounting operation of the external secure storage; the mounting operation can only be performed after the authentication state machine reaches the UNLOCKED state.

[0093] As can be seen, in this example, by storing the verification key inside the secure device and preventing it from being read through an external interface, the confidentiality, integrity, and immutability of the key are guaranteed at the hardware level. By statically linking and storing the security authentication tool in the root file system, the authentication process can be executed independently before the external secure storage is mounted, without creating any premature dependence on any data on the storage. Through the precisely defined sub-behaviors in the restricted mode, it is ensured that the device can still output diagnostic information and maintain basic recording capabilities when authentication fails, preventing the device from becoming completely unusable due to external storage authentication anomalies.

[0094] In other possible embodiments, the capacity of the internal non-volatile flash memory can be selected to a larger capacity according to the actual system requirements, so as to improve the capacity margin of each partition; the root file system can also replace the compressed read-only file system with an initial memory file system; the interface of the external secure storage can also be replaced with a secure digital input / output interface or a general flash storage interface; when write protection is not required, the security authentication process can be tailored according to the actual security requirements.

[0095] As can be seen, in this embodiment, by using the criticality classification method, the system content is divided into a critical startup level and a non-critical startup level. The former is retained in the internal non-volatile flash memory, while the latter is migrated to the external secure storage. This significantly reduces the system partition capacity of the internal non-volatile flash memory, thereby reducing chip selection costs. By simultaneously carrying the second data and driving record data in the external secure storage, the roles of system storage and data storage are unified, avoiding the need for additional storage chips. By storing the verification key inside the secure device and preventing it from being read through the external interface, the confidentiality and immutability of the key are guaranteed at the hardware level. By storing the security authentication tool in the root file system, the early dependence of the authentication process on data on the external storage is eliminated, ensuring that authentication can be executed independently before the external storage is mounted. The precise definition of the restricted mode when authentication fails ensures that the device can still output diagnostic information and maintain basic recording capabilities when the external storage is unavailable, preventing the device from becoming completely unusable.

[0096] The following are embodiments of the apparatus of this application. These embodiments of the apparatus and the embodiments of the method of this application belong to the same concept and are used to execute the methods described in the embodiments of this application. For ease of explanation, only the parts related to the apparatus embodiments of this application are shown in the embodiments of this application. For specific technical details not disclosed, please refer to the description of the embodiments of the method of this application, which will not be repeated here.

[0097] This application provides a system partition compression device for a vehicle driving recorder, used to perform the steps in the above-described system partition compression method for a vehicle driving recorder. The system partition compression device for a vehicle driving recorder in this application may include modules corresponding to the respective steps.

[0098] This application embodiment can divide the system partitioning compression device of the vehicle driving recorder into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. The module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0099] When dividing each function into modules according to its corresponding function. Figure 6 This is a functional unit block diagram of a system partition compression device for a vehicle driving recorder provided in an embodiment of this application; the system partition compression device for the vehicle driving recorder is applied to... Figure 1The vehicle driving recorder storage system 10 is shown in Figure 6. As shown, the system partition compression device 60 of the vehicle driving recorder includes a content acquisition unit 601, used to acquire system data of the vehicle driving recorder, which includes internal non-volatile flash memory and external secure storage; a content partitioning unit 602, used to divide the system data into first data and second data according to a preset judgment standard, the preset judgment standard being used to characterize the moment when the external secure storage can be mounted; a content compression unit 603, used to perform compression processing on the first data, generating a compressed system partition image, so that the capacity of the system partition in the internal non-volatile flash memory used to store the first data is reduced to a preset target value; and an architecture construction unit 604, used to deploy the second data to the external secure storage, and construct a target partition layout of the internal non-volatile flash memory according to the system partition image, each partition in the target partition layout being used to store the corresponding part of the first data.

[0100] In one possible embodiment, the first data includes a bootloader program, an operating system kernel image, and a root file system; the compression process includes at least: constructing the root file system as a compressed read-only file system, and embedding the environment variable data required for the bootloader program to run in the bootloader program's binary file during compilation, thereby eliminating the need for a separate environment variable partition; after performing the compression process, if the system partition capacity is still not reduced to a preset target value, then at least one of the remaining compression measures is continued to be performed, and the system partition capacity is detected until it is reduced to the preset target value. The remaining compression measures include: changing the compression method of the operating system kernel image from a first compression ratio to a second compression ratio, reducing the capacity of the partition where the bootloader program is located and the miscellaneous partition in the internal non-volatile flash memory, and removing the independent parameter partition in the internal non-volatile flash memory. The second compression ratio is higher than the first compression ratio.

[0101] In one possible embodiment, regarding the deployment of the second data to an external secure storage, the architecture building unit 604 is specifically configured to: configure the external secure storage to simultaneously hold the second data and the driving record data captured by the vehicle driving recorder; store the system parameters that need to be accessed after the external secure storage is mounted in the data partition of the external secure storage; pre-create symbolic links in the image of the root file system, the symbolic links pointing to writable symbolic links in the external secure storage, the writable symbolic links being used to switch from the currently active version directory to the new version file directory when the system version of the vehicle driving recorder is upgraded; mount the external secure storage; after the external secure storage is mounted, the symbolic links redirect access requests to the target path in the currently active version directory through the writable symbolic links.

[0102] In one possible embodiment, regarding mounting the external secure storage, the architecture building unit 604 is specifically configured to: before mounting the external secure storage, the target path ultimately pointed to by the symbolic link via the writable symbolic link does not exist, the symbolic link is in a dangling state, and the mount point of the external secure storage is an empty directory before mounting; the startup script is executed in a preset numbered order, wherein the mount script for mounting the external secure storage is executed before all subsequent scripts that may access the target path pointed to by the symbolic link; the mount script calls the mount assist tool located in the root file system to perform the mounting of the external secure storage; and the startup script does not access the target path pointed to by the symbolic link before the external secure storage is mounted.

[0103] In one possible embodiment, the architecture building unit 604 is further configured to: mount the temporary file directory generated at runtime as a memory file system before mounting the external secure storage; pre-build file-level symbolic links in the root file system image, the file-level symbolic links pointing to fixed-function directory paths in the external secure storage, the fixed-function directory paths not changing with version changes; the file-level symbolic links and the pre-built symbolic links pointing to writable symbolic links in the root file system point to different path branches in the directory tree of the root file system, and there is no path intersection between the two; before mounting the external secure storage, the target path pointed to by the file-level symbolic links does not exist, the file-level symbolic links are in a dangling state, and the startup script does not access the target path pointed to by the file-level symbolic links before the external secure storage is mounted; after mounting the external secure storage, the variable data directory and configuration file directory that need to be persistently saved at runtime are redirected to the data partition of the external secure storage through file-level symbolic links; write operation requests initiated by the application are distributed by the operating system's virtual file system to the memory file system or the external secure storage according to the path prefix of the write operation request pointed to by the file-level symbolic links, and the read-only file system itself does not receive any write requests.

[0104] In one possible embodiment, the architecture building unit 604 is further configured to: perform an over-the-air upgrade on the system partition in the internal non-volatile flash memory using a first upgrade method, and perform an over-the-air upgrade on the second data in the external secure storage using a second upgrade method. The first upgrade method involves performing a full partition erase / write upgrade on the system partition in the internal non-volatile flash memory through the recovery mode of the bootloader program. The second upgrade method involves performing a file-level incremental update on the second data in the external secure storage after the external secure storage has been mounted and security authentication has been successful, in the runtime environment after the bootloader program starts the operating system kernel image. After the external secure storage has been mounted and security authentication has been successful, an upgrade package is obtained, and the upgrade package is temporarily stored in the temporary storage area of ​​the external secure storage, and the upgrade package is copied from the temporary storage area to a removable storage medium. Furthermore, it is configured to: The system is restarted after setting the recovery mode boot flag, entering the bootloader's recovery mode. Recovery mode is the running mode where the bootloader does not boot the operating system kernel image. After completing the system partition upgrade of the internal non-volatile flash memory, the system exits recovery mode and restarts to enter the running environment after the bootloader boots the operating system kernel image. The second data in the external secure storage is activated and deployed from the temporary storage area. The first upgrade method and the second upgrade method are bound to the same upgrade package version. The second data is stored in the external secure storage in directories according to the kernel version, with symbolic links pointing to writable symbolic links, which in turn point to the currently activated version directory. When the activation of the second data fails, the writable symbolic links are rolled back to the currently activated version directory before the switch, and the vehicle driving recorder continues to run in basic function mode, which only retains the driving record function.

[0105] In one possible embodiment, in terms of performing a full partition erase / write upgrade on the system partition in the internal non-volatile flash memory via the bootloader's recovery mode, the architecture building unit 604 is further configured to: read the upgrade package from the removable storage medium in recovery mode, and verify the integrity and signature of the upgrade package according to the upgrade signature verification key stored in the root file system; if the verification passes, perform the erase / write upgrade; if the verification fails, the bootloader remains in recovery mode and outputs a waiting message; if the system partition upgrade fails, the bootloader remains bootable and can re-enter recovery mode, and if the removable storage medium remains valid, reread the upgrade package from the removable storage medium for retry; if the removable storage medium fails, the bootloader remains in recovery mode and outputs a waiting message.

[0106] In one possible embodiment, in recovery mode, the bootloader program directly accesses the system partition storing the root file system by reading raw blocks through a predefined flash physical address offset, extracts the upgrade signature verification key, without mounting any file system and without relying on the driver or file system of the external secure storage; recovery mode directly reads the upgrade package in the removable storage medium through the interface driver corresponding to the removable storage medium, and uses the upgrade signature verification key to perform integrity and signature verification on the upgrade package, without relying on the controller driver and security authentication process of the external secure storage medium.

[0107] In one possible embodiment, the architecture building unit 604 is further configured to: before mounting the external secure storage, invoke a security authentication tool located in the root file system to perform security authentication and unlocking. The security authentication tool transfers the verification ciphertext between the system-on-a-chip and the security device. The verification key is stored inside the security device and is not held by the system-on-a-chip, so as to perform security authentication and unlocking of the external secure storage through the security device. The security device is an independent security chip, and the verification key cannot be read out through an external interface. After successful authentication, the external secure storage is mounted. If authentication fails, it runs in a restricted mode. In the restricted mode, the authentication failure error message is output through the basic output driver located in the root file system, and only the first data in the internal non-volatile flash memory is available. Service services that depend on the external secure storage are stopped, no write operations are performed on the data partition of the external secure storage, and over-the-air upgrade operations are prohibited.

[0108] When using integrated units, such as Figure 7 As shown, Figure 7 This is a functional unit block diagram of another vehicle driving recorder system partition compression device provided in this application embodiment. Figure 7 The system partitioning compression device 60 of the vehicle driving recorder includes a processing module 702 and a communication module 701. The processing module 702 controls and manages the operation of the system partitioning compression device 60, such as the steps of the content acquisition unit 601, content partitioning unit 602, content compression unit 603, and architecture construction unit 604, and / or other processes for executing the techniques described herein. The communication module 701 supports interaction between the system partitioning compression device and other devices. Figure 7 As shown, the system partition compression device of the vehicle driving recorder may include a storage module 703, which is used to store the program code and data of the system partition compression device of the vehicle driving recorder.

[0109] The processing module 702 can be a processor or processing module, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication module 701 can be a transceiver, RF circuitry, or a communication interface, etc. The storage module 703 can be a memory.

[0110] All relevant content in each scenario involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here. The system partition compression device 60 of the above-mentioned vehicle driving recorder can perform the above-mentioned... Figure 2 The system partition compression method of the car driving recorder is shown.

[0111] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions according to the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0112] Figure 8 This is a structural block diagram of a vehicle driving recorder provided in an embodiment of this application. Figure 8As shown, the vehicle driving recorder 80 may include one or more of the following components: a processor 801 and a memory 802 coupled to the processor 801, wherein the memory 802 may store one or more computer programs 803, and the one or more computer programs 803 may be configured to implement the methods described in the above embodiments when executed by one or more processors 801. The vehicle driving recorder 80 here may be a conventional driving recorder known in the art, such as a commercially available driving recorder with video recording, storage, and communication functions.

[0113] The processor 801 may include one or more processing cores. The processor 801 connects to various parts of the vehicle driving recorder 80 using various interfaces and lines, and performs various functions and processes data of the vehicle driving recorder 80 by running or executing instructions, programs, code sets, or instruction sets stored in the memory 802, and by calling data stored in the memory 802. Optionally, the processor 801 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 801 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 801 and may be implemented separately through a communication chip.

[0114] The memory 802 may include random access memory (RAM) or read-only memory (ROM). The memory 802 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 802 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described above. The data storage area may also store data created by the vehicle driving recorder 80 during use.

[0115] It is understood that the vehicle driving recorder 80 may include more or fewer structural elements than those shown in the above block diagram, and this is not limited here.

[0116] This application also provides a computer storage medium storing a computer program / instructions thereon, which, when executed by a processor, implements some or all of the steps of any of the methods described in the above method embodiments.

[0117] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0118] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0119] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, and systems can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and there may be other division methods in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0121] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can be physically included separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0122] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute some steps of the methods of the various embodiments of this application. The aforementioned storage medium includes: a USB flash drive, a portable hard disk, a magnetic disk, an optical disk, volatile memory, or non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM), etc., which are various media capable of storing program code.

[0123] While this application discloses the above information, it is not limited thereto. Any person skilled in the art can easily conceive of variations or substitutions without departing from the spirit and scope of this application, and can make various alterations and modifications, including combinations of the different functions and implementation steps described above, as well as software and hardware implementation methods, all of which are within the protection scope of this application.

Claims

1. A system partition compression method for a vehicle driving recorder, characterized in that, include: The system acquires data from a vehicle driving recorder, which includes an internal non-volatile flash memory and an external secure memory. According to a preset judgment criterion, the system data is divided into first data and second data, and the preset judgment criterion is used to characterize the moment when the external secure storage can be mounted. The first data is compressed to generate a compressed system partition image, so that the capacity of the system partition used to store the first data in the internal non-volatile flash memory is reduced to a preset target value. For the second data, it is deployed to the external secure storage, and a target partition layout of the internal non-volatile flash memory is constructed according to the system partition image. Each partition in the target partition layout is used to store the corresponding part of the first data.

2. The method according to claim 1, characterized in that, The first data includes the bootloader, the operating system kernel image, and the root file system; The compression process includes at least: constructing the root file system as a compressed read-only file system, and embedding the environment variable data required for the boot program to run into the binary file of the boot program during compilation, thereby eliminating the need for a separate environment variable partition; After performing the compression process, if the system partition capacity is still not reduced to the preset target value, then at least one of the remaining compression measures is continued to be performed, and the system partition capacity is detected until it is reduced to the preset target value. The remaining compression measures include: changing the compression method of the operating system kernel image from a first compression ratio to a second compression ratio, reducing the capacity of the partition where the boot program is located and the miscellaneous partition in the internal non-volatile flash memory, and removing the independent parameter partition in the internal non-volatile flash memory. The second compression ratio is higher than the first compression ratio.

3. The method according to claim 2, characterized in that, The step of deploying the second data to the external secure storage includes: The external secure storage device is configured to simultaneously hold the second data and the driving record data captured by the vehicle driving recorder; The system parameters that need to be accessed after the external secure storage is mounted are stored in the data partition of the external secure storage; Symbolic links are pre-built in the image of the root file system. These symbolic links point to writable symbolic links in the external secure storage. The writable symbolic links are used to switch from the currently active version directory to the new version file directory when the system version of the vehicle driving recorder is upgraded. Mount the external secure storage device; After the external secure storage is mounted, the symbolic link redirects access requests to the target path in the currently active version directory via the writable symbolic link.

4. The method according to claim 3, characterized in that, The mounting of the external secure storage includes: Before the external secure storage is mounted, the target path that the symbolic link ultimately points to via the writable symbolic link does not exist, the symbolic link is in a dangling state, and the mount point of the external secure storage is an empty directory before mounting. The startup scripts are executed in a preset numbered order, wherein the mounting script for mounting the external secure storage is executed before all subsequent scripts that may access the target path pointed to by the symbolic link; The mount script calls the mount auxiliary tool located in the root file system to execute the mount of the external secure storage; The startup script does not access the target path pointed to by the symbolic link until the external secure storage is mounted.

5. The method according to claim 3, characterized in that, The method further includes: Before mounting the external secure storage, the temporary file directory generated during runtime is mounted using a memory file system. In the root file system image, file-level symbolic links are pre-built. These file-level symbolic links point to fixed-function directory paths in the external secure storage. These fixed-function directory paths do not change with version changes. The file-level symbolic links and the pre-built symbolic links in the root file system that point to the writable symbolic links point to different path branches in the directory tree of the root file system, and there is no path intersection between them. Before the external secure storage is mounted, the target path pointed to by the file-level symbolic link does not exist, and the file-level symbolic link is in a dangling state. The startup script does not access the target path pointed to by the file-level symbolic link before the external secure storage is mounted. After the external secure storage is mounted, the variable data directory and configuration file directory that need to be persistently saved at runtime are redirected to the data partition of the external secure storage through the file-level symbolic links; Write requests initiated by the application are routed by the operating system's virtual file system to the memory file system or the external secure storage according to the path prefix of the file-level symbolic link. The read-only file system itself does not receive any write requests.

6. The method according to claim 3, characterized in that, The method further includes: The system partition in the internal non-volatile flash memory is upgraded over the air using a first upgrade method, and the second data in the external secure storage is upgraded over the air using a second upgrade method. The first upgrade method is to perform a full partition erase and write upgrade on the system partition in the internal non-volatile flash memory through the recovery mode of the boot program. The second upgrade method is to perform a file-level incremental update on the second data in the external secure storage after the external secure storage has been mounted and security authentication has been successful, in the runtime environment after the boot program starts the operating system kernel image. After the external secure storage is mounted and security authentication is successful, the upgrade package is obtained, and the upgrade package is temporarily stored in the temporary storage area of ​​the external secure storage, and the upgrade package is copied from the temporary storage area to the removable storage medium; and, the recovery mode boot flag is set and the system restarts to enter the recovery mode of the boot program, which is the running mode in which the boot program does not start the operating system kernel image; After completing the system partition upgrade of the internal non-volatile flash memory, exit the recovery mode and restart to enter the runtime environment after the boot program starts the operating system kernel image. Activate and deploy the second data in the external secure storage from the temporary storage area. The first upgrade method and the second upgrade method are bound to the same upgrade package version. The second data is stored in the external secure memory in directories according to kernel version. The symbolic link points to the writable symbolic link, which points to the currently active version directory. When the activation of the second data fails, the writable symbolic link is rolled back to the currently active version directory before the switch, and the vehicle driving recorder continues to operate in the basic function mode, which only retains the driving record function.

7. The method according to claim 6, characterized in that, The step of performing a full partition erase and upgrade on the system partition in the internal non-volatile flash memory through the recovery mode of the bootloader program includes: The recovery mode reads the upgrade package from the removable storage medium and verifies the integrity and signature of the upgrade package according to the upgrade signature verification key stored in the root file system. After the verification is successful, the erase and write upgrade is performed. When the verification fails, the bootloader program remains in recovery mode and outputs a waiting message; When the system partition upgrade fails, the bootloader remains bootable and can re-enter the recovery mode. If the removable storage medium remains valid, the upgrade package is reread from the removable storage medium for retry. When the removable storage medium fails, the bootloader program remains in recovery mode and outputs a waiting message.

8. The method according to claim 7, characterized in that, In the recovery mode, the bootloader program directly accesses the system partition storing the root file system by reading raw blocks through a predefined flash physical address offset, and extracts the upgrade signature verification key without mounting any file system and without relying on the driver or file system of the external secure storage. The recovery mode directly reads the upgrade package from the removable storage medium through the interface driver corresponding to the removable storage medium, and uses the upgrade signature verification key to perform integrity and signature verification on the upgrade package, without relying on the controller driver and security authentication process of the external secure storage.

9. The method according to claim 3, characterized in that, The method further includes: Before mounting the external secure storage, a security authentication tool located in the root file system is invoked to perform security authentication and unlocking. The security authentication tool transfers the verification ciphertext between the system-on-a-chip and the security device. The verification key is stored inside the security device and the system-on-a-chip does not hold the verification key. This allows the external secure storage to be securely authenticated and unlocked through the security device. The security device is an independent security chip and the verification key cannot be read out through an external interface. After successful authentication, the external secure storage device is mounted. When authentication fails, the system operates in a restricted mode. In this restricted mode, the authentication failure error message is output through the basic output driver located in the root file system, and only the first data in the internal non-volatile flash memory is available. Service services that depend on the external secure storage are stopped, no write operations are performed on the data partition of the external secure storage, and over-the-air upgrade operations are prohibited.

10. A system partitioning compression device for a vehicle driving recorder, characterized in that, include: The content acquisition unit is used to acquire system data from the vehicle driving recorder, which includes an internal non-volatile flash memory and an external secure memory. The content partitioning unit is used to divide the system data into first data and second data according to a preset judgment standard, wherein the preset judgment standard is used to characterize the moment when the external secure storage can be mounted. The content compression unit is used to perform compression processing on the first data to generate a compressed system partition image, so that the capacity of the system partition used to store the first data in the internal non-volatile flash memory is reduced to a preset target value. An architecture building unit is used to deploy the second data to the external secure storage and to build a target partition layout for the internal non-volatile flash memory based on the system partition image, wherein each partition in the target partition layout is used to store the corresponding part of the first data.

11. A vehicle driving recorder, characterized in that, The method includes a processor, a memory, a communication interface, and one or more programs, said programs being stored in the memory and configured to be executed by the processor, said programs including instructions for performing the steps of the method as claimed in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, A computer program for storing electronic data interchange is provided, wherein the computer program causes a computer to perform the method as described in any one of claims 1-9.

Images