Vehicle firmware upgrade package flashing method and device, vehicle and storage medium

Abstract

This application provides a method, apparatus, vehicle, and storage medium for flashing vehicle firmware upgrade packages. The method is applied in the field of vehicle software upgrade and flashing technology. It receives a firmware upgrade package sent by a cloud server. The firmware upgrade package uses a predefined logical partition name as a unique index. The firmware upgrade package contains image files corresponding to each logical partition name, and the logical partition name does not contain any node information pointing to the physical storage location on the vehicle side. Based on the obtained partition node mapping table, the physical storage path of the target device partition corresponding to the logical partition name is determined. The image file corresponding to the logical partition name is extracted from the firmware upgrade package and written to the storage area pointed to by the physical storage path. This achieves the effect of adaptively finding the path and downloading the image file on the vehicle side without specifying a specific physical storage path on the cloud server side, only requiring the corresponding logical partition name.

Description

Technical Field

[0001] This application relates to the field of vehicle software upgrade and flashing technology, and more specifically, to a method, apparatus, vehicle, and storage medium for flashing vehicle firmware upgrade packages in the field of vehicle software upgrade and flashing technology. Background Technology

[0002] In current mainstream automotive OTA (Over-the-Air) systems, cloud-based upgrade packages require hard-coding of the physical device node paths on the vehicle side. The upgrade packages are deeply bound to the partition naming and storage architecture of specific vehicle models. When the cloud issues upgrade commands, the operation and maintenance personnel statically specify the target partition, and the vehicle side writes directly according to this physical path. Furthermore, the system does not define standardized logical partition identifiers, and all configurations expose the underlying physical paths.

[0003] However, this approach has the following problems: First, the upgrade package is tightly coupled with the vehicle model. Every change in partition naming requires modification of the packaging tool, resulting in multiple versions of the tool existing simultaneously. This leads to a large number of upgrade packages and makes mismatches during operation and maintenance extremely easy. Second, the cloud cannot sense whether the vehicle is currently running on side A or side B, nor can it determine whether the target partition is safe to write, posing a risk of system crashes due to accidental writing to the currently running partition. Third, the vehicle system does not support automatic identification of source / target partitions by the client and cannot adapt to new architectures such as AB dual partitions and dynamic partitions. Any hardware change requires full-line linkage, resulting in extremely poor scalability and maintainability.

[0004] Therefore, the current upgrade package is strongly coupled with the underlying physical path, lacks a unified logical partition identifier and dynamic adaptation mechanism, and the vehicle cannot automatically identify the currently running partition and the secure writable partition. It is also incompatible with multiple partition architectures, resulting in a serious architectural coupling defect in the current vehicle OTA upgrade system. Summary of the Invention

[0005] This application provides a method, apparatus, vehicle, and storage medium for flashing vehicle firmware upgrade packages. This method can solve the technical problem in the current vehicle OTA upgrade system where there is a strong coupling defect between the cloud firmware upgrade package and the underlying physical path of the vehicle.

[0006] Firstly, a method for flashing vehicle firmware upgrade packages is provided, the method comprising: The firmware upgrade package is received from the cloud server. The firmware upgrade package uses a predefined logical partition name as a unique index. The firmware upgrade package contains an image file corresponding to each logical partition name, and the logical partition name does not contain any node information pointing to the physical storage location of the vehicle. Based on the obtained partition node mapping table, the physical storage path of the target device partition corresponding to the logical partition name is determined. The partition node mapping table is used to record the correspondence between the logical partition name and the physical storage path of each physical device partition on the vehicle side. The target device partition is the device partition that is not running among the physical device partitions. Extract the image file corresponding to the logical partition name from the firmware upgrade package and write it to the storage area pointed to by the physical storage path.

[0007] The beneficial effects of the technical solution described in the first aspect above include at least the following: By using standardized logical partition names as the unique indexes of the image files in the firmware upgrade packages generated by the cloud server, and to ensure the lightweight nature of the information in the firmware upgrade packages, the naming of these indexes does not carry any physical storage node information. Furthermore, the vehicle side independently maintains a partition node mapping table, which dynamically converts the logical partition names into actual writable physical storage paths based on the current system startup running state. The vehicle side only needs to query the mapping table to obtain the secure writable non-running partition path. The cloud server does not need to be aware of the current running state of the vehicle side, thus eliminating the risk of accidentally writing to the currently running partition. At the same time, since the logical partition names remain consistent across different vehicle models and different partition naming rules, the same upgrade package can be adapted to multiple hardware variants without modification, thereby eliminating the problems of multiple versions of packaging tools and operational mismatches caused by partition naming changes. This involves constructing a two-level abstraction layer for finding paths using logical partition names and partition node mapping tables. This completely decouples the upgrade business logic from the underlying partition layout. Regardless of whether the vehicle adopts a single partition, AB dual partition, or dynamic partition architecture, compatibility can be achieved simply by adjusting the implementation of the mapping table. The evolution of hardware partitioning schemes no longer requires a full-line linkage modification of upgrade tools or upgrade packages. This solves the technical problem of strong coupling between cloud firmware upgrade packages and the underlying physical paths of the vehicle in current in-vehicle OTA upgrade systems.

[0008] Among some possible implementations, the above-mentioned vehicle firmware upgrade package flashing method includes: Using the logical partition name as an index, the physical storage path of the target device partition that the preset soft link node in the obtained partition node mapping table is determined.

[0009] Using the technical solutions described above in the possible implementation methods, the use of soft link nodes does not require the development of additional complex mapping query logic. At the same time, soft links can be viewed and debugged by standard file system tools, making it convenient for operation and maintenance personnel to check whether the mapping relationship is correct. When it is necessary to change the physical storage path, only the target of the soft link needs to be updated, without modifying any application code.

[0010] Among some possible implementations, the above-mentioned vehicle firmware upgrade package flashing method includes: Each time the system is started on the vehicle, the target device partition that is not in operation on the vehicle is identified, and a soft link node pointing to the physical storage path of the target device partition is generated. Update the obtained partition node mapping table based on the changes in the path pointed to by the soft link node.

[0011] By using the technical solutions in the above possible implementation methods, the mapping relationship can be dynamically generated each time the system starts, which can automatically adapt to the changes in partition layout caused by the switching of vehicle-side operation (such as A / B slot switching), ensure that the soft connection node points to the correct operating plane, and ensure that the partition node mapping table always reflects the current actual physical storage layout without manual intervention.

[0012] Among some possible implementations, the above-mentioned vehicle firmware upgrade package flashing method includes: Read the device partition identifier to which the current system boot partition belongs; Using the logical partition name as an index, the physical storage path corresponding to the non-running plane relative to the device partition identifier is retrieved from the obtained partition node mapping table; The partition node mapping table records the device partition identifiers of the dual device partitions of each logical partition, and records the physical storage paths corresponding to the two respectively; wherein, when the device partition identifier of one device partition corresponds to the running plane, the device partition identifier of the other device partition corresponds to the non-running plane.

[0013] Through the technical solutions described above, the firmware upgrade package is always written to the non-operational plane, and the current operational plane remains unaffected. Even if a power outage or error occurs during the flashing process, the vehicle can still boot normally from the original operational plane, achieving a safe upgrade (i.e., seamless upgrade of the A / B plane system). Simultaneously, because the mapping table clearly distinguishes the physical paths of the two slots, the system does not need to rely on external soft connection mechanisms and can directly obtain the target path by looking up the table, greatly improving system upgrade efficiency and reducing the complexity of writing firmware upgrade packages.

[0014] Among some possible implementations, the above-mentioned vehicle firmware upgrade package flashing method includes: The partition node mapping table is pre-installed in the vehicle's security element and stored in encrypted form.

[0015] Through the technical solutions in the above possible implementations, the partition node mapping table is written into the non-volatile storage area of ​​the safety element during the vehicle production stage, and locked after writing to prevent unauthorized modification and ensure the security of the partition node mapping table.

[0016] Among some possible implementations, the above-mentioned vehicle firmware upgrade package flashing method includes: Receive mapping table update data packets with digital signatures sent by the cloud server; The digital signature is verified for integrity and source authentication using a public key pre-installed in the vehicle's security element. After confirming the validity of the digital signature, the partition node mapping table stored in the secure element is replaced or incrementally updated to adapt to changes in the hardware partition topology of the vehicle or the need for adding new logical partitions.

[0017] By utilizing the technical solutions in the above possible implementations and updating the partition node mapping table in the secure element using digital signatures, automakers can remotely correct partition mapping errors, adapt to new hardware modifications, or expand storage partitions after the vehicle is sold, without requiring the vehicle to return to the factory. This significantly reduces maintenance costs while ensuring the security and integrity of the updates.

[0018] Among some possible implementations, the above-mentioned vehicle firmware upgrade package flashing method includes: A switching command is sent to the bootloader on the vehicle side, and when the vehicle side starts up again, it boots from the target device partition corresponding to the physical storage path after the image file is written, so that the non-running surface corresponding to the target device partition is transformed into a new running surface.

[0019] By employing the technical solutions described above in the possible implementation methods, the original system remains unchanged during the upgrade process. The system will only switch to the new system after the upgrade is successful and the vehicle is restarted. Any upgrade failure will not affect the normal use of the vehicle, greatly improving the reliability of OTA upgrades and the user experience.

[0020] Secondly, a vehicle firmware upgrade package flashing device is provided, the device comprising: The receiving module is used to receive firmware upgrade packages sent by the cloud server. The firmware upgrade package uses a predefined logical partition name as a unique index. The firmware upgrade package contains image files corresponding to each logical partition name, and the logical partition name does not contain any node information pointing to the physical storage location of the vehicle. The determination module is used to determine the physical storage path of the target device partition corresponding to the logical partition name based on the obtained partition node mapping table. The partition node mapping table is used to record the correspondence between the logical partition name and the physical storage path of each physical device partition on the vehicle side. The target device partition is the device partition that is not running among the physical device partitions. The update module is used to extract the image file corresponding to the logical partition name from the firmware upgrade package and write it to the storage area pointed to by the physical storage path.

[0021] Thirdly, a vehicle is provided, including a memory for storing executable program code; and a processor for calling and running the executable program code from the memory, causing the vehicle to perform the methods described in the first aspect or any possible implementation thereof.

[0022] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0023] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0024] Figure 1 An exemplary system architecture diagram of a vehicle firmware upgrade package flashing method provided in this application embodiment; Figure 2 A flowchart illustrating a method for flashing a vehicle firmware upgrade package, provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for flashing a vehicle firmware upgrade package, provided in an embodiment of this application; Figure 4 A flowchart illustrating a method for flashing a vehicle firmware upgrade package, provided in an embodiment of this application; Figure 5 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0025] To make the features and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent 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. Furthermore, in the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, in the description of the embodiments of this application, "multiple" refers to two or more.

[0027] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0028] In current mainstream automotive OTA systems, the firmware upgrade packages generated by the cloud server require hardcoding the physical device node paths on the vehicle side. For example, the bootloader image is fixed to / dev / mmcblk0p1, and the system image is fixed to / dev / mmcblk0p5. This design results in the upgrade package being deeply bound to the partition naming rules, storage chip layout, and partition table order of a specific vehicle model. Once the partition naming or layout changes, for example, due to hardware upgrades that increase the eMMC (Embedded MultiMedia Card) from 32GB to 64GB, causing subsequent partition start addresses to shift, or due to information security requirements that add a separate trusted root partition, or due to adjustments in partition order to fix boot vulnerabilities, the cloud server's packaging tool must simultaneously modify these hardcoded paths.

[0029] Meanwhile, the same vehicle model may undergo multiple such changes during its lifecycle. Each change means maintaining a new version of the packaging tool, forcing the cloud-based operations and maintenance team to manage multiple parallel packaging tool versions simultaneously, each compatible only with a specific combination of hardware batches and software versions. When issuing upgrade tasks, operations and maintenance personnel must first query the target vehicle's hardware batch, current software version, and partition layout version, then select the correct packaging tool from the toolchain repository to regenerate the upgrade package, or select the correct version of the pre-generated package from the upgrade package repository. This multi-dimensional mapping relationship is extremely complex and prone to basic errors such as tool misselection, configuration mismatch, and image writing errors, which is known in the industry as tool explosion and configuration maze. Once an error occurs, the upgrade may fail at best, and at worst, the image may be written to the wrong partition, causing vehicle malfunctions or even preventing the vehicle from starting.

[0030] Meanwhile, when the cloud server issues the upgrade command, it has no way of knowing whether the vehicle is currently running on the A-side or the B-side. In vehicles that support seamless A / B partition upgrades, there are two sets of partitions in the storage medium: one for the currently running system (running side) and the other for the backup system (non-running side). The A-side and B-side (also known as the A / B system or A / B partition) is a dual-system backup mechanism used to achieve seamless and secure system updates. The correct upgrade strategy for this dual-system backup mechanism is to write the new firmware to the non-running side and then make the new system effective by switching the boot slot.

[0031] However, in existing systems, cloud servers can only infer the current operating plane (whether plane A or plane B is currently running) based on static information such as the software version number reported by the vehicle, or directly use the target partition path manually configured by maintenance personnel. If the vehicle's current physical path happens to be the operating plane partition, the write operation will overwrite the running system core files, causing the system to crash immediately; if the write operation is to the bootloader partition and the vehicle is running, the vehicle may be completely unable to start. This risk often leads maintenance personnel to adopt a conservative strategy in practice, or even require the vehicle to be sent back to the factory for upgrades, severely undermining the value of OTA technology.

[0032] More importantly, the vehicle-side system itself does not support automatically identifying the running and non-running partitions based on the operating environment. Typically, all upgrade targets are statically specified by the cloud server or manually, with the vehicle only passively performing write operations and lacking any intelligent judgment capabilities. It cannot determine whether it is currently running on side A or side B, nor can it determine which partition is in a non-running state and safe to write, let alone whether the target device partition is in a normal state (e.g., whether it is damaged or has sufficient space). This design is completely inadequate when facing new architectures such as AB dual-partition, ABC triple-partition, and dynamic partitioning. For example, in the ABC triple-partition scheme, there are three slots that are upgraded in turn. The vehicle needs to comprehensively decide on the next target partition based on factors such as the currently running slot, the previous successful upgrade status, and the version numbers of each slot. This obviously cannot be achieved by statically specifying it through the cloud server. As another example, in the dynamic partitioning scheme, the size and position of the partition can be adjusted at runtime, and the physical path is no longer fixed. The cloud server simply cannot predict the path of the target partition in advance.

[0033] Therefore, this application provides a method for flashing vehicle firmware upgrade packages to solve the above-mentioned technical problems.

[0034] Please see Figure 1 , Figure 1 This is an exemplary system architecture diagram of a vehicle firmware upgrade package flashing method provided in an embodiment of this application.

[0035] like Figure 1 As shown, the system architecture may include vehicle 101, network 102, and server 103. Network 102 serves as the medium for providing a communication link between vehicle 101 and server 103. Network 102 may include various types of wireless communication links, such as Near Field Communication (NFC), Ultra Wideband (UWB), Bluetooth, Wireless-Fidelity (Wi-Fi), or microwave communication links.

[0036] Vehicle 101 can interact with server 103 via network 102 to receive or send messages to server 103. Alternatively, vehicle 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. Server 103 can be a business server providing various services. It should be noted that server 103 can be hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0037] In this embodiment, vehicle 101 first receives a firmware upgrade package sent by a cloud server. The firmware upgrade package uses a predefined logical partition name as a unique index. The firmware upgrade package contains image files corresponding to each logical partition name, and the logical partition name does not contain any node information pointing to the physical storage location of the vehicle. Then, vehicle 101 determines the physical storage path of the target device partition corresponding to the logical partition name according to the obtained partition node mapping table. Subsequently, vehicle 101 extracts the image file corresponding to the logical partition name from the firmware upgrade package and writes it to the storage area pointed to by the physical storage path.

[0038] The system architecture may or may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification, that is, the method provided in the embodiments of this application can be applied to a system structure that only includes vehicle 101, and the embodiments of this application do not limit this.

[0039] It should be understood that Figure 1 The number of vehicles, networks, and servers shown is only illustrative; the number can be any number depending on the implementation requirements.

[0040] Please see Figure 2 , Figure 2 This is a flowchart illustrating a method for flashing a vehicle firmware upgrade package, provided in an embodiment of this application. The execution subject in this embodiment can be a vehicle executing the method for flashing a vehicle firmware upgrade package, a processor within the vehicle executing the method for flashing a vehicle firmware upgrade package, or a vehicle firmware upgrade package flashing service within the vehicle executing the method for flashing a vehicle firmware upgrade package. For ease of description, the following uses the processor within the vehicle as an example to illustrate the specific execution process of the method for flashing a vehicle firmware upgrade package.

[0041] like Figure 2 As shown, the vehicle firmware upgrade package flashing method can include at least the following: S10. Receive the firmware upgrade package sent by the cloud server. The firmware upgrade package uses a predefined logical partition name as a unique index. The firmware upgrade package contains an image file corresponding to each logical partition name, and the logical partition name does not contain any node information pointing to the physical storage location of the vehicle. Understandably, the vehicle receives the firmware upgrade package sent by the cloud server through its built-in communication module. The biggest difference between this upgrade package in this embodiment and the regular upgrade package is that it does not use any information related to the vehicle's physical storage location.

[0042] Specifically, traditional upgrade packages might explicitly state that the image file should be written to a specific physical device node on the vehicle (such as the absolute hardware path of / dev / disk / boot_a). However, the upgrade package in this embodiment uses only a set of predefined logical partition names as indexes. These logical partition names are uniformly agreed upon by the automaker during the development phase and are independent of specific hardware. For example, bootloader can represent the bootloader partition, kernel the kernel partition, system the system partition, and modem the communication baseband partition. These names remain consistent across all vehicle models and hardware platforms, just like each person has a fixed name, regardless of its specific absolute hardware path, thus simplifying the cumbersome nature of firmware upgrade packages.

[0043] In addition to the image file itself, the firmware upgrade package also includes a manifest file, which lists the logical partitions involved in the upgrade and their corresponding image files. For example, an upgrade might include two logical partitions: bootloader and system. The manifest would specify that bootloader corresponds to bootloader.bin and system corresponds to system.img. It's important to note that even in this manifest, the paths to any physical device nodes are completely absent.

[0044] S20. Based on the obtained partition node mapping table, determine the physical storage path of the target device partition corresponding to the logical partition name. The partition node mapping table is used to record the correspondence between the logical partition name and the physical storage path of each physical device partition on the vehicle side. The target device partition is the device partition that is not in operation among the physical device partitions. In this embodiment, after receiving the upgrade package, the vehicle does not immediately begin flashing. Instead, it first retrieves the partition node mapping table stored locally. This partition node mapping table is a configuration file generated by the vehicle at the factory based on its hardware layout. It mainly records the correspondence between each standardized logical partition name in the vehicle's hardware and the vehicle's actual physical storage path. For example, assuming an existing vehicle exists, its mapping table may record that the physical path corresponding to the bootloader is / dev / mmcblk0p1, and the physical path corresponding to the system is / dev / mmcblk0p5. That is, the partition node mapping table contains the specific physical paths of each device node on the vehicle corresponding to each partition node. It is equivalent to a partition node address lookup table, which can find the corresponding appropriate physical path based on the name of each physical node.

[0045] Furthermore, the vehicle uses the logical partition name in the firmware upgrade package's corresponding list as an index to query the specific path in the partition node mapping table. For example, when the firmware upgrade package requires updating the system partition, the vehicle looks up the system entry in the partition node mapping table and matches it with the physical path / dev / mmcblk0p5 corresponding to that system entry.

[0046] It should be noted that since the operation of vehicle-side devices is usually divided into two partitions, taking the system entry as an example, it corresponds to two running planes, assuming they are named A and B respectively. When the vehicle is powered on and started, the vehicle can activate running plane A to execute the system program. At this time, if the firmware upgrade package is directly downloaded to running plane A, it will cause the currently running program to crash, resulting in the vehicle system being unable to be used normally. Therefore, it is generally necessary to download the firmware upgrade package to running plane B. Running plane B is currently idle or inactive. In this embodiment, running plane B is the target device partition.

[0047] In this embodiment, the partition node mapping table is pre-installed in the vehicle's security element and stored in an encrypted manner.

[0048] In this embodiment, a secure storage method for the partition node mapping table is specifically defined, namely, the partition node mapping table is pre-placed in the vehicle's secure element and stored in an encrypted manner.

[0049] The Secure Element (SE) can be a standalone hardware security chip or a security subsystem integrated into a system-on-a-chip. It mainly features protection against physical attacks, tampering, and side-channel attacks, and can protect the sensitive data stored therein.

[0050] Specifically, the partition node mapping table is written into the non-volatile storage area of ​​the secure element during the vehicle production stage. After being written, it is locked to prevent unauthorized modification. When it is stored, the mapping table data can be encrypted using a vehicle-specific device key (e.g., using the AES-256-GCM algorithm) to ensure that even if an attacker reads the external storage of the secure element by physical means, they cannot obtain the plaintext content of the mapping table.

[0051] Meanwhile, when the vehicle is running, programs that need to read the partition node mapping table (such as OTA upgrade clients) request the decrypted mapping table data through a dedicated call interface provided by the secure element. At the same time, after performing access control checks (e.g., only allowing calls from signed trusted applications), the secure element decrypts the mapping table and returns it to the caller.

[0052] Furthermore, because the partition node mapping table is stored in an encrypted manner and the access path is controlled, even if the vehicle's operating system is compromised, attackers cannot tamper with the partition node mapping table, thereby preventing malware from writing firmware to the wrong partition by modifying the mapping table, which could lead to system damage or security vulnerabilities.

[0053] S30. Extract the image file corresponding to the logical partition name from the firmware upgrade package and write it to the storage area pointed to by the physical storage path.

[0054] In this embodiment, the vehicle can extract the image file (e.g., system.img) corresponding to the logical partition name from the firmware upgrade package and write it to the storage area pointed to by the physical storage path of the target device partition obtained by the query.

[0055] This write operation typically requires erasing the original content of the target partition, writing the new image, and finally performing verification. This ensures that the same upgrade package using the logical name "system" will be written to / dev / mmcblk0p5 on a Type A vehicle and to / dev / mmcblk0p8 on a Type B vehicle, thus enabling a single firmware upgrade package to adapt to various different hardware applications.

[0056] In this embodiment, after the step of extracting the image file corresponding to the logical partition name from the firmware upgrade package and writing it to the storage area pointed to by the physical storage path, the method further includes: Receive mapping table update data packets with digital signatures sent by the cloud server; The integrity of the digital signature is verified and its source is authenticated using the verification public key pre-installed in the security element at the vehicle end. After confirming the validity of the digital signature, the partition node mapping table stored in the secure element is replaced or incrementally updated to adapt to changes in the hardware partition topology of the vehicle or the need for adding new logical partitions.

[0057] In this embodiment, a remote update mechanism for the partition node mapping table is provided to adapt to changes in the vehicle hardware partition topology (e.g., changes in partition layout due to storage media replacement or capacity expansion) or the need for adding new logical partitions. When the automaker needs to update the partition node mapping table stored on the vehicle, the cloud server generates a mapping table update data packet with a digital signature. The data packet includes new mapping table data (or incremental patch), version number, target vehicle identification number range, and timestamp information.

[0058] The specific update process includes: using a pre-installed verification public key within the secure element to perform integrity verification and source authentication on the digital signature; the secure element pre-stores the vehicle manufacturer's root certificate public key or a dedicated verification public key. The vehicle transmits the received data packet to the secure element, which then uses this public key to verify the digital signature of the data packet.

[0059] The verification process includes confirming that the signature was issued by the automaker's private key, confirming that the data packet has not been tampered with, confirming that the VIN code in the data packet matches the current vehicle, and confirming that the timestamp is within a valid range. If any verification fails, the security element returns an error and refuses to update.

[0060] After confirming the validity of the digital signature, the partition node mapping table stored in the secure element is replaced or incrementally updated: the secure element performs the update operation internally; for replacement updates, the secure element directly erases the original mapping table and writes new mapping table data; for incremental updates, the secure element reads the current mapping table, applies patches, generates a new mapping table and writes it. All operations are completed internally by the secure element, and the operating system cannot directly access the intermediate data during the update process. After the update is completed, the secure element returns a success status, and the vehicle can use the new mapping table for subsequent firmware upgrades.

[0061] In summary, this mechanism allows automakers to remotely correct partition mapping errors, adapt to new hardware modifications, or expand storage partitions after a vehicle is sold, without requiring the vehicle to return to the factory. This significantly reduces maintenance costs while ensuring the security and integrity of updates.

[0062] In this embodiment, after the step of extracting the image file corresponding to the logical partition name from the firmware upgrade package and writing it to the storage area pointed to by the physical storage path, the method further includes: A switching command is sent to the bootloader on the vehicle side, and the vehicle side boots from the target device partition corresponding to the physical storage path after the image file is written when it starts up again, so that the non-running surface corresponding to the target device partition is transformed into the new running surface.

[0063] In this embodiment, after the image file is written to the physical storage path of the non-running plane, the vehicle needs to boot from this partition on the next startup, making this partition the new running plane.

[0064] First, a switching command needs to be sent to the bootloader on the vehicle side. This bootloader is responsible for selecting which slot to boot from when the system starts. After the firmware is flashed on the vehicle side, a switching command is sent through a specific interface to instruct the bootloader to select a non-running surface as the boot slot on the next startup. This ensures that the system will boot from the target device partition corresponding to the physical storage path after the image file is written on the vehicle side on the next startup.

[0065] The specific operational logic is to transform the non-operational surface corresponding to the target device partition into a new operating surface. After the vehicle successfully boots from the new partition, the partition becomes the new operating surface, and the original operating surface automatically becomes a non-operational surface for use in the next upgrade.

[0066] During the entire switching process, the partition node mapping table needs to be updated synchronously to ensure that when the system starts up again, the initialization script will re-detect the current running plane and update the soft links or mapping table to ensure that the logical partition name points to the new non-running plane (i.e., the old running plane), thus preparing for subsequent upgrades.

[0067] In summary, the above mechanism ensures that the original system remains unchanged during the upgrade process. The system will only switch to the new system after the upgrade is successful and the vehicle is restarted. Any upgrade failure will not affect the normal use of the vehicle, which greatly improves the reliability of OTA upgrades and the user experience.

[0068] This application provides a method for flashing vehicle firmware upgrade packages. The firmware upgrade package generated by the cloud server uses a standardized logical partition name as the unique index of the image file. To ensure lightweight information within the firmware upgrade package, the index name does not carry any physical storage node information. The vehicle independently maintains a partition node mapping table. This mapping table dynamically converts the logical partition name into a writable physical storage path based on the current system startup status. The vehicle only needs to query the mapping table to obtain a secure, writable non-running partition path. The cloud server does not need to be aware of the vehicle's current running state, thus eliminating the risk of accidentally writing to the currently running partition. Furthermore, because the logical partition name remains consistent across different vehicle models and partition naming rules, the same upgrade package can adapt to various hardware variants without modification, thereby eliminating the problems of multiple versions of packaging tools and operational mismatches caused by partition naming changes. This involves constructing a two-level abstraction layer for finding paths using logical partition names and partition node mapping tables. This completely decouples the upgrade business logic from the underlying partition layout. Regardless of whether the vehicle adopts a single partition, AB dual partition, or dynamic partition architecture, compatibility can be achieved simply by adjusting the implementation of the mapping table. The evolution of hardware partitioning schemes no longer requires a full-line linkage modification of upgrade tools or upgrade packages. This solves the technical problem of strong coupling between cloud firmware upgrade packages and the underlying physical paths of the vehicle in current in-vehicle OTA upgrade systems.

[0069] Please see Figure 3 , Figure 3 This is a flowchart illustrating a method for flashing a vehicle firmware upgrade package, as provided in an embodiment of this application.

[0070] like Figure 3 As shown, the vehicle firmware upgrade package flashing method can include at least the following: S110: Read the device partition identifier to which the current system boot partition belongs; S120. Using the logical partition name as an index, query the obtained partition node mapping table to obtain the physical storage path corresponding to the non-running surface relative to the device partition identifier; S130, wherein the partition node mapping table records the device partition identifiers of the dual device partitions of each logical partition, and records the physical storage paths corresponding to the two respectively; wherein, when the device partition identifier of one of the device partitions corresponds to the running surface, the device partition identifier of the other device partition corresponds to the non-running surface.

[0071] In this embodiment, a dual-device partition mapping scheme based on an A / B partitioning system is provided, which is particularly suitable for scenarios that require seamless upgrade support. In this scheme, the partition node mapping table records two physical storage paths for each logical partition, corresponding to the device partitions of the running plane and the non-running plane, respectively.

[0072] When a vehicle needs to determine the physical storage path of a non-running plane corresponding to a certain logical partition name, the following steps are performed: First, when the vehicle starts, the bootloader will pass the slot information of the current boot (such as slot_a or slot_b) to the operating system through the kernel command line or device tree, read the device partition identifier to which the current system boot partition belongs, and determine whether the current running plane is slot_a or slot_b.

[0073] Furthermore, using the logical partition name as an index, the system retrieves the physical storage path corresponding to the non-running plane that is the partition identifier of the current device. For example, if the current running plane is slot_a, then the non-running plane is slot_b. For the logical partition system, the system looks up the slot_b entry under system in the mapping table, obtaining the physical path / dev / mmcblk0p6. This path is the non-running plane partition (the physical storage path of the target device partition), which is the target write location for the firmware upgrade package.

[0074] Therefore, in this embodiment, the firmware upgrade package is always written to the non-operating plane, and the current operating plane is unaffected. Even if there is a power outage or an error occurs during the flashing process, the vehicle can still start normally from the original operating plane, achieving a safe upgrade (i.e., seamless upgrade of the A / B plane system). At the same time, since the mapping table clearly distinguishes the physical paths of the two slots, the system does not need to rely on external soft connection mechanisms and can directly obtain the target path by looking up the table, which greatly improves the system upgrade efficiency and reduces the complexity of writing the firmware upgrade package.

[0075] In this embodiment, a method for flashing a vehicle firmware upgrade package is provided. The method reads the device partition identifier of the currently booting partition to determine the current operating plane. Using a standardized logical partition name as an index, it queries the partition node mapping table to obtain the physical storage path corresponding to the non-operating plane opposite to the operating plane. Since the partition node mapping table pre-records the identifiers and physical paths of the dual device partitions corresponding to each logical partition, and explicitly stipulates that when one is an operating plane, the other is a non-operating plane, the vehicle can automatically locate the safe and writable target device partition without any external input or manual judgment. This allows the cloud server to completely avoid the current operating plane and the need to carry any physical path information in the firmware upgrade package. It can obtain the correct write target through a single mapping query, fundamentally avoiding the risk of system crashes due to miswriting the current operating partition. This completely decouples the upgrade business from the underlying physical storage, significantly improving the system's maintainability and architectural compatibility.

[0076] Please see Figure 4 , Figure 4 This is a flowchart illustrating a method for flashing a vehicle firmware upgrade package, as provided in an embodiment of this application.

[0077] like Figure 4 As shown, the vehicle firmware upgrade package flashing method can include at least the following: S21. Using the logical partition name as an index, determine the physical storage path of the target device partition that the preset soft link node in the obtained partition node mapping table is fixed to.

[0078] In this embodiment, symbolic links can be used to map logical partition names to physical storage paths based on the partition node mapping table. In the vehicle's operating system, a symbolic link is a special file system object that points to another file or directory. In this embodiment, this characteristic is utilized to map each standardized logical partition name to a symbolic link, and through this fixed symbolic link, the physical storage path corresponding to the current target device partition is directly locked, reducing the complexity of querying the partition node mapping table.

[0079] Specifically, in vehicles that support the A / B partition scheme, the system typically has two complete system partitions (such as system_a and system_b). The partition where the system currently running on the vehicle is located is called the active slot, and the other is called the inactive slot. Firmware upgrade packages usually need to be written to the inactive slot so that they can be switched on the next boot.

[0080] Typically, the initialization process determines whether the current running plane is A or B by reading the kernel command-line parameters passed by the bootloader or by reading specific hardware registers, thereby obtaining the partition identifier of the non-running plane.

[0081] Furthermore, assuming the standardized logical partition name `system` needs to point to the system partition of a non-running plane, and the current running plane is A, its corresponding partition node for the `system` partition is ` / dev / disk / system_a`. The non-running plane is B, and its corresponding target device partition node is ` / dev / disk / system_b`. This mapping relationship typically alternates with system switching between planes A and B. Therefore, the vehicle-side mapping table will have two parts: A->B and B->A. Based on this, we found that distinguishing based on the actual physical partition each time makes the vehicle-side configuration relatively complex.

[0082] Therefore, at system startup, a pair of symbolic links, / dev / disk / system_active and / dev / disk / system_inactive (similar to shortcut files), are added. This pair of symbolic links always points to the running and non-running sides of the system partition. So, whether the system is running on side A or side B, we can use / dev / disk / system_active as the physical storage path of the device partition corresponding to the running side and / dev / disk / system_inactive as the physical storage path of the target device partition when flashing.

[0083] It should be noted that the advantage of using symbolic links is that the symbolic link mechanism is a feature natively supported by the operating system kernel, eliminating the need to develop complex mapping query logic. In addition, symbolic links can be viewed and debugged by standard file system tools, making it easier for operations and maintenance personnel to check whether the mapping relationship is correct.

[0084] Furthermore, when the physical storage path needs to be changed (e.g. due to partition table reconstruction), only the target of the symbolic link needs to be updated, without requiring any modification to the application code.

[0085] In this embodiment, before the step of querying the obtained partition node mapping table for a physical storage path that matches a preset soft link node using the logical partition name as an index, the method further includes: Each time the system starts on the vehicle, the target device partition that is not running on the vehicle is identified, and a soft link node is generated that points to the physical storage path of the target device partition. Update the obtained partition node mapping table based on the changes in the path pointed to by the soft link node.

[0086] In this embodiment, the vehicle executes an initialization script or daemon process each time the system is started. This process is responsible for detecting the current system partition layout and generating soft link nodes corresponding to the logical partition names.

[0087] Specifically, in this embodiment, the symbolic link nodes are set to system_active and system_inactive, respectively. system_active always points to the currently running system partition, and system_inactive always points to another non-running partition. The specific dynamic update process is as follows: When the current running plane is A, the initialization process points the system_active symbolic link to the physical partition system_a and the system_inactive symbolic link to the physical partition system_b. At this time, system_active represents the running plane partition, and system_inactive represents the non-running plane partition to be upgraded.

[0088] When the current running plane is B, the initialization process sets the system_active symbolic link to point to the physical partition system_b, and the system_inactive symbolic link to point to the physical partition system_a. At this time, system_active represents the B-side partition, and system_inactive represents the A-side partition.

[0089] Understandably, the pointer relationships of the aforementioned soft link nodes automatically switch with the running state when the system starts up, thereby ensuring that at any time, system_inactive accurately points to the target partition that is not currently running, which can be directly used by the upgrade module. This dynamic update process does not require maintaining an additional mapping table, nor does it require the upgrade logic to judge the current running state; it can be completed simply by rebuilding the soft link nodes based on their properties.

[0090] In summary, by dynamically generating mapping relationships each time the system starts, it can automatically adapt to changes in partition layout caused by switching of vehicle-side operating systems (such as A / B slot switching), ensuring that soft connection nodes point to the correct operating plane and that the partition node mapping table always reflects the current actual physical storage layout without manual intervention.

[0091] In this embodiment, a method for flashing a vehicle firmware upgrade package is provided. Using standardized logical partition names as indexes, the physical storage path of the target device partition, which is fixedly pointed to by a pre-set soft link node, is directly obtained from the partition node mapping table. This soft link node dynamically updates its pointer based on the current operating plane when the vehicle starts up and remains fixed. This eliminates the need for the vehicle to re-determine the current operating plane or calculate the location of non-operating partitions in real time during upgrade operations. Instead, it only needs to query the fixed pointer of the corresponding soft link node in the mapping table using the logical partition name to resolve the corresponding physical storage path. This decouples the operating plane identification from the target device partition location process, avoiding the overhead of repeatedly determining the operating plane for each upgrade and eliminating the risk of misjudging the target partition due to changes in the operating plane state. This further improves the determinism and reliability of the upgrade process.

[0092] Based on the above embodiments, specific application implementation examples are provided as follows: By binding image files with standardized partitions as logical indexes in the cloud upgrade package, and storing a dynamic mapping table between partitions and physical device nodes in the vehicle-side safety element, the client automatically parses the target device partition based on the current running plane, achieving complete decoupling between cloud configuration and vehicle-side hardware. This enables firmware upgrade packages to automatically adapt across vehicle models, naming rules, and A / B planes, while eliminating the problems of fragmented packaging toolchains and chaotic operation and maintenance configurations.

[0093] The firmware upgrade package provided by the cloud server uses a structured JSON format and only uses standardized logical partition names as unique indexes, completely masking the physical device path. Partition: boot, partition: system, partition: vendor; Source: ota / boot.img, source: ota / system.img, source: ota / vendor.img; Target: ota / boot.img, target: ota / system.img, target; ota / vendor.img.

[0094] Vehicle-side mapping table (securely stored in SE) — Physical implementation layer The vehicle-side system pre-configures and encrypts the storage of a "logical partition-physical device" mapping table within the Secure Element (SE). Partition: boot, partition: system, partition: vendor; Source: / dev / disk / boot_a, source: / dev / disk / system_a, source: / dev / disk / vendor_a; Target: / dev / disk / boot_b, target: / dev / disk / system_b, target; / dev / disk / vendor_b.

[0095] The specific system upgrade process (automatic closed loop on the client side) is as follows: (1) The client reads the currently booted partition and determines the running plane; (2) Search for the corresponding target device partition in the local mapping table based on the partition index; (3) Download the corresponding partition image file from the cloud; (4) Write the image to the target device (non-running plane); (5) After the upgrade is completed, switch to the target device partition to start via Bootloader.

[0096] In summary, in this embodiment, the firmware upgrade package of the cloud server uses a standardized partition as the unique logical index, which is bound to the image file path and does not contain any vehicle-side physical device node information. Simultaneously, the vehicle-side secure element stores a mapping table between partitions and physical device nodes. This mapping table is initialized by the vehicle-side firmware and supports secure updates via digital signatures. Before the client upgrades, the currently running partition is actively detected, and the target device partition is dynamically obtained from the local mapping table based on the partition index (determining the running and non-running planes). The non-running plane is selected and written into the corresponding required image file in the firmware upgrade package. This ensures that the generation and distribution of the firmware upgrade package of the cloud server do not depend on any vehicle-side hardware configuration information. All adaptation logic is completed by the vehicle-side local mapping table. Furthermore, the partition index is used for semantic positioning of the target device partition in the control word operation unit, achieving decoupling of instructions between the logic layer and the hardware layer.

[0097] It should be noted that any solution that uses a standardized logical partition as the sole semantic bridge for communication between the cloud and the vehicle, and combines it with a vehicle-side security mapping table to achieve dynamic binding of physical paths, regardless of its specific implementation, falls within the scope of protection of this patent.

[0098] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Figure 5 As shown, vehicle 500 may include: at least one vehicle processor 501, at least one network interface 504, user interface 503, memory 505, and at least one communication bus 502.

[0099] The communication bus 502 is used to enable communication between these components.

[0100] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0101] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0102] The vehicle processor 501 may include one or more processing cores. The vehicle processor 501 connects to various parts within the vehicle 500 via various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 505, and by calling data stored in memory 505. Optionally, the vehicle processor 501 may integrate one or more of the following: a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the vehicle processor 501 and may be implemented as a separate chip.

[0103] The memory 505 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned vehicle processor 501. Figure 5 As shown, the memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a vehicle firmware upgrade package flashing program.

[0104] exist Figure 5 In the vehicle 500 shown, the user interface 503 is mainly used to provide an input interface for the user and to obtain the user input data; while the vehicle processor 501 can be used to call the vehicle firmware upgrade package flashing program stored in the memory 505 to specifically execute the above-mentioned related method steps to implement the vehicle firmware upgrade package flashing method provided in the above embodiment.

[0105] Furthermore, this application also protects an apparatus. This embodiment can divide the apparatus into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0106] When each function is divided into modules corresponding to its specific function, the vehicle firmware upgrade package flashing device includes: The receiving module is used to receive firmware upgrade packages sent by the cloud server. The firmware upgrade package uses a predefined logical partition name as a unique index. The firmware upgrade package contains an image file corresponding to each logical partition name, and the logical partition name does not contain any node information pointing to the physical storage location on the vehicle. The determination module is used to determine the physical storage path of the target device partition corresponding to the logical partition name based on the obtained partition node mapping table; The update module is used to extract the image file corresponding to the logical partition name from the firmware upgrade package and write it to the storage area pointed to by the physical storage path.

[0107] Optionally, the determining module is also used to determine the physical storage path of the target device partition that is fixedly pointed to by the preset soft link node in the obtained partition node mapping table, using the logical partition name as an index.

[0108] Optionally, the determining module is also used to determine the target device partition in the non-running state on the vehicle side each time the system is started on the vehicle side, and generate a soft link node that points to the physical storage path of the target device partition. Update the obtained partition node mapping table based on the changes in the path pointed to by the soft link node.

[0109] Optionally, the determination module is also used to read the device partition identifier to which the current system boot partition belongs; Using the logical partition name as an index, the physical storage path corresponding to the non-running plane relative to the device partition identifier is retrieved from the obtained partition node mapping table; The partition node mapping table records the device partition identifiers of the dual-device partitions of each logical partition, and records the corresponding physical storage paths of the two. When the device partition identifier of one device partition corresponds to the running plane, the device partition identifier of the other device partition corresponds to the non-running plane.

[0110] Optionally, the determination module is also used to pre-install the partition node mapping table in the vehicle-side security element and store it encrypted.

[0111] Optionally, the vehicle firmware upgrade package flashing device also includes: an adjustment module for receiving a mapping table update data packet carrying a digital signature sent by a cloud server; The integrity of the digital signature is verified and its source is authenticated using the verification public key pre-installed in the security element at the vehicle end. After confirming the validity of the digital signature, the partition node mapping table stored in the secure element is replaced or incrementally updated to adapt to changes in the hardware partition topology of the vehicle or the need for adding new logical partitions.

[0112] Optionally, the vehicle firmware upgrade package flashing device also includes a switching module, which sends a switching command to the bootloader on the vehicle side, and boots from the target device partition corresponding to the physical storage path after the image file is written when the vehicle starts up next time, so that the non-running surface corresponding to the target device partition is transformed into a new running surface.

[0113] It should be understood that the device provided in this embodiment is used to execute the above-described vehicle firmware upgrade package flashing method, and therefore can achieve the same effect as the above-described implementation method.

[0114] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant program code.

[0115] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0116] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a vehicle firmware upgrade package flashing method provided in the above embodiments.

[0117] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement the vehicle firmware upgrade package flashing method provided in the above embodiment.

[0118] This embodiment also provides a computer program product. When the computer program product is run on a computer, it causes the computer to perform the above-mentioned related steps to realize the method for flashing a vehicle firmware upgrade package provided in the above embodiment.

[0119] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0120] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0121] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0122] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0123] 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 preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0124] In addition, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0125] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0126] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0127] The above is a description of a vehicle firmware upgrade package flashing method, apparatus, storage medium, and vehicle provided in this application. For those skilled in the art, based on the ideas of the embodiments of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for flashing vehicle firmware upgrade packages, characterized in that, The method includes: The firmware upgrade package is received from the cloud server. The firmware upgrade package uses a predefined logical partition name as a unique index. The firmware upgrade package contains an image file corresponding to each logical partition name, and the logical partition name does not contain any node information pointing to the physical storage location of the vehicle. Based on the obtained partition node mapping table, the physical storage path of the target device partition corresponding to the logical partition name is determined. The partition node mapping table is used to record the correspondence between the logical partition name and the physical storage path of each physical device partition on the vehicle side. The target device partition is the device partition that is not in operation among the physical device partitions. Extract the image file corresponding to the logical partition name from the firmware upgrade package and write it to the storage area pointed to by the physical storage path.

2. The method according to claim 1, characterized in that, The step of determining the physical storage path of the target device partition corresponding to the logical partition name based on the obtained partition node mapping table includes: Using the logical partition name as an index, the physical storage path of the target device partition that the preset soft link node in the obtained partition node mapping table is determined.

3. The method according to claim 2, characterized in that, Before the step of determining the physical storage path of the target device partition that a preset soft link node points to from the obtained partition node mapping table using the logical partition name as an index, the method further includes: Each time the system is started on the vehicle, the target device partition that is not in operation on the vehicle is identified, and a soft link node pointing to the physical storage path of the target device partition is generated. Update the obtained partition node mapping table based on the changes in the path pointed to by the soft link node.

4. The method according to claim 1, characterized in that, The step of determining the physical storage path of the target device partition corresponding to the logical partition name based on the obtained partition node mapping table further includes: Read the device partition identifier to which the current system boot partition belongs; Using the logical partition name as an index, the physical storage path corresponding to the non-running plane relative to the device partition identifier is retrieved from the obtained partition node mapping table; The partition node mapping table records the device partition identifiers of the dual device partitions of each logical partition, and records the physical storage paths corresponding to the two respectively; wherein, when the device partition identifier of one device partition corresponds to the running plane, the device partition identifier of the other device partition corresponds to the non-running plane.

5. The method according to claim 1, characterized in that, The partition node mapping table is pre-installed in the vehicle's security element and stored in encrypted form.

6. The method according to claim 1, characterized in that, After the step of extracting the image file corresponding to the logical partition name from the firmware upgrade package and writing it to the storage area pointed to by the physical storage path, the method further includes: Receive mapping table update data packets with digital signatures sent by the cloud server; The digital signature is verified for integrity and source authentication using a public key pre-installed in the vehicle's security element. After confirming the validity of the digital signature, the partition node mapping table stored in the secure element is replaced or incrementally updated to adapt to changes in the hardware partition topology of the vehicle or the need for adding new logical partitions.

7. The method according to claim 1, characterized in that, After the step of extracting the image file corresponding to the logical partition name from the firmware upgrade package and writing it to the storage area pointed to by the physical storage path, the method further includes: A switching command is sent to the bootloader on the vehicle side, and when the vehicle side starts up again, it boots from the target device partition corresponding to the physical storage path after the image file is written, so that the non-running surface corresponding to the target device partition is transformed into a new running surface.

8. A device for flashing vehicle firmware upgrade packages, characterized in that, The device includes: The receiving module is used to receive firmware upgrade packages sent by the cloud server. The firmware upgrade package uses a predefined logical partition name as a unique index. The firmware upgrade package contains image files corresponding to each logical partition name, and the logical partition name does not contain any node information pointing to the physical storage location of the vehicle. The determination module is used to determine the physical storage path of the target device partition corresponding to the logical partition name based on the obtained partition node mapping table. The partition node mapping table is used to record the correspondence between the logical partition name and the physical storage path of each physical device partition on the vehicle side. The target device partition is the device partition that is not in operation among the physical device partitions. The update module is used to extract the image file corresponding to the logical partition name from the firmware upgrade package and write it to the storage area pointed to by the physical storage path.

9. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 7.

Images