A universal OTA system, OTA upgrade method, and equipment

Abstract

This invention discloses a universal OTA system, OTA upgrade method, and device, relating to the field of OTA technology. The system includes a Hardware layer, a Firmware layer, and a System layer. The Hardware layer is used to select the boot mode and different storage media during the OTA process. The Firmware layer, based on ATF, is used to achieve hardware decoupling and determine the boot path selection and rollback mechanism. The System layer is used to implement upgrade package acquisition, upgrade package verification, upgrade package decompression, upgrade mode acquisition, partition data writing, and upgrade status maintenance. This application can meet the upgrade needs of integrated hardware and software upgrades, cross-domain integrated upgrades, open and compatible multi-platform upgrades, and security and stability upgrades, satisfying the upgrade requirements of different systems and platforms.

Description

Technical Field

[0001] This application relates to the field of OTA (Over-the-Air Technology) technology, specifically to a general OTA system and OTA upgrade method and equipment. Background Technology

[0002] Existing OTA technology solutions suffer from low versatility and poor flexibility. Furthermore, they consume significant R&D resources during project migration, leading to inefficiency.

[0003] Among them, the main reasons for the low universality of OTA are: (1) differences at the hardware level: the read and write characteristics and drivers of different storage media are completely different, and the addresses and sizes of Bootloader, firmware, recovery partition, configuration partition, etc. are different. A universal OTA package cannot know which address to write the data to; (2) complexity at the software and system level: many low-power MCU (microcontroller unit) devices run "bare-metal" programs, and their OTA mechanism needs to implement the entire differential, verification and rollback logic themselves. For real-time operating systems such as FreeRTOS, Zephyr, and RT-Thread, their kernel mechanisms, file systems and package management are different. For general operating systems such as Linux and Android, although Linux itself is relatively unified, each manufacturer will carry out deep customization (such as the ROMs of various Android manufacturers), resulting in differences in system partitions, services and underlying HAL (hardware abstraction layer) interfaces. At the same time, the update package format and protocol are not uniform, and some use Complete image files, some use differential / incremental packets to save traffic, differential algorithms (such as bsdiff, HDiffPatch) and their implementations are also different, the communication protocol in the OTA upgrade process may be HTTP / HTTPS, MQTT, CoAP or even the manufacturer's custom private protocol, there is no unified standard for the handshake, authentication, download and status reporting process between the server and the device; (3) different security mechanisms are implemented: for signature and verification, although asymmetric encryption (such as RSA, ECC) is used for signature verification, the certificate chain, root certificate, signature algorithm and strength used are determined by each manufacturer, a general OTA system cannot manage the private keys and certificates of all manufacturers, for secure boot, the device will verify the signature of the Bootloader and firmware when booting, the root certificate of this verification is hard-coded in the device and strongly bound to the manufacturer's OTA system, the general solution cannot intervene in this trust chain, for encrypted transmission and storage, the upgrade package may need to be encrypted when transmitted and stored, the encryption algorithm and key management scheme used are also different.

[0004] Therefore, how to provide a universal OTA solution to meet the upgrade needs of different systems and platforms has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a universal OTA system, OTA upgrade method, and device that can meet the upgrade needs of different systems and platforms, including integrated hardware and software upgrades, cross-domain integration upgrades, open and compatible multi-platform upgrades, and security and stability upgrades.

[0006] In a first aspect, embodiments of this application provide a universal OTA system, the universal OTA system comprising:

[0007] The Hardware layer is used to implement the boot method selection for the OTA process, as well as the selection of different storage media;

[0008] The Firmware layer, based on ATF, is used to achieve hardware decoupling, as well as to determine the boot path selection and rollback mechanism implementation;

[0009] The System layer is used to implement upgrade package acquisition, upgrade package verification, upgrade package decompression, upgrade mode acquisition, partition data writing, and upgrade status maintenance.

[0010] In conjunction with the first aspect, in one implementation method,

[0011] The Hardware layer includes a Secure ROM module, a Boot Pin module, and a Storage Media module;

[0012] The Secure ROM module is used to control the device to boot from the Default Location during normal startup and from the Non-Default Location during WDT reset, and controls the switching between Default Location startup and Non-Default Location startup through SBL;

[0013] The Boot Pin module is used to select the Storage Media to use via a DIP switch, and the device's ROM selects the corresponding Storage Driver for loading and initialization via the Boot Pin module;

[0014] The Storage Media module is used for storage and supports GPT partitioned storage and RAW format storage.

[0015] In conjunction with the first aspect, in one implementation method,

[0016] The firmware layer includes the SE_BootCtrl module and the OTA Storage Stack module;

[0017] The SE_BootCtrl module is used to select the boot SLOT based on the status information in the Metadata, switch the SLOT used in the ROM based on the selected boot SLOT, execute the number of restarts based on the Retry Counter when the firmware boot fails, and execute ROLLBACK when the Retry Counter is 0.

[0018] The OTA Storage Stack module is used to select the Storage path and call the corresponding Drive Hardware based on the Hardware layer's selection of the storage medium.

[0019] In conjunction with the first aspect, in one implementation method,

[0020] The System layer includes the Receiver module, Authenticator module, Extractor module, Parser module, Programmer module, and Transactor module;

[0021] The Receiver module is used to establish a secure connection with the OTA Server, download and receive upgrade packages, and connect to the PC via USB or ETH interface to obtain upgrade packages through ADB commands.

[0022] The Authenticator module is used to verify the legitimacy of the upgrade package using a certificate, to verify the integrity of the upgrade package using the HASH value contained in the certificate extension, and to calculate the HASH value after the upgrade package is written to the partition to verify the correctness of the written data.

[0023] The Extractor module is used to decompress the upgrade package to a specified location, and the decompression path is configurable. It also extracts data from the compressed upgrade package and supports a partition writing method while decompressing.

[0024] The Parser module is used to obtain the upgrade mode of the upgrade package from the INI file, and to obtain the version number and size of the upgrade package from the INI file. The upgrade mode includes full package upgrade and differential upgrade.

[0025] The Programmer module is used to call the general storage-lib library to write data to the partition, and supports writing in GPT and RAW formats. It also supports reading partition data and calculating the HASH value to verify the correctness of the write.

[0026] The Transactor module is used to complete the upgrade process by switching the SLOT, activate the upgrade SLOT, and collect the startup status of the upgrade SLOT.

[0027] In conjunction with the first aspect, in one implementation method,

[0028] The firmware layer also includes the SE_OTA Manager module;

[0029] The SE_OTA Manager module is used to implement OTA function scheduling during the OTA process.

[0030] In conjunction with the first aspect, in one implementation method,

[0031] The general OTA system also includes an APP layer;

[0032] The APP layer includes the EM module, SM module, and SE_OTA TOOL module;

[0033] The SE_OTA TOOL module is used to provide command-line tools;

[0034] The EM module and SM module are used to collect and manage the status of OTA execution, as well as to provide a UI display of the upgrade progress.

[0035] Secondly, embodiments of this application provide an OTA upgrade method, based on the aforementioned general OTA system implementation, the OTA upgrade method comprising:

[0036] The system layer receives the upgrade package, decompresses and verifies it, and obtains the version number, size and upgrade mode of the upgrade package. Then, it writes the upgrade package to the specified partition.

[0037] Perform SLOT switching and UFS LUN MAP switching, map the upgraded SLOT to the Default SLOT, and boot the system according to the upgraded SLOT;

[0038] Collect the startup status of each domain, and after confirming that each status upgrade is successful, update the Metadata status information to complete the OTA upgrade.

[0039] In conjunction with the second aspect, in one implementation, the step of receiving the upgrade package through the System layer, decompressing and verifying the upgrade package, obtaining the version number, size, and upgrade mode of the upgrade package, and then writing the upgrade package to the designated partition specifically includes:

[0040] The Receiver module in the System layer establishes a secure connection with the OTA Server, receives the compressed upgrade package, and stores it in a specified location;

[0041] The SE_OTA Manager module in the System layer decompresses the upgrade package according to the specified decompression path through the Extractor module in the System layer, and stores the upgrade package in the specified path after decompression.

[0042] The SE_OTA Manager module notifies the Authenticator module in the System layer to verify the legality and integrity of the upgrade package. Once the verification is successful, the SE_OTA Manager module notifies the Parser module in the System layer to obtain the version number, size, and upgrade mode of the upgrade package from the INI file.

[0043] The SE_OTA Manager module calls the general storage-lib library through the Programmer module in the System layer to write the upgrade package to the specified partition.

[0044] In conjunction with the second aspect, in one implementation, the SLOT switching operation and UFS LUN MAP switching, mapping the upgraded SLOT to the Default SLOT, and booting the system according to the upgraded SLOT, specifically includes:

[0045] The SE_OTA Manager module performs SLOT switching operations through the Transactor module in the System layer, and then restarts the system. At this time, the Secure ROM module starts from the Default SLOT.

[0046] Upon entering the SE_BootCtrl module in the Firmware layer, the SE_BootCtrl module performs a UFS LUN MAP switch based on the OTA Metadata status information and its own SLOT information, mapping the upgrade SLOT to the DefaultSLOT, and then reboots the system. At this point, the Secure ROM module boots from the Default Slot.

[0047] Enter the SE_BootCtrl module and follow the upgrade SLOT to start the system.

[0048] Thirdly, this application provides an OTA upgrade device, which includes a processor, a memory, and an OTA upgrade program stored in the memory and executable by the processor. When the OTA upgrade program is executed by the processor, it implements the steps of the OTA upgrade method described above.

[0049] The beneficial effects of the technical solutions provided in this application include:

[0050] It provides a general OTA architecture that can meet the upgrade needs of integrated hardware and software, cross-domain integration, open and compatible multi-platform upgrades, as well as security and stability upgrades. It can meet the upgrade needs of different systems and platforms, and can be easily integrated and deployed on different project platforms, effectively saving R&D resources and improving R&D efficiency. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of the structure of the general OTA system of this application;

[0052] Figure 2 This is a flowchart of the OTA upgrade method for this application;

[0053] Figure 3 This is a schematic diagram of the hardware structure of the OTA upgrade device in this application. Detailed Implementation

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

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0056] In a first aspect, embodiments of this application provide a universal OTA system to meet the goals of integrated hardware and software upgrades, cross-domain integrated upgrades, open and compatible multi-platform upgrades, and security and stability upgrades.

[0057] In one embodiment, reference is made to Figure 1 , Figure 1 This is a schematic diagram of the structure of the general OTA system of this application. For example... Figure 1 As shown, a general OTA system includes: Hardware layer, Firmware layer, System layer, and APP layer. Figure 2 In this context, Linux Kernel refers to the Linux kernel, Hypervisor refers to the virtual machine monitoring program, UFSDriver refers to the general-purpose flash memory driver, QSPI Flash Driver refers to the QSPI Flash driver, and eMMC Driver refers to the embedded storage driver.

[0058] The Hardware layer is used to select the boot method and different storage media during the OTA process; the Firmware layer, based on ATF, is used to achieve hardware decoupling, determine the boot path selection, and implement the rollback mechanism; the System layer is used to implement upgrade package acquisition, upgrade package verification, upgrade package decompression, upgrade mode acquisition, partition data writing, and upgrade status maintenance. ATF, or Arm Trusted Firmware, is the core software foundation for Secure Boot and Trusted Execution Environment (TEE) under the Arm architecture.

[0059] In this application, the Hardware layer includes a Secure ROM module, a Boot Pin module, and a Storage Media module.

[0060] The Secure ROM module controls the device (device or system undergoing PTA upgrade) to boot from the Default Location during normal startup and from the Non-Default Location when a WDT (Watchdog Timer) reset occurs. The switching between Default Location and Non-Default Location boot is controlled via the SBL (Secondary Boot Loader). The Secure ROM module stores the power-on boot program and serves as the root of trust for the entire chip.

[0061] The Boot Pin module is used to select the Storage Media to use via a DIP switch, and the device's ROM (Read-Only Memory) is loaded and initialized by selecting the corresponding Storage Driver through the Boot Pin module.

[0062] The Storage Media module is used to implement storage, supporting GPT partitioning (a disk partitioning scheme based on the EFI standard) storage and RAW format storage.

[0063] Specifically, for the hardware layer, as long as the design supports the Secure ROM module, BootPin module, and Storage Media module required for OTA, the OTA architecture described in this application can be supported. The Secure ROM module's role in OTA is to ensure that the bootloader (firmware) upgrade will not brick the device if it fails; the BootPin module's role in OTA is to support the selection of different storage media. As long as both the Secure ROM module and the BootPin module are supported, the universality of hardware-level support for OTA functions can be guaranteed.

[0064] In this application, the Firmware layer includes the SE_BootCtrl module (boot control module) and the OTA StorageStack module (OTA storage function software stack module).

[0065] The SE_BootCtrl module is used to select the boot SLOT based on the status information in the metadata, switch the SLOT used in the ROM according to the selected boot SLOT, perform a reboot count based on the RetryCounter when the firmware boot fails, and perform a ROLLBACK when the Retry Counter is 0.

[0066] The OTA Storage Stack module is used to select the Storage path based on the Hardware layer's choice of storage media and call the corresponding Drive Hardware.

[0067] Specifically, for the firmware layer, as long as it's based on ATF and includes the SE_BootCtrl module and the OTA StorageStack module, the OTA architecture described in this application can be supported. The OTA StorageStack module achieves hardware decoupling, allowing OTA to read and write partitions directly by calling the general interfaces ota_write and ota_read, regardless of the specific storage medium. The SE_BootCtrl module is the control center for OTA during the underlying firmware boot phase, determining the boot path selection and rollback mechanism. Supporting these two modules ensures the universality of OTA functionality support at the firmware layer.

[0068] In this application, the System layer includes the Receiver module (upgrade package receiving module), the Authenticator module (upgrade package authentication module), the Extractor module (upgrade package decompression module), the Parser module (upgrade package parsing module), the Programmer module (upgrade package writing module), and the Transactor module (SLOT switching and activation module, responsible for switching SLOTs and restarting). By designing these modules in the System layer with high cohesion and loose coupling, they are independent of specific system implementations and provide a unified API (Application Programming Interface). These interfaces are compiled into .a libraries (static libraries) or .so libraries (dynamic libraries), facilitating integration into operating systems such as Android, Ubuntu, and FreeRTOS.

[0069] The Receiver module is used to establish a secure connection with the OTA server, download and receive upgrade packages, and connect to a PC (personal computer) via USB (Universal Serial Bus) or ETH (Ethernet) interface to obtain upgrade packages using ADB (Advanced Deployment Tool) commands. In other words, the Receiver module supports establishing a secure connection with the OTA server, downloading and receiving upgrade packages, and connecting to a PC via USB or ETH interface to obtain upgrade packages using ADB commands.

[0070] Specifically, the Receive module encapsulates communication protocols through an abstraction layer, supporting network communication protocols including HTTP / HTTPS, MQTT, and CoAP, as well as USB protocol, facilitating upgrade package download and debugging by developers via PC. Encapsulating the communication protocol decouples the upgrade business logic from the communication protocol. It supports a unified upgrade format and can convert to the required format as needed. For example, if the received upgrade package is in VPX format, the module's format conversion function can remove the VPX header, restoring the original upgrade package format; for example, firmware can be restored to its original binary format, and systems or applications to .so or .a library formats. Furthermore, it supports both full-package and differential package upgrades, distinguishing between them based on the parsed configuration file. As long as the System layer supports this module, upgrade package reception can be universally applicable.

[0071] The Authenticator module is used to verify the legitimacy of upgrade packages using certificates, to verify the integrity of upgrade packages using the hash value contained in the certificate extension, and to calculate the hash value after the upgrade package is written to the partition to verify the correctness of the written data. In other words, the Authenticator module can verify the legitimacy of upgrade packages using Secure Boot ROTPK+509V3 certificates, and can also verify the integrity of upgrade packages using the hash value contained in the certificate extension. It also supports calculating the hash value after the upgrade package is written to the partition to verify the correctness of the written data.

[0072] Specifically, the Authenticator module uses a Level 2 509V3 standard certificate to verify the legitimacy of OTA upgrade packages. The root certificate is the same as that used in Secure Boot, simplifying root certificate management. The 509V3 certificate's extensions store the upgrade package's hash value for verifying its integrity. The Authenticator module achieves universality through the 509V3 certificate; wherever this module is deployed, authentication functionality can be universally applied.

[0073] The Extractor module is used to decompress upgrade packages to a specified location, with configurable decompression paths, and to extract data from compressed upgrade packages, supporting simultaneous decompression and partition writing. In other words, the Extractor module supports decompressing various upgrade package types such as ZIP and RAR to a specified location, with configurable decompression paths, and also supports extracting data from compressed upgrade packages while simultaneously decompressing and writing to partitions.

[0074] The Parser module is used to obtain the upgrade mode of the upgrade package from the INI file (initialization file), as well as the version number and size of the upgrade package from the INI file. The upgrade mode includes full package upgrade and differential upgrade.

[0075] Specifically, the Parser module decouples configuration-related information from business logic. Upgrade mode, upgrade version, upgrade package size, partition information, OTA server address, timeout, and retry policy can all be obtained by parsing the configuration file using the Parser module. The Parser module's functionality facilitates OTA deployment and general management and maintenance.

[0076] The Programmer module is used to call the general storage-lib library (a storage library compatible with UFS, EMMC, and QSPI) to write data to partitions. It supports writing in GPT and RAW formats and can read partition data and calculate hash values ​​to verify the correctness of the write.

[0077] Specifically, the Programmer module obtains partition information from the configuration file parsed by the Parser module, and then writes the upgrade package to each partition according to the partition information using API functions of the general storage-lib library. The Programmer module decouples the write function from the partition information, achieving generalization (generally, the partition information is embedded within the Programmer module). The general storage-lib library decouples the write function from the specific hardware storage medium, achieving generalization.

[0078] The Transactor module is used to complete the upgrade process by switching SLOTs, activating the upgrade SLOT, and collecting the startup status of the upgrade SLOT. After collecting the startup status of the upgrade SLOT, if the upgrade is successful, it reports the status upwards and sets an upgrade end flag; if the upgrade fails, it reports the status upwards and waits for a rollback.

[0079] Specifically, the Transactor module is responsible for maintaining the upgrade status and interacts with the SE_BootCtrl module in the firmware layer to jointly manage the same array of OTA upgrade status information structures.

[0080] Furthermore, the Firmware layer also includes the SE_OTA Manager module, which is used to implement OTA function scheduling during the OTA process. It should be noted that the SE_OTA Manager module is optional. OTA functions can be implemented through internal scheduling by calling the SE_OTA Manager module, or users can organize OTA function scheduling themselves as needed by calling standard APIs, or implement OTA function scheduling by writing scripts based on the executable commands of SE_OTA_Tool (OTA tool).

[0081] In this application, the APP layer includes the EM module (execution management module), the SM module (status management module), and the SE_OTATOOL module (OTA tool module); the SE_OTA TOOL module is used to provide command-line tools; the EM module and the SM module are used to provide OTA execution status collection and management, as well as UI display of upgrade progress.

[0082] It should be noted that the EM module, SM module, and SE_OTA TOOL module in the APP layer are all optional modules. The SE_OTA TOOL module is used to provide command-line tools, allowing users to schedule OTA functions by writing scripts. The EM module and SM module are used to provide status management for OTA execution and to provide UI (interface) display of upgrade progress.

[0083] The SE_OTA TOOL module includes Command (executable instructions or actions), Parameter (optional or required input items for the command, used to pass additional information or configuration), and Description (providing a detailed description of the command or parameter), as shown in Table 1 below.

[0084] Table 1

[0085]

[0086] EM, or Execute Management, is a service responsible for the execution of OTA and other services; SM, or Status Management, is a service responsible for collecting the status of OTA and other services, which can be used for diagnostics and other purposes.

[0087] For each module in the general OTA system of this application, users can flexibly customize relevant modules according to the needs of different platforms and different business scenarios. Through the scheduling and cooperation of these modules, a general OTA function can be realized. This application is a highly cohesive, loosely coupled, configurable, and easily extensible general OTA architecture. Through this general OTA system, the OTA development work on new platforms will be simplified to: implementing (or reusing) the Hardware layer + implementing (or reusing) the Firmware layer + system configurable layer (defining and selecting modules, updating configuration files).

[0088] Secondly, this application also provides an OTA upgrade method based on the above-described general OTA system implementation.

[0089] In one embodiment, reference is made to Figure 2 , Figure 2 This is a flowchart of the OTA upgrade method for this application. Figure 2 As shown, OTA upgrade methods include:

[0090] S1: Receive the upgrade package through the System layer, decompress and verify the upgrade package, obtain the version number, size and upgrade mode of the upgrade package, and then write the upgrade package to the specified partition;

[0091] S2: Perform SLOT switching operation and UFS (Universal Flash Storage) LUN MAP (Logical Unit Number Mapping) switching, map the upgraded SLOT to the Default SLOT (non-upgrade slot), and start the system according to the upgraded SLOT;

[0092] S3: Collects the startup status of each domain, confirms successful upgrades for each status, updates the metadata status information, and completes the OTA upgrade. The entire OTA upgrade process is completed through the cooperation of various modules in the general OTA system. The SE_OTA Manager module is the coordination and control center for OTA. Throughout the upgrade process, the SM module can obtain upgrade status information at any time, the EM module is responsible for triggering OTA functions, and the SE_OTA Tool module is the tool embodiment of the SE_OTA_Manager module's functions and can be run via command line.

[0093] Furthermore, in one embodiment, the upgrade package is received through the System layer, and the upgrade package is decompressed and verified, and the version number, size, and upgrade mode of the upgrade package are obtained. Then, the upgrade package is written to a specified partition, specifically including:

[0094] S101: The Receiver module in the System layer establishes a secure connection with the OTA Server, receives the compressed upgrade package, and stores it in a specified location;

[0095] S102: The SE_OTA Manager module in the System layer decompresses the upgrade package according to the specified decompression path through the Extractor module in the System layer, and stores the upgrade package in the specified path after decompression.

[0096] S103: The SE_OTA Manager module notifies the Authenticator module in the System layer to verify the legality and integrity of the upgrade package. After the verification is successful, the SE_OTA Manager module notifies the Parser module in the System layer to obtain the version number, size and upgrade mode of the upgrade package from the INI file.

[0097] S104: The SE_OTA Manager module calls the generalstorage-lib library through the Programmer module in the System layer to write the upgrade package to the specified partition.

[0098] Furthermore, in one embodiment, the SLOT switching operation and UFS LUN MAP switching are performed, mapping the upgraded SLOT to the Default SLOT, and the system is started according to the upgraded SLOT. Specifically, this includes:

[0099] S201: The SE_OTA Manager module performs SLOT switching operations through the Transactor module in the System layer, and then restarts the system. At this time, the Secure ROM module starts from the Default SLOT.

[0100] S202: Enter the SE_BootCtrl module in the Firmware layer. The SE_BootCtrl module completes the UFS LUN MAP switch based on the OTA Metadata status information and its own SLOT information, maps the upgrade SLOT to the DefaultSLOT, and then restarts the system. At this time, the Secure ROM module starts from the Default Slot.

[0101] S203: Enter the SE_BootCtrl module and start the system according to the upgrade SLOT.

[0102] It's important to note that ROM and firmware components generally share commonality across different products from the same company. Therefore, the Secure ROM module and the SE_BootCtrl and OTA_Storage Stack modules within the firmware are essentially interchangeable. System-level modules utilize the se_otalib.so or se_otalib.a library, allowing for easy deployment on systems such as Android, Ubuntu, AutoSAR, and Hypervisor. Supporting integrated hardware and software upgrades means that updating the eFuse via OTA, along with the upgrade software, can activate certain new hardware features (changing the eFuse is equivalent to changing the hardware). Cross-domain upgrades refer to multi-domain scenarios based on a SoC, where the SE_OTA_Manager module and other modules are deployed in one domain (e.g., the Android domain). However, while completing an Android upgrade, the SE_OTA_Manager module can simultaneously upgrade other domains such as Ubuntu Linux and RTOS.

[0103] Thirdly, embodiments of this application provide an OTA upgrade device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0104] Reference Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of the OTA upgrade device involved in the embodiments of this application. In the embodiments of this application, the OTA upgrade device may include a processor, a memory, a communication interface, and a communication bus.

[0105] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0106] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components within the OTA upgrade device, as well as interfaces used for interconnecting the OTA upgrade device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0107] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0108] The processor can be a general-purpose processor, which can call the OTA upgrade program stored in the memory and execute the OTA upgrade method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the OTA upgrade program is called can be referred to in the various embodiments of the OTA upgrade method of this application, and will not be repeated here.

[0109] Those skilled in the art will understand that Figure 3 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0110] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0111] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0112] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0113] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0114] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0115] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A universal OTA system, characterized in that, The general OTA system includes: The Hardware layer is used to implement the boot method selection for the OTA process, as well as the selection of different storage media; The Firmware layer, based on ATF, is used to achieve hardware decoupling, determine boot path selection, and implement rollback mechanisms. ATF is the core software foundation for secure boot and trusted execution environments under the Arm architecture. The System layer is used to implement upgrade package acquisition, upgrade package verification, upgrade package decompression, upgrade mode acquisition, partition data writing, and upgrade status maintenance. The Hardware layer includes a Secure ROM module, a Boot Pin module, and a Storage Media module. The Secure ROM module is used to control the device to boot from the Default Location during normal startup, and to boot from the Non-Default Location during WDT reset. It also controls the switching between Default Location startup and Non-Default Location startup via SBL. The Boot Pin module is used to select the Storage Media to use via a DIP switch, and the device's ROM selects the corresponding Storage Driver for loading and initialization via the Boot Pin module; The Storage Media module is used to implement storage, supporting GPT partitioned storage and RAW format storage; The Firmware layer includes the SE_BootCtrl module and the OTA Storage Stack module; The SE_BootCtrl module is used to select the boot SLOT based on the status information in the Metadata, switch the SLOT used in the ROM based on the selected boot SLOT, execute the number of restarts based on the Retry Counter when the firmware boot fails, and execute ROLLBACK when the Retry Counter is 0. The OTA Storage Stack module is used to select the Storage path and call the corresponding Drive Hardware based on the Hardware layer's selection of the storage medium.

2. The universal OTA system as described in claim 1, characterized in that: The System layer includes the Receiver module, Authenticator module, Extractor module, Parser module, Programmer module, and Transactor module; The Receiver module is used to establish a secure connection with the OTA Server, download and receive upgrade packages, and connect to the PC via USB or ETH interface to obtain upgrade packages through ADB commands. The Authenticator module is used to verify the legitimacy of the upgrade package using a certificate, to verify the integrity of the upgrade package using the HASH value contained in the certificate extension, and to calculate the HASH value after the upgrade package is written to the partition to verify the correctness of the written data. The Extractor module is used to decompress the upgrade package to a specified location, and the decompression path is configurable. It also extracts data from the compressed upgrade package and supports a partition writing method while decompressing. The Parser module is used to obtain the upgrade mode of the upgrade package from the INI file, and to obtain the version number and size of the upgrade package from the INI file. The upgrade mode includes full package upgrade and differential upgrade. The Programmer module is used to call the general storage-lib library to write data to the partition, and supports writing in GPT and RAW formats. It also supports reading partition data and calculating the HASH value to verify the correctness of the write. The Transactor module is used to complete the upgrade process by switching the SLOT, activate the upgrade SLOT, and collect the startup status of the upgrade SLOT.

3. A universal OTA system as described in claim 2, characterized in that: The firmware layer also includes the SE_OTA Manager module; The SE_OTA Manager module is used to implement OTA function scheduling during the OTA process.

4. A universal OTA system as described in claim 1, characterized in that: The general OTA system also includes an APP layer; The APP layer includes the EM module, SM module, and SE_OTA TOOL module; The SE_OTA TOOL module is used to provide command-line tools; The EM module and SM module are used to collect and manage the status of OTA execution, as well as to provide a UI display of the upgrade progress.

5. An OTA upgrade method, based on a system implementation of a universal OTA as described in any one of claims 1 to 4, characterized in that, The OTA upgrade method includes: The system layer receives the upgrade package, decompresses and verifies it, and obtains the version number, size and upgrade mode of the upgrade package. Then, it writes the upgrade package to the specified partition. Perform SLOT switching and UFS LUN MAP switching, map the upgraded SLOT to the Default SLOT, and boot the system according to the upgraded SLOT; Collect the startup status of each domain, and after confirming that each status upgrade is successful, update the Metadata status information to complete the OTA upgrade.

6. The OTA upgrade method as described in claim 5, characterized in that, The process of receiving the upgrade package through the System layer, decompressing and verifying the upgrade package, obtaining the version number, size, and upgrade mode of the upgrade package, and then writing the upgrade package to the specified partition specifically includes: The Receiver module in the System layer establishes a secure connection with the OTA Server, receives the compressed upgrade package, and stores it in a specified location; The SE_OTA Manager module in the System layer decompresses the upgrade package according to the specified decompression path through the Extractor module in the System layer, and stores the upgrade package in the specified path after decompression. The SE_OTA Manager module notifies the Authenticator module in the System layer to verify the legality and integrity of the upgrade package. Once the verification is successful, the SE_OTA Manager module notifies the Parser module in the System layer to obtain the version number, size, and upgrade mode of the upgrade package from the INI file. The SE_OTA Manager module calls the general storage-lib library through the Programmer module in the System layer to write the upgrade package to the specified partition.

7. An OTA upgrade method as described in claim 6, characterized in that, The process of performing SLOT switching and UFS LUN MAP switching, mapping the upgraded SLOT to the Default SLOT, and booting the system according to the upgraded SLOT, specifically includes: The SE_OTA Manager module performs SLOT switching operations through the Transactor module in the System layer, and then restarts the system. At this time, the Secure ROM module starts from the Default SLOT. Upon entering the SE_BootCtrl module in the Firmware layer, the SE_BootCtrl module performs a UFS LUN MAP switch based on the OTA Metadata status information and its own SLOT information, maps the upgraded SLOT to the Default SLOT, and then restarts the system. At this time, the Secure ROM module boots from the Default Slot. Enter the SE_BootCtrl module and follow the upgrade SLOT to start the system.

8. An OTA upgrade device, characterized in that, The OTA upgrade device includes a processor, a memory, and an OTA upgrade program stored in the memory and executable by the processor, wherein when the OTA upgrade program is executed by the processor, it implements the steps of an OTA upgrade method as described in any one of claims 5 to 7.

Images