Cross-system system file updating method, system-on-chip and equipment

Abstract

The embodiment of the invention provides a cross-system system file updating method, a system-on-chip and equipment, and the method comprises the steps: enabling a client system to enter an engineering mode, and enabling the client system to write a to-be-updated system file under a USB interface directory into a shared file space of the client system and a host system; the host system regularly polls whether a to-be-updated system file exists in the shared file space or not; when the system file to be updated exists, the host system writes the system file into the system partition and modifies the state of the system file; the client system determines a result of the operation based on the state of the system file. According to the scheme, the existing shared file space is reused, cross-system instruction transmission can be completed without a real-time communication channel through the polling mechanism and the state change of the system file, the development requirement of a cross-system communication protocol is avoided, and the development cost is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a cross-system system file update method, system-on-a-chip, and device. Background Technology

[0002] With the increasing intelligence of automobiles and the increasing complexity of electronic and electrical architectures, modern vehicle infotainment systems typically adopt a multi-system architecture. For example, a host system and a client system run on a system-on-a-chip (SoC). The host system is, for example, the QNX system (also known as the Neutrino Real-Time Operating System), and the client system is, for example, the Android system.

[0003] During the development, debugging, and production phases, the vehicle infotainment system requires system configuration updates. These updates typically involve cross-system collaboration (such as between the host system and client systems), including operations such as reading and burning system image files. In related technologies, burning image files usually relies on complex communication links, resulting in low operational efficiency and high development complexity, thus increasing development costs. Summary of the Invention

[0004] This application provides a cross-system system file update method, system-on-a-chip, and device to reduce development costs.

[0005] In a first aspect, embodiments of this application provide a cross-system system file update method, applied to a system-on-a-chip (SoC), on which a host system and a client system run. The method includes: the client system entering engineering mode; the client system writing the system file to be updated from the USB interface directory into a shared file space between the client system and the host system, wherein the system file is an image file used to control the security functions of the SoC; the host system periodically polling the shared file space to see if the system file to be updated exists; when the system file to be updated exists, the host system writes the system file to the system partition and modifies the status of the system file; and the client system determining the result of the operation based on the status of the system file.

[0006] In one possible implementation, after the client system enters engineering mode, the method further includes: the client system determining the type of the system file to be updated in the USB interface directory; the client system determining the fuse status of the SOC; the client system providing corresponding security function operation buttons based on the type of the system file and the fuse status of the SOC; the client system controlling the security function operation buttons to be operable; and when the client system receives a click event on the security function operation button, executing the step of the client system writing the system file to be updated in the USB interface directory into the shared file space between the client system and the host system.

[0007] In one possible implementation, the client system provides corresponding security function operation buttons based on the type of the system file and the fuse status of the SOC. This includes: if the client system determines that the system file is an image file used to control the enabling of the Secure Boot function of the SOC, and determines that the fuse status of the SOC is unfuse, then the client system provides an operation button for enabling the Secure Boot function.

[0008] In one possible implementation, the client system provides corresponding security function operation buttons based on the type of the system file and the fuse status of the SOC. For example, if the system file is an image file used to enable the security debugging function, and the fuse status of the SOC is determined to be in the fused state, then the client system provides an operation button for enabling the security debugging function.

[0009] In one possible implementation, the host system performs the operation of writing system files to the system partition and modifies the status of the system files, including: the host system writes the system files to the system partition; if the writing is successful, the system file is deleted or a successful writing identifier is added to the name of the system file; if the writing fails, a failed writing identifier is added to the name of the system file.

[0010] In one possible implementation, the client system determines the result of the operation based on the status of the system file, including: if the client system detects that the system file has been deleted or the name of the system file contains a successful write identifier, then the write operation is determined to be successful; if the client system detects that the name of the system file contains a failed write identifier, then the write operation is determined to be failed.

[0011] In one possible implementation, before the host system writes the system file to the system partition, the method further includes: the host system determining whether the conditions for the write operation are met, wherein the conditions for the write operation include the host system not entering a low-power mode; or, the host system detecting that the system file has not been written to by the system identifier; if the conditions are met, then the operation of writing the system file to the system partition is performed.

[0012] Secondly, embodiments of this application provide a system-on-a-chip (SoC) on which a host system and a client system run. When the client system enters engineering mode, it writes the system file to be updated from the USB interface directory into a shared file space between the client system and the host system. The system file is an image file used to control the SOC security functions. The host system periodically polls the shared file space to see if the system file to be updated exists. When the system file to be updated exists, the host system writes the system file to the system partition and modifies the status of the system file. The client system determines the result of the operation based on the status of the system file.

[0013] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the above method.

[0014] The cross-system system file update method, system-on-a-chip, and device provided in this application include: a client system entering engineering mode; the client system writing the system file to be updated from the USB interface directory into a shared file space between the client system and the host system; the host system periodically polling the shared file space to see if the system file to be updated exists; when the system file to be updated exists, the host system writes the system file to the system partition and modifies the status of the system file; the client system determines the result of the operation based on the status of the system file. This application's solution reuses the existing shared file space and, through a polling mechanism and changes in the status of the system file, completes cross-system instruction transmission without a real-time communication channel, avoiding the need for developing cross-system communication protocols and reducing development costs. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] Figure 1 A flowchart illustrating the cross-system file update method provided in this application;

[0017] Figure 2 A flowchart illustrating the cross-system file update method provided in this application;

[0018] Figure 3 The architecture diagram of the multiple systems provided in this application;

[0019] Figure 4 A flowchart illustrating the cross-system file update method provided in this application;

[0020] Figure 5A flowchart illustrating the cross-system file update method provided in this application;

[0021] Figure 6 A schematic diagram of the structure of a cross-system system-on-a-chip provided in this application;

[0022] Figure 7 A schematic diagram of the structure of the electronic device provided in this application.

[0023] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0025] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning. In addition, the terms "comprising" and "having," and any variations thereof, are intended to be omnipresent but not exclusive. For example, a product or device that comprises a series of components is not necessarily limited to those components that are explicitly listed, but may include other components that are not explicitly listed or that are inherent to such product or device.

[0026] The following disclosure provides many different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the invention. Furthermore, reference numerals and / or letters may be repeated in different examples; such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed. In addition, examples of various specific processes and materials are provided in this invention, but those skilled in the art will recognize the application of other processes and / or the use of other materials.

[0027] In current automotive electronic systems, safety function switches are set up to enable, disable, or configure the system's safety protection mechanisms to ensure system safety. For example, Secure Boot is a technology used to protect the computer system startup process, aiming to ensure that the device loads only verified and authorized software during startup.

[0028] Security function switching operations during system updates may include the following scenarios: QTD (QNX TrustedDisk) in the QNX system is a security mechanism used to protect the storage area of ​​the QNX operating system. When the system loads the QTD disk, it verifies whether the data has been tampered with, thereby selectively rejecting illegal software programs and data.

[0029] In Android virtual machines running on the QNX virtualization platform, QVB (Qualcomm Verity Boot) is a secure boot mechanism based on a hardware root of trust, designed to ensure that the Android virtual machine's boot image has not been tampered with. QVB verifies the integrity of the boot image file by checking its hash value and prevents the system from booting if an anomaly is detected.

[0030] eFuse is a hardware-level security mechanism and an irreversible security locking strategy. It typically relies on hardware eFuse to permanently change the system's security state. Once triggered or burned out, it permanently changes the system's state to prevent unauthorized changes or updates to the system.

[0031] Both QTD and QVB can selectively enable or disable the verification function by updating a system image file. As long as the distribution path of the image file used to disable this security function is guaranteed, the security of the released system software can be ensured.

[0032] When performing cross-system security function switching operations involving a System-on-Chip (SoC), cross-system collaboration (such as between the host system and the client system) is required, involving reading, writing, and status feedback of system files. However, related technologies have significant limitations in achieving this collaboration.

[0033] For example, the solution of burning system files based on the Fastboot interface burns system files from external devices to the target system via the Fastboot protocol. However, it depends on the external environment and hardware / software interfaces. In real-vehicle testing scenarios, it requires disassembling the car's infotainment system, which greatly limits its application scenarios. In addition, this solution is not suitable for mass production versions because the interface is usually disabled in official versions.

[0034] For example, embedding system files into the host system and triggering security function switches via local commands is a simple method, but it can lead to security problems. Attackers may use the embedded system files to disable the corresponding security function switches. This method can only be used temporarily during the development phase, and the security risks are greater when used in the official upgrade version.

[0035] For example, a solution based on bridging a Universal Serial Bus (USB) storage device to the host system uses a bridging driver to connect the client system's USB interface to the host system, read system files from the USB flash drive, and burn them. However, this requires the development of an additional USB bridging driver, increasing system complexity and development costs.

[0036] Based on the above scenarios, it is clear that existing technologies suffer from high development costs.

[0037] The cross-system system file update method, system-on-a-chip, and device provided in this application include: a client system entering engineering mode; the client system writing the system file to be updated from the USB interface directory into a shared file space between the client system and the host system; the host system periodically polling the shared file space to see if the system file to be updated exists; when the system file to be updated exists, the host system writes the system file to the system partition and modifies the status of the system file; the client system determines the result of the operation based on the status of the system file. This application's solution reuses the existing shared file space and, through a polling mechanism and changes in the status of the system file, completes cross-system instruction transmission without a real-time communication channel, avoiding the need for developing cross-system communication protocols and reducing development costs.

[0038] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0039] Figure 1 A flowchart illustrating the cross-system file update method provided in this application; such as Figure 1 As shown, the method includes the following steps:

[0040] S101, The client system enters engineering mode;

[0041] S102. The client system writes the system file to be updated in the USB interface directory to the shared file space between the client system and the host system. The system file is an image file used to control the SOC security function.

[0042] S103. The host system periodically polls the shared file space to check for system files that need to be updated.

[0043] S104. When there is a system file to be updated, the host system writes the system file to the system partition and modifies the status of the system file.

[0044] S105. The client system determines the result of the operation based on the status of the system file.

[0045] For example, this method can be applied to automotive electronic systems, as well as other fields requiring high security and system isolation, such as industrial control systems, medical devices, aerospace electronics, or cloud computing platforms. This method can be applied to system-on-a-chip (SoC), where a host system and a guest system can run. The host system typically refers to the underlying platform running the virtualization layer (e.g., the QNX virtualization platform), responsible for managing physical resources and providing the virtualization environment. The guest system (Guest Virtual Machine, GVM), such as the Android virtual machine system, is a virtualized instance running on the host system, capable of hosting specific applications such as real-time operating systems or general-purpose operating systems.

[0046] In some embodiments, engineering mode is a special state of the client system. In this state, the system provides some engineering application or debugging-related software tools or functional interfaces to enable the client system to enter engineering mode. It can be entered through additional methods and after identity or permission authentication to reduce security risks and facilitate the execution of sensitive operations such as system file updates. Shared file space is a shared storage area between the host system and the client system to realize file exchange. It can be based on virtual disks or network sharing mechanisms to ensure data isolation and efficient transmission.

[0047] In practical applications, when a client system boots in engineering mode, it identifies the system files on the USB device, reads them via the USB interface, and copies them to the shared file space. Optionally, this process may include system file verification to ensure the legitimacy of the source and prevent unauthorized reading of system files.

[0048] For example, the shared file space serves as a shared storage area, allowing the host system to access these system files subsequently, while the client system can only operate in engineering mode, which can reduce external interference and improve update reliability.

[0049] In some embodiments, the host system periodically polls the shared file space for system files awaiting updates, typically using a timer or event-driven mechanism. For example, the host system might set up a periodic check task that scans a specified directory in the shared file space every few seconds or minutes, using the file system's Application Programming Interface (API) to detect new file creation events. In practice, the polling logic might include checking file extensions or metadata identifiers to distinguish updated files from other files, ensuring that only legitimate system files are processed.

[0050] In some embodiments, the host system performs the operation of writing system files to the system partition. This typically involves mounting the guest system's system partition (e.g., via virtual disk mapping), verifying the signature and integrity of the image file, and then using low-level writing tools (such as the dd command or a dedicated API) to copy the system files to the target location. In practice, the current system files can be replaced, or the system files to be updated can be written to a specified storage area in the system partition so that the host system can subsequently boot the main program from that specified partition.

[0051] It should be noted that system files may include image files related to controlling the enabling or disabling of SOC security features, such as image files for enabling SOC Secure Boot, image files for temporarily disabling SOC Secure Boot, and image files for enabling Secure Debugging.

[0052] As we can understand, Secure Boot means that all programs, or a specified range of programs, that are launched from the system and software are secure. "Secure" means that these programs are provided by the software vendor and that this content has not been tampered with; tampering is identified by verifying the software signature.

[0053] In this embodiment, the image file controlling the enabling of Secure Boot is, for example, sec.elf. Loading this image file enables Secure Boot. mifs_la.nonsecure.img is an image file used to temporarily disable Secure Boot, meaning it allows bypassing Secure Boot verification in software. apdp.mbn is an image file used to enable Secure Debugging. mifs_la.nonsecure.img contains a compiled software switch, which is currently disabled in this image. When disabled, the system does not perform signature verification or content checks on the program's data during startup, allowing engineers to temporarily modify content for debugging purposes. Essentially, after writing the image file controlling the temporary disabling of SOC Secure Boot to the system, when the system reaches this point and sees the software switch is disabled, it will not perform verification on other programs, thus bypassing security checks.

[0054] For SOC devices without fuses (such as in-vehicle infotainment systems), after loading sec.elf, the system will program the fuse registers according to the fuse information configured in sec.elf during system restart, thereby enabling secure boot functionality from the hardware level. Once the SOC device completes fuse activation, even if the device restarts, it will boot the system with secure verification enabled, load the configured system image file, and perform data tamper-proof verification to boot the system securely. After fuse activation, sec.elf is no longer needed in the boot process; sec.elf is only used to configure fuse information and instruct the system to complete the fuse operation.

[0055] For SOC devices with fuses, the mifs_la.secure.img image already exists in the system before loading mifs_la.nonsecure.img. During system startup, the system will load this mifs_la.secure.img secure boot image file to verify the signature validity of subsequent boot components (such as other system image files), ensuring that the system has not been tampered with and ensuring system startup security.

[0056] After loading mifs_la.nonsecure.img, the system will start with security checks disabled. The bootloader will also load the system image file to start the system, but it will not check whether the data content has been tampered with, thus allowing engineers to modify and set the content of the system, programs or software for debugging purposes.

[0057] It should be noted that, for an architecture where a host system and a client system run on a SOC, and the client system runs on top of the host system, the system mentioned above refers to the host system. Of course, for other system architectures, the system involved in secure boot can also be a client system, or a client system and a host system; this embodiment does not impose any restrictions.

[0058] The cross-system system file update method provided in this application includes: the client system enters engineering mode; the client system writes the system file to be updated from the USB interface directory into the shared file space between the client system and the host system; the host system periodically polls the shared file space to see if the system file to be updated exists; when the system file to be updated exists, the host system writes the system file to the system partition and modifies the status of the system file; the client system determines the result of the operation based on the status of the system file. This solution reuses the existing shared file space and, through a polling mechanism and changes in the status of the system file, completes cross-system command transmission without a real-time communication channel, avoiding the need to develop cross-system communication protocols and reducing development costs.

[0059] Figure 2 A flowchart illustrating the cross-system file update method provided in this application is shown below. Figure 2 As shown, after the client system enters engineering mode in S101, it also includes:

[0060] S1021. The client system determines the type of the system file to be updated in the USB interface directory;

[0061] S1022, The client system determines the fuse status of the SOC;

[0062] S1023. The client system provides corresponding security function operation buttons based on the type of system file and the fuse status of the SOC.

[0063] S1024. The client system control security function operation button is in an operable state;

[0064] S1025. When the client system receives a click event on the security function operation button, it executes the step of writing the system file to be updated in the USB interface directory to the shared file space between the client system and the host system.

[0065] For example, engineering mode is a special state of a client system. In this state, the client system provides additional software tools or functional interfaces for engineering applications or debugging, which are used to perform certain debugging or engineering settings on the device. Entering engineering mode requires additional methods to operate and requires identity or permission authentication to reduce security risks and facilitate the execution of sensitive operations such as system file updates.

[0066] In some embodiments, the client system checks the system files stored in the USB interface directory and the fuse status of the SOC to determine whether the security function operation button is operable. Specifically, based on the type of system files stored in the USB storage device and the fuse status of the SOC, it determines whether to provide the user with the function to update the corresponding system partition image file. If the security function operation button is available, when the user clicks the security function operation button, the client system writes the system files to be updated stored in the USB interface directory to the shared file space. This involves reading the image file from the USB device, verifying the integrity and legitimacy of its system files (to prevent tampering), and then using a copy function to transfer the system files to the shared file space. The entire process is executed after privilege escalation to ensure that the system file writing does not fail due to insufficient privileges, while reducing external interference through the isolated environment of engineering mode.

[0067] In this example, the fuse status refers to the state of the fuse at the SOC hardware level. Here, "fuse" refers to an eFuse (electronic fuse) or OTP (One-Time Programmable) memory cell inside the chip, which permanently records information by burning out or changing its state. In software security features, the "fuse mechanism" borrows this concept, referring to the permanent or long-term locking of certain functions once a security condition is triggered, making them unrecoverable by ordinary means, thereby preventing unauthorized access, tampering, or bypassing of security features.

[0068] Specifically, the fuse status is controlled by the SOC hardware mechanism. The fuse status can be obtained by reading the value of the field representing the fuse status in the register in the SOC. If it is in the fuse status, it means that the secure boot function is enabled on the hardware. If it is in the non-fuse status, it means that the secure boot function is not enabled on the hardware.

[0069] In practical applications, the engineering mode can be turned on or off by engineers to introduce manual intervention options during system updates.

[0070] This example solution controls system file write operations on the client system by using controlled identity or permission verification in engineering mode and controlling the distribution path of system files stored on external USB storage devices. This achieves secure, reliable, and isolated execution of system file updates, effectively preventing unauthorized access and system damage.

[0071] In some embodiments, in S1013, the client system provides corresponding security function operation buttons based on the type of system file and the fuse status of the SOC, including:

[0072] If the client system determines that the system file is the image file used to control the enabling of the Secure Boot function of the SOC, and determines that the fuse status of the SOC is non-fuse, the client system provides an operation button for enabling the Secure Boot function.

[0073] For example, when the SOC's fuse is in an unfuse state, writing the image file (sec.elf) that controls the SOC's Secure Boot function to the system file partition will change the unfuse state to a fuse state. The written image file (sec.elf) contains a boot program that programs the fuse register during the system's Secure Boot process, after which the fuse is in a fuse state.

[0074] The solution in this embodiment limits the action of "providing an operation button to enable the Secure Boot function" to be triggered only when both of the following conditions are met: "the system file is the image that controls the enabling of the Secure Boot function" and "the SOC is in an unfuse state". This achieves precise condition control over the enabling process of the Secure Boot function, ensuring that the function can only be activated under the premise that the hardware allows it (unfuse) and the software intent is clear (writing a specific image). This reduces the possibility of function enabling failure or conflict due to environmental misjudgment or file confusion.

[0075] In some embodiments, in S1013, the client system provides corresponding security function operation buttons based on the type of system file and the fuse status of the SOC, including:

[0076] If the system file is an image file used to control the temporary shutdown of the Secure Boot function of the SOC, and it is determined that the fuse status of the SOC is in the "fuse" state, then the client system provides an operation button for disabling the Secure Boot function.

[0077] For example, when the SOC's fuse is in a "fed" state, writing the image file (mifs_la.nonsecure.img) that controls the temporary shutdown of the SOC's secure boot function to the system file partition will not change the "fed" state to an "unfed" state. This invariance of the "fed" state never changing to an "unfed" state is based on the fuse register. The fuse register is a One-Time Programmable Register (OTP Register), which can only be programmed once and cannot be modified afterward.

[0078] It's understandable that when the SOC's fuse is in a "fed" state, it indicates that Secure Boot is enabled on the hardware. To disable Secure Boot on the SOC, the user can only do so temporarily through software. This software control involves writing an image file (mifs_la.nonsecure.img) that temporarily disables Secure Boot. Once this image file (mifs_la.nonsecure.img) is written to the system, Secure Boot is temporarily disabled.

[0079] The solution in this embodiment allows the safety start function to be temporarily disabled when the fuse is in the activated state, which facilitates debugging and maintenance while maintaining fuse protection.

[0080] In some embodiments, in S1013, the client system provides corresponding security function operation buttons based on the type of system file and the fuse status of the SOC, including:

[0081] If the system file is an image file used to enable secure debugging, and the SOC's fuse status is determined to be in the "fuse-in" state, the client system provides an operation button to enable secure debugging.

[0082] For example, when the SOC's fuse status is "fuse-in", writing the image file (apdp.mbn) that controls the enabling of secure debugging to the system file partition will not change the "fuse-in" status to "unfuse-out" status, for a reason similar to temporarily disabling the SOC's secure boot function.

[0083] In practical applications, if the SOC's fuse status is "fuse-in", the functional interface for debugging the SOC device is closed for security reasons, and the SOC device can no longer be debugged or modified. However, if there is a need for debugging after the fuse is fused, the debugging policy needs to be enabled. The method to enable the debugging policy is to write the image file (apdp.mbn) that controls the enabling of the secure debugging function.

[0084] The solution in this embodiment provides an entry point for enabling security policy debugging functions when the fuse is already in place, supporting security function testing without compromising system security.

[0085] For example, based on Figure 2 A flowchart illustrating the cross-system system file update method. In S104, the host system writes system files to the system partition and modifies the state of the system files, including:

[0086] S1041. The host system performs the operation of writing system files to the system partition. If the writing is successful, the system file is deleted or a successful writing identifier is added to the name of the system file.

[0087] S1042. If the write operation fails, add a write failure identifier to the name of the system file.

[0088] In some embodiments, the host system typically performs a series of verifications, such as verifying the digital signature of the system file to ensure its integrity and provenance, preventing corrupt or malicious files from being written. Subsequently, the host system invokes a dedicated writing tool or application programming interface to overwrite the contents of the system file onto the corresponding sectors of the system partition, in blocks of data.

[0089] In practical applications, the entire write operation strives for atomicity, meaning it either succeeds completely or fails completely, avoiding inconsistencies caused by partial updates. Therefore, transactional write mechanisms or pre-backing up the original files can be employed. If the write process is verified as successful—meaning all data blocks have been accurately written and verified—the host system performs subsequent state modifications. This involves deleting the original system file in the shared file space to free up space and eliminate potential security risks, or adding a successful write identifier such as "_success" or a timestamp to the name of the system file as a persistent record of the operation.

[0090] In some embodiments, if a write operation fails, possibly due to insufficient disk space, permission errors, file corruption, or hardware failure, the host system's error handling mechanism will be triggered. The system will catch any exceptions or error codes thrown during the write process and immediately interrupt the operation to prevent further data corruption. Furthermore, the host system will not delete the original system file but will ensure it remains in the shared file space, adding explicit write failure identification information to its name, such as adding a "_fail" suffix or a specific error code. This addition of identification information is accomplished through a file system renaming operation, a relatively fast and atomic operation that ensures the reliability of the status markers.

[0091] In practical applications, the added failure identification information not only indicates the result, but may also include a brief explanation of the error, providing crucial clues for subsequent problem diagnosis and manual recovery. In subsequent steps, the client system can clearly determine the operation result by scanning the shared file space and parsing the identification information in these filenames, thus deciding whether to continue the process or trigger an alarm and recovery procedure.

[0092] The solution presented in this example explicitly marks the success and failure status of update operations through atomic operations such as file deletion or renaming, providing a clear and automated state synchronization and error handling mechanism that enhances the reliability and maintainability of the system file update process.

[0093] For example, based on Figure 2 A flowchart illustrating the cross-system system file update method, where the client system determines the result of the operation based on the system file status in S105, including:

[0094] S1051. When the client system detects that a system file has been deleted or the name of the system file contains a successful write identifier, the write operation is considered successful.

[0095] S1052. When the client system detects that the name of a system file contains an identifier indicating a write failure, it determines that the write operation has failed.

[0096] In some embodiments, the client system detects the status of system files primarily by periodically or through event-triggered scanning of the shared file space.

[0097] Specifically, the client system might run a background service that actively queries the shared file space directory at preset time intervals, such as every few seconds. The core of the detection logic lies in analyzing the existence of files and their filename characteristics. For successful writes, the detection criteria are twofold: either the system file with the original filename is not found in the shared file space at all (i.e., it has been deleted by the host system), or a file with a filename containing a specific success identifier can be found. For failed writes, the detection focuses on finding files with filenames containing a specific failure identifier. In practice, this detection mechanism is usually implemented through the file system application programming interface (API). The code parses the filename string, matches it against predefined success or failure keyword patterns, and then makes a judgment.

[0098] In some embodiments, successful write identification information is typically designed as a clear and easily parsable suffix or prefix string. For example, a success identifier might be appended with "SUCCESS" to the original filename, or with an identifier including a timestamp such as "OK_20241024" to indicate the specific time of the successful operation. Failed write identification information, in addition to indicating the failure status, may also include a short error type code for diagnostic purposes. For example, a failure identifier might be appended with "FAIL" to the filename, or more specifically, "ERROR_CODE_05" to indicate a specific error such as "insufficient disk space". These identifiers are a pre-agreed protocol between the host and client systems to ensure a consistent understanding of the file status.

[0099] In some alternative embodiments, when the client system determines that a write operation has failed, in addition to logging the failure, it can also execute a series of automated error handling or recovery procedures. For example, the system can attempt to trigger a retry mechanism, i.e., re-notify the host system or wait for a period of time to check again whether the update process can be restarted. Furthermore, the client system can write detailed error events to the system log and may send alerts to the administrator via the network or user interface, prompting the need for manual intervention, thereby preventing the system from being in a dangerous state of incompleteness or inability to start.

[0100] The solution in this example determines the write result by detecting the status of system files on the client system, and then executes the corresponding success boot or failure handling strategy based on this, thereby improving the reliability and maintainability of the system file update process.

[0101] As yet another example, based on any of these examples, system files are files that have been signed with a key.

[0102] In some embodiments, system file signing is typically performed during the file generation phase, i.e., by the system developer or publisher when building the image file. Specifically, key signing refers to generating a digital signature for a system file using the publisher's private key. This signature can be appended to the end of the file or used as a separate metadata file. This process does not change the file content itself, but generates a unique verification value that any entity holding the corresponding public key can verify has not been tampered with since the file was signed.

[0103] Correspondingly, when the client system writes system files from the USB interface directory to the shared file space in engineering mode, it may perform a preliminary signature verification. Furthermore, before the host system writes system files to the system partition, the host system must use the corresponding public key to verify the signature of the system file, confirming that the file was signed by a legitimate private key holder and has not been modified. Only after the verification is successful will the write operation be performed.

[0104] The solution in this example improves the security of system updates by key signing system files.

[0105] As yet another example, building upon any previous example, prior to the host system writing system files to the system partition in S103, the following steps are also included:

[0106] The host system determines whether the conditions for a write operation are met. If they are met, the system file is written to the system partition.

[0107] In some embodiments, before a critical operation of writing system files to the system partition is performed, the host system needs to perform a precondition check. This is a crucial security gate to ensure that the update operation is not performed under inappropriate system conditions, thereby avoiding system crashes or data corruption.

[0108] For example, the host system also needs to check the health of the system partitions, such as whether there is enough free space, whether the partition table is normal, and whether there are known error logs on the storage media. In addition, some environmental condition checks may also be involved, such as whether the system power supply is stable (especially important for embedded devices), or whether specific security policies are met (such as allowing updates only during specific time windows or when triggered by an authorized administrator).

[0109] For example, the host system needs to verify the integrity and legitimacy of the system file to be written. This includes verifying the digital signature of the system file using a public key to confirm that it comes from a trusted source and has not been tampered with. It may also include verifying whether the file size, checksum, or version number matches the intended target to prevent version incompatibility or file corruption.

[0110] For example, check the running status of the client system. Ideally, the client system should not be in a complete shutdown or a special hibernation state before the operation of writing system files to the system partition can be performed.

[0111] The solution presented in this example introduces a strict precondition judgment mechanism to effectively prevent high-risk write operations from being performed under incompatible or unstable system conditions, thereby significantly improving the reliability, security, and success rate of the entire update process.

[0112] As yet another example, based on any example, the conditions for performing a write operation are determined not to be met if either of the following conditions is met: the host system is about to enter or has already entered a low-power mode; or, a system file has been detected to have been written to by a system identifier.

[0113] In some embodiments, low-power mode means that the system is preparing to reduce its operating frequency, shut down some peripheral devices, or enter hibernation to save energy. In this state, the system's computing power, I / O performance, and storage access stability will significantly decrease. Forcing a high-I / O load system file write operation is highly likely to cause interruptions or incomplete data writing due to unstable power supply or abnormal clock frequency, resulting in system file corruption or even rendering the target partition unbootable.

[0114] In some embodiments, the host system detects that a system file has already been written using a system identifier, which is a key criterion for preventing duplicate writes. This system identifier may be a persistent flag set by the host system in a non-volatile storage area (such as a specific partition or a protected system configuration file) after a previous successful write operation, or it may be version metadata recorded in the system partition. Before performing a new update, the host system first reads and verifies this identifier. If the version number, checksum, or timestamp of the system file to be written is found to be completely identical to the existing system identifier, it is determined to be a duplicate operation. The effectiveness of this mechanism lies in avoiding unnecessary and potentially high-risk repeated write operations. This not only saves time but, more importantly, eliminates the unexpected risks that may be introduced by multiple redundant writes to the same system partition, such as a power outage between writes causing the system to be in an inconsistent intermediate state.

[0115] The solution presented in this example effectively avoids performing high-risk operations in unstable or redundant scenarios by introducing an intelligent prediction mechanism for low-power states and repeated writes, thereby significantly improving the security and efficiency of the system file update process.

[0116] Figure 3 The multi-system architecture diagram provided in this application is as follows: Figure 3 As shown, the host system can be a QNX system, and a guest system (GVM system, such as an Android system) can run on the host system; the shared file system area between the two corresponds to the shared file space.

[0117] Based on this system architecture, the specific method for updating system files across systems is as follows:

[0118] The client system can run an engineering mode application (APP). This application allows the GVM system to enter engineering mode. In this mode, the application can issue a copy command to copy the system files to be updated stored on a USB flash drive via the USB interface and copy them to the shared file space. The system files are then renamed according to pre-agreed rules (e.g., the File Rename command) so that the host system can recognize them.

[0119] The background program on the host system side (which can be a script running on the host system) reads files in the shared file space by polling (e.g., the Read File Name command). After detecting a system file, it will perform a write operation on the system file, such as using the dd if = file command to write the file to a system partition such as Universal Flash Storage (UFS) or Embedded MultiMedia Card (EMMC). After the operation is completed, it will modify the status of the file by renaming or deleting it (e.g., the File Rename / File Remove command).

[0120] Modifications to file status by the host system (renaming or deletion) are detected by the client system's application (APP) by reading the filename, thus determining the success or failure of the write operation. This interaction mode based on shared file space enables secure and orderly communication between two heterogeneous systems, ensuring that system file update tasks can be reliably completed under the high-privilege control of the host system, while the client system can promptly perceive the final status.

[0121] Figure 4 A flowchart illustrating the cross-system file update method provided in this application is shown below. Figure 4 The diagram shows the workflow of the client system as the execution entity. The steps performed by the client system are as follows:

[0122] S601. The system detects that the engineering mode APP is open (i.e., after the user triggers the operation to enter the engineering mode, the client system verifies the user's identity or permissions, and then the client system enters the engineering mode. The engineering mode APP can be opened automatically by the client system or manually) and detects that the USB flash drive is inserted (i.e., the client system detects that a USB flash drive is inserted).

[0123] S602, Read the root directory of the USB drive;

[0124] S603. Confirm that the safety function operation button is in an operable state. If yes, proceed to step S604; otherwise, end the process.

[0125] Step 604: When a click event is received on the safety function operation button, continue to the following steps S605.

[0126] S605: Copy the system files to be updated to the shared file space;

[0127] S606. Read the status of system files in the shared file space. If a system file is deleted or its name contains the suffix "success", then proceed to step S607. If the name of a system file contains the suffix "failed+reason", then proceed to step S608.

[0128] S607. The report system file was successfully written and a success message was displayed.

[0129] S608, Report system file writing failure and display failure message.

[0130] Figure 5 A flowchart illustrating the cross-system file update method provided in this application is shown below. Figure 5 The diagram shows the workflow of the host system as the execution entity. The host system periodically executes:

[0131] S701. Read whether there is a system file to be updated in the shared file space. If there is a system file to be updated in the shared file space, then execute the following step S702. Otherwise, return to the beginning.

[0132] S702. Determine whether the conditions for performing a write operation are met. If the conditions for performing a write operation are met, proceed to step 703; if the conditions for performing a write operation are not met, proceed to step 704. Step 704. Add the suffix "failed + reason" to the name of the system file.

[0133] S703. Use the dd command to write the system file to the corresponding system partition according to the system file name;

[0134] S705. Check whether the system file was written successfully or not. If the writing was successful, proceed to step S706 below; if the writing failed, proceed to step S707 below.

[0135] S706. Delete the system file or add the suffix "success" to the name of the system file;

[0136] S707. Add the suffix "failed + reason" to the names of system files;

[0137] After S704, S706, and S707 are executed, the process returns to the initial step of S701.

[0138] The cross-system system file update method provided in this application includes: the client system enters engineering mode, and when the user clicks the corresponding security function operation button, it writes the system file to be updated under the USB interface directory into the shared file space between the client system and the host system; the host system periodically polls the shared file space to see if there is a system file to be updated; when there is a system file to be updated, the host system writes the system file to the system partition and modifies the status of the system file; the client system determines the result of the operation based on the status of the system file. This application's solution reuses the existing shared file space and, through a polling mechanism and changes in the status of system files, completes cross-system command transmission without a real-time communication channel, avoiding the need to develop cross-system communication protocols and reducing development costs.

[0139] Figure 6 This is a schematic diagram of the system-on-a-chip (SoC) provided in this application. The SoC runs a host system 81 and a client system 82.

[0140] When the client system 82 enters engineering mode, the client system 82 writes the system file to be updated in the USB interface directory to the shared file space between the client system 82 and the host system 81. The system file is an image file used to control the SOC security function.

[0141] The host system 81 periodically polls the shared file space to check for system files that need to be updated.

[0142] When a system file exists that needs to be updated, the host system 81 writes the system file to the system partition and modifies the status of the system file;

[0143] The client system 82 determines the result of the operation based on the status of the system file.

[0144] In one example, client system 82 is also used for:

[0145] Determine the type of system file to be updated in the USB interface directory;

[0146] Determine the fuse status of the SOC;

[0147] Provide corresponding safety function operation buttons based on the type of system file and the fuse status of the SOC;

[0148] The control safety function operation buttons are in an operable state;

[0149] When a click event is received on the security function operation button, the client system executes the step of writing the system file to be updated in the USB interface directory to the shared file space between the client system and the host system.

[0150] In one example, client system 82 is specifically used for:

[0151] If the system file is determined to be an image file used to control the enabling of the Secure Boot function of the SOC, and the fuse status of the SOC is determined to be non-fuse, then an operation button for enabling the Secure Boot function is provided.

[0152] In one example, client system 82 is specifically used for:

[0153] If the system file is an image file used to control the temporary shutdown of the Secure Boot function of the SOC, and it is determined that the fuse status of the SOC is in the "fuse" state, then an operation button for disabling the Secure Boot function is provided.

[0154] In one example, client system 82 is specifically used for:

[0155] If the system file is an image file used to enable the secure debugging function, and the SOC's fuse status is determined to be in the "fuse-in" state, then an operation button for enabling the secure debugging function is provided.

[0156] In one example, host system 81 is specifically used for:

[0157] The host system 81 writes the system file to the system partition. If the writing is successful, the system file is deleted or a successful writing identifier is added to the name of the system file; if the writing fails, a failed writing identifier is added to the name of the system file.

[0158] In one example, client system 82 is specifically used for:

[0159] The client system 82 determines that the write operation was successful if it detects that a system file has been deleted or that the system file's name contains a successful write identifier; conversely, the client system 82 determines that the write operation failed if it detects that the system file's name contains a failed write identifier. In one example, the system file is a file that has been encrypted or signed with a key.

[0160] In one example, the host system 81 is further configured to: determine whether the conditions for a write operation are met; if so, write the system file to the system partition. In one example, the conditions for a write operation are not met if either of the following conditions is met: the host system 81 is about to enter or has already entered a low-power mode; or, the host system 81 detects that the system file has already been written through the system identifier.

[0161] The system-on-a-chip provided in this embodiment can execute the methods provided in the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0162] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Figure 7 As shown, the electronic device provided in this embodiment includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, memory 292, and communication interface 293 can communicate with each other via the bus 294. The communication interface 293 can be used for information transmission. The processor 291 can call logical instructions in the memory 292 to execute the method described above.

[0163] Furthermore, the logic instructions in the aforementioned memory 292 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0164] The memory 292, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, that is, it implements the methods in the above method examples.

[0165] The memory 292 may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 292 may include high-speed random access memory and may also include non-volatile memory.

[0166] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0167] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method described in the above embodiments.

[0168] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0169] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0170] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0171] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0172] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0173] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0174] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A cross-system system file update method, applied to a system-on-a-chip (SoC), characterized in that, The system-on-a-chip runs a host system and a client system, and the method includes: The client system enters engineering mode; The client system writes the system file to be updated in the USB interface directory into the shared file space between the client system and the host system. The system file is an image file used to control the SOC security function. The host system periodically polls the shared file space to check if the system file to be updated exists. When the system file to be updated exists, the host system writes the system file to the system partition and modifies the status of the system file; The client system determines the result of the operation based on the status of the system file.

2. The method according to claim 1, characterized in that, After the client system enters engineering mode, the following is also included: The client system determines the type of the system file to be updated in the USB interface directory; The client system determines the fuse status of the SOC; The client system provides corresponding security function operation buttons based on the type of the system file and the fuse status of the SOC; The client system controls the security function operation button to be in an operable state; When the client system receives a click event on the security function operation button, it executes the step of writing the system file to be updated in the USB interface directory into the shared file space between the client system and the host system.

3. The method according to claim 2, characterized in that, The client system provides corresponding security function operation buttons based on the type of the system file and the fuse status of the SOC, including: If the client system determines that the system file is an image file used to control the enabling of the Secure Boot function of the SOC, and determines that the fuse status of the SOC is non-fuse, then the client system provides an operation button for enabling the Secure Boot function.

4. The method according to claim 2, characterized in that, The client system provides corresponding security function operation buttons based on the type of the system file and the fuse status of the SOC, including: If the system file is an image file used to control the temporary shutdown of the Secure Boot function of the SOC, and it is determined that the fuse status of the SOC is in the fused state, then the client system provides an operation button for disabling the Secure Boot function.

5. The method according to claim 2, characterized in that, The client system provides corresponding security function operation buttons based on the type of the system file and the fuse status of the SOC, including: If the system file is an image file used to enable secure debugging, and the fuse status of the SOC is determined to be in the fused state, then the client system provides an operation button for enabling secure debugging.

6. The method according to claim 1, characterized in that, The host system performs the operation of writing the system file to the system partition and modifying the state of the system file, including: The host system writes the system file to the system partition. If the writing is successful, the system file is deleted or a successful writing identifier is added to the name of the system file. If the write operation fails, an identifier indicating the write failure will be added to the name of the system file.

7. The method according to claim 6, characterized in that, The client system determines the result of the operation based on the state of the system file, including: The client system determines that the write operation was successful when it detects that the system file has been deleted or the name of the system file contains a successful write identifier. When the client system detects that the name of the system file contains an identifier indicating a write failure, it determines that the write operation has failed.

8. The method according to claim 1, characterized in that, Before the host system writes the system file to the system partition, the following is also included: The host system determines whether the conditions for a write operation are met. The conditions for a write operation include that the host system has not entered a low-power mode; or, the host system detects through a system identifier that the system file has not been written to. If the conditions are met, the system file will be written to the system partition.

9. A system-on-a-chip, characterized in that, The system-on-a-chip runs a host system and a client system, wherein... When the client system enters engineering mode, the client system writes the system file to be updated in the USB interface directory to the shared file space between the client system and the host system. The system file is an image file used to control the SOC security function. The host system periodically polls the shared file space to check if the system file to be updated exists. When the system file to be updated exists, the host system writes the system file to the system partition and modifies the status of the system file; The client system determines the result of the operation based on the status of the system file.

10. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

Images