WO2023216845A1 - 嵌入式设备固件更新方法、嵌入式设备、开发端设备 - Google Patents

嵌入式设备固件更新方法、嵌入式设备、开发端设备 Download PDF

Info

Publication number
WO2023216845A1
WO2023216845A1 PCT/CN2023/089849 CN2023089849W WO2023216845A1 WO 2023216845 A1 WO2023216845 A1 WO 2023216845A1 CN 2023089849 W CN2023089849 W CN 2023089849W WO 2023216845 A1 WO2023216845 A1 WO 2023216845A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
update
firmware
partition
information
Prior art date
Application number
PCT/CN2023/089849
Other languages
English (en)
French (fr)
Inventor
王豫新
巫建刚
徐春光
Original Assignee
乐鑫信息科技（上海）股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 乐鑫信息科技（上海）股份有限公司 filed Critical 乐鑫信息科技（上海）股份有限公司
Publication of WO2023216845A1 publication Critical patent/WO2023216845A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping

Definitions

  • the present application relates to the field of embedded technology, and in particular, to an embedded device firmware update method, an embedded device, a development device, and an embedded device firmware update system.
  • the FOTA Firmware Over the Air
  • IoT devices can not only improve functions and eliminate system loopholes, but also provide differentiated services to different users, making products more popular in the market.
  • this application provides an embedded device firmware update method, which is applied to the embedded device.
  • the embedded device includes a boot loader and a firmware update acquisition program; the boot loader stores In the boot loader partition, the firmware update acquisition program is stored in the corresponding firmware partition, wherein the firmware update acquisition program includes an update trigger module and a data receiving module, the boot loader includes a data processing module, and the method includes :
  • the update trigger module detects a trigger event for updating the firmware of the embedded device
  • the data receiving module obtains transmission data from the source device, and the transmission data at least includes update data for the embedded device to perform firmware updates and update method information identifying the update method used for this firmware; convert the update data to Write to the partition where the transferred data is stored; and
  • the data processing module processes the received update data according to the update mode information to obtain new firmware data, so that the new firmware data can be applied from the partition where the new firmware data is stored during running of the boot loader.
  • the update data is patch data.
  • the data processing module processes the received update data to obtain new firmware data including:
  • the data processing module processes the received update data and obtains new firmware data, it also includes:
  • the data processing module writes the new firmware data to the partition storing the new firmware data, and sets the partition storing the new firmware data as the partition to be booted, so that the partition to be booted can be loaded from the partition to be booted during running of the boot loader. Apply the new firmware data.
  • the data processing module differentially decodes the received patch data and old firmware data to obtain new firmware data, it also includes:
  • the data processing module obtains the version verification information or summary verification information of the old firmware data from the transmission data; and determines whether the patch data is the same as the old firmware data based on the version verification information or summary verification information. match;
  • the update data is compressed data.
  • the data processing module processes the received update data to obtain new firmware data including:
  • the data processing module processes the received update data and obtains new firmware data, it also includes:
  • the data processing module writes the new firmware data to the partition storing the new firmware data, and sets the partition storing the new firmware data as the partition to be booted, so that the partition to be booted can be loaded from the partition to be booted during running of the boot loader. Apply the new firmware data.
  • the update data is new firmware data
  • the partition storing the transmission data is the partition storing the new firmware data
  • the update trigger module detects a trigger event for updating the firmware of the embedded device including:
  • the update triggering module receives the push information that the version of the firmware sent by the source device is updated
  • the update triggering module sends a query request to the source device to determine whether there is an updated version of the firmware, and receives a reply message sent by the source device indicating that there is an updated version of the firmware.
  • the data receiving module obtains the transmission data from the source device, it also includes:
  • the data receiving module determines whether the received transmission data is encapsulated data; such as If yes, the update method information is obtained from the transmission data, and the update method adopted for this firmware is determined.
  • the data receiving module writes the update data to the partition storing the transmission data, it also includes:
  • the data receiving module determines whether the update data has been encrypted; if so, the update data is decrypted according to the encryption type information in the transmission data.
  • the data receiving module writes the update data to the partition storing the transmission data, it also includes:
  • the data receiving module verifies whether the received update data is complete based on the integrity verification parameter information in the transmission data.
  • the data receiving module writes the update data to the partition storing the transmission data, it also includes:
  • the data receiving module sets the partition where the transmission data is stored as a partition to be booted, so that the data processing module obtains the transmission data from the partition where the transmission data is stored.
  • the data processing module before applying the new firmware data from the partition where the new firmware data is stored during running of the boot loader, the data processing module further includes:
  • the data processing module obtains file header information from the transmission data and verifies the file header information.
  • the data processing module before applying the new firmware data from the partition where the new firmware data is stored during running of the boot loader, the data processing module further includes:
  • the data processing module obtains the signature information of the update data from the transmission data, and verifies the signature information.
  • the data processing module applies the new firmware data from the partition where the new firmware data is stored during running of the bootloader, it further includes:
  • the data processing module obtains integrity verification parameter information from the transmission data, and verifies whether the data written to the partition storing new firmware data is complete.
  • the data processing module obtains the integrity check from the transmission data.
  • Parameters after verifying whether the data written to the partition storing the new firmware data is complete, also include:
  • the data processing module performs the operation of setting the partition storing the new firmware data as the partition to be booted; if the integrity check fails, the data processing module does not perform the operation of setting the partition storing the new firmware data as the partition to be booted. The operation of setting the partition storing new firmware data as the partition to be booted.
  • This application also provides an embedded device, including: a first memory and a first processor, the first memory is used to store a computer program, and the first processor is used to implement any of the above when executing the computer program.
  • the method for updating firmware of embedded devices including: a first memory and a first processor, the first memory is used to store a computer program, and the first processor is used to implement any of the above when executing the computer program.
  • This application also provides an embedded device firmware update method, which is applied to development-end devices.
  • the method includes:
  • transmission data for the embedded device to perform firmware update is generated.
  • generating corresponding update data based on the update method information includes:
  • the generated update data is patch data
  • the generated update data is compressed data
  • the generated update data is new firmware data.
  • the transmission data further includes any one or any combination of the following information:
  • This application also provides a development device, including: a second memory and a second processor.
  • the second memory is used to store a computer program.
  • the second processor is used to implement any of the above when executing the computer program.
  • This application also provides an embedded device firmware update system, which includes the above-mentioned embedded device and a source device; the source device stores transmission data for updating the embedded device firmware.
  • the source device is a development device or a cloud device.
  • the embedded device includes a boot loader and a firmware update acquisition program; the boot loader includes a data processing module, and the firmware update acquisition program includes an update trigger module and a data receiving module.
  • the update trigger module detects a trigger event for updating the firmware of the embedded device
  • the data receiving module obtains the transmission data from the source device, and writes the update data in the transmission data for the embedded device to update the firmware to the storage space where the transmission data is stored.
  • the data processing module processes the received update data according to the update mode information in the transmitted data to obtain new firmware data, so that the new firmware data can be applied from the partition where the new firmware data is stored during the running of the boot loader to complete the firmware of updates.
  • the data processing module in this application is executed in the boot loader in an optimized manner. Since the boot loader does not need to load many operating system functions and does not need a network communication protocol stack, the boot loader has more available memory and can Provide more available memory space to the data processing module. For compressed updates and differential updates, more available memory space means that higher-level compression algorithms can be used to perform compression, thereby obtaining smaller compressed packages or patch files and avoiding excessive traffic consumption and time. consumption, it can be deployed on devices with limited software and hardware resources to improve the efficiency of firmware updates. In addition, compared with existing solutions that can only support one firmware update method, this application has better compatibility and can use different update methods to apply to different usage scenarios and IoT devices with different functions to meet the needs of different firmware Update requirements. In addition, this application also provides an embedded device, a development device and an embedded device firmware update system with the above technical advantages.
  • Figure 1 shows a schematic diagram of the full update process
  • Figure 2 shows a schematic diagram of the compression update flow chart
  • Figure 3 shows a schematic diagram of the differential update process
  • Figure 4 schematically shows a flow chart of a specific implementation of the embedded device firmware update method provided by this application
  • Figure 5 schematically shows a specific flow chart of the implementation of the embedded device firmware update method provided by this application on the development device
  • Figure 6 schematically shows a flow chart of a specific implementation of the data receiving module in the embedded device firmware update method provided by this application;
  • Figure 7 schematically shows an implementation flow chart of the boot loader operation of the solution provided by this application.
  • Figure 8 shows a schematic diagram of the storage space division of the embedded device when three update methods are enabled
  • Figure 9 shows a schematic diagram of the storage space division of the embedded device when only full update and compressed update are enabled
  • FIG. 10 schematically shows the structural block diagram of the embedded device provided by this application.
  • FIG. 11 schematically shows the structural block diagram of the development end device provided by this application.
  • Figure 12 schematically shows a structural block diagram of the embedded device firmware update system provided by this application.
  • firmware update methods can be divided into three types: full update, compressed update and differential update, of which differential update can also be called incremental update.
  • the full update is to transfer the complete new firmware data to the embedded device to complete the firmware update.
  • the development device compresses the new firmware data.
  • the embedded device performs the decompression operation after receiving the compressed data, and then applies the decompressed new firmware data to complete the firmware update. .
  • the development device performs differential processing on the new firmware data and the old firmware data, generates patch data, and transmits the patch data to the embedded device; the embedded device combines the received old firmware data And patch data, differential decoding operation is performed to recover the new firmware data to complete the firmware update.
  • FIG. 4 The flow chart of a specific implementation method of the embedded device firmware update method provided in this application is shown in Figure 4.
  • this method is applied to the embedded device, and the embedded device includes a boot loader and a firmware update acquisition program.
  • the bootloader is stored in the bootloader partition and the firmware update acquisition program is stored in the corresponding firmware partition.
  • the firmware update acquisition program includes an update trigger module and a data receiving module
  • the boot loader includes a data processing module.
  • Devices that support FOTA usually have two programs: the bootloader program and the firmware program (app program).
  • the bootloader When executing the FOTA function, the bootloader mainly completes the function of reading system parameters and loading the specified firmware update acquisition program based on the system parameters.
  • the firmware program is responsible for the normal functioning of the device and has a firmware update acquisition program integrated into it.
  • the data processing module can be configured to be executed in the boot loader.
  • the update trigger module and data receiving module can be set to be executed in the firmware update acquisition program, and are mainly responsible for receiving update data and rewriting system parameters.
  • the method specifically includes the following steps:
  • the update trigger module detects a trigger event for updating the firmware of the embedded device.
  • the triggering event of detecting an update to the firmware of the embedded device may be specifically: the update triggering module receives updated push information on the version of the firmware sent by the source device; or the update triggering module sends a version of the firmware to the source device.
  • a query request is made as to whether there is an updated version, and a reply message sent by the source device that the version is updated is received.
  • the data receiving module obtains transmission data from the source device.
  • the transmission data at least includes update data for the embedded device to perform firmware update and identification of the update used in this firmware. Update mode information of the new mode; write the update data to the partition where the transmission data is stored.
  • the transmission data at least includes update data for the embedded device to perform firmware update and update method information identifying the update method adopted for this firmware.
  • the transmission data may further include other data, for example, may include any one or any combination of the following information: file header information, signature information of the update data, encryption type information for encrypting the update data, File format version information, update data version information, verification information on whether the data has been encapsulated, compression algorithm information, differential update algorithm information, update data length information, integrity verification parameter information, signature information, version verification information or summary verification information, which will not affect the implementation of this application.
  • the update data is patch data; when the update method information identifies that the update method adopted by this firmware is compressed update, the update data is Compressed data.
  • the update method information identifies that the update method adopted for this firmware is full update, the update data is new firmware data.
  • the data receiving module After the data receiving module obtains the transmission data, it writes the updated data into the partition where the transmission data is stored.
  • the data processing module processes the received update data according to the update mode information to obtain new firmware data, so that the new firmware data can be applied from the partition where the new firmware data is stored during running of the boot loader.
  • the data processing module when the update method information indicates that the update method used for this firmware is differential update, the data processing module performs differential decoding on the received patch data and old firmware data to obtain new firmware data. And after the data processing module processes the received update data and obtains new firmware data, it also includes: the data processing module writes the new firmware data to the partition where the new firmware data is stored, and writes the new firmware data.
  • the partition storing the new firmware data is set as a partition to be booted, so that the new firmware data is applied from the partition to be booted during running of the boot loader.
  • the data processing module before the data processing module differentially decodes the received patch data and the old firmware data to obtain the new firmware data, it also includes: the data processing module obtains the old firmware from the transmission data. Version verification information or summary verification information of the data; judging the number of the patch data and the old firmware based on the version verification information or summary verification information Whether the data matches; if so, perform the operation of differentially decoding the received patch data and the old firmware data to obtain new firmware data.
  • the data processing module decompresses the compressed data to obtain new firmware data.
  • the data processing module processes the received update data and obtains new firmware data, it also includes: the data processing module writes the new firmware data to the partition where the new firmware data is stored, and stores the new firmware data.
  • the partition storing the new firmware data is set as the partition to be booted, so that the new firmware data is applied from the partition to be booted during running of the boot loader.
  • the update method information indicates that when the update method used for this firmware is full update, the update data is the new firmware data, and the partition that stores the transmission data is the partition that stores the new firmware data.
  • the update trigger module, data receiving module, and data processing module are all uniformly set up in the firmware program, resulting in a bloated firmware program.
  • the data processing module is set in the boot loader. Taking an embedded device that includes a bootloader and two firmware programs (app_0, app_1) as an example, Table 1 shows a comparison of the memory space required by the final FOTA function between the existing solution and the solution provided by this application.
  • the solution provided by this application stores the data processing module in the boot loader, which can make the entire FOTA function require less storage space.
  • each module will occupy a certain amount of memory when running, resulting in less available memory for the data processing module that implements decompression and decoding.
  • its RAM size is 400KB.
  • the available memory in the boot loader and firmware program is shown in Table 2.
  • the data processing module in this application is executed in the boot loader. Since the boot loader does not need to load many operating system functions and does not need a network communication protocol stack, the boot loader has more available memory and can provide data Processing modules provide more available memory space. For compressed updates and differential updates, more available memory space means that higher-level compression algorithms can be used to perform compression, thereby obtaining smaller compressed packages or patch files and avoiding excessive traffic consumption and time. consumption, it can be deployed on devices with limited software and hardware resources to improve the efficiency of firmware updates. In addition, compared with existing solutions that can support one firmware update method, this application has better compatibility and can use different update methods to suit different usage scenarios and IoT devices with different functions to meet the needs of different firmware Update requirements.
  • the embedded device firmware update method provided by this application can generate transmission data on the development end device.
  • the generated transmission data can be sent directly to the embedded device for firmware updates. It can also be sent to other source devices for storage, and the embedded device obtains the transmission data from the source device and updates the firmware.
  • the file format of the transmission data can be as shown in Table 3.
  • serial numbers 0 to 9 are the file header part of the transmission data generated by the development device.
  • the part corresponding to serial number 10 is the update data.
  • the update method information is differential update
  • the generated update data is patch data
  • the update method information is compressed update
  • the generated update data is compressed data
  • the update method information is full update
  • the generated update data is new firmware data .
  • specified transmission data can be generated through configuration items.
  • the specific process of the embedded device firmware update method provided by this application on the development device includes:
  • S201 Determine the update method used for firmware update, and generate update method information.
  • the developer can choose the update method used in this update based on the situation of this update. Specifically, developers can first locally verify the amount of data to be transmitted by the three update methods, determine the time required for the device to complete the firmware update, and select the most suitable firmware update method after comparison.
  • the generated update data is patch data; when the update method information is compressed update, the generated update data is compressed data; when the update method information is full update, The generated update data is new firmware data.
  • S203 Based on the update data and update method information, generate transmission data for firmware update of the embedded device.
  • transmission data for firmware updates for embedded devices is generated.
  • the transmission data may further include any one or any combination of the following information: file header information, signature information of the update data, encryption type information for encrypting the update data, file format version information, version information of the update data, data Whether it is encapsulated verification information, compression algorithm information, differential update algorithm information, update data length information, integrity verification parameter information, signature information, version verification information or digest verification information.
  • the generated update data can be added to the file header.
  • the file header part may include the information listed in serial numbers 0 to 9 in Table 3. Further, if you want to use signature information, you can add signature information to the updated data after updating the data. If you want to use encryption, you can encrypt the update data.
  • the method further includes: sending the transmission data to the source device for storage.
  • the embedded device can communicate with the source device and obtain the transmission data sent by the source device to update the firmware.
  • Figure 6 shows a flow chart of a specific implementation of the data receiving module in the embedded device firmware update method provided by this application. This method is applied to embedded devices.
  • Figure 6 shows the specific process of the embedded device receiving update data, which specifically includes:
  • the update trigger module detects a trigger event for updating the firmware of the embedded device.
  • the data receiving module obtains the transmission data from the source device.
  • the transmission data may further include the following information: file header information, signature information of the update data, Encryption type information for encrypting the update data, file format version information, version information of the update data, verification information on whether the data has been encapsulated, compression algorithm information, differential update algorithm information, length information of the update data, and integrity Verification parameter information, signature information, version verification information or summary verification information.
  • the transmission data can be generated by the development-side device, and the data receiving module directly obtains the transmission data from the development-side device. It can also be generated by the development device and sent to other source devices, such as cloud devices. The data receiving module obtains the transmission data from the source device, which does not affect the implementation of this application.
  • the data receiving module determines whether the received transmission data is encapsulated data; if so, obtains the update method information from the transmission data and determines the update method adopted for this firmware.
  • the data receiving module determines whether the received transmission data is encapsulated data based on the information in the transmission data, such as the Magic num information in Table 3. If so, obtain the update method information from the transmission data and determine the update method used for this firmware.
  • S304 The data receiving module determines that the update data has been encrypted, and then decrypts the update data according to the encryption type information in the transmission data.
  • the data receiving module can determine whether the update data has been encrypted. In the case where encryption processing has been performed, the update data is decrypted accordingly based on the encryption type information in the transmitted data.
  • the decryption process may be to perform decryption while downloading, for example, receiving 100KB of update data, that is, decrypting the received 100KB of update data.
  • the decryption operation can also be performed after receiving all the update data, which does not affect the implementation of the present application.
  • the data receiving module writes the updated data to the partition where the transmission data is stored.
  • the data receiving module writes the updated data into the partition that stores the transmitted data based on the update method information.
  • the update method information is full update, the update data is written to the firmware partition; if the update method is compressed update, the update data is written to the firmware partition or a pre-divided compressed partition; If the update method is differential update, the update data is written to the pre-divided patch partition.
  • the data receiving module verifies whether the received update data is complete based on the integrity check parameter information in the transmitted data.
  • the integrity of the received update data is verified based on the integrity check parameter information in the transmitted data, such as serial numbers 8 and 9 in Table 3. For example, the file header checksum in the received update data is compared with the checksum calculated by the embedded device. If they are consistent, the data is complete. If the verification passes, go to the next step. If the verification fails, an error message is generated and reported.
  • the data receiving module sets the partition where the transmission data is stored as the partition to be booted, so that the data processing module obtains the transmission data from the partition where the transmission data is stored.
  • the partition storing the transferred data is set as the partition to be booted. It can be understood that if the update method currently used is compressed update, the partition where the decompressed data is stored is specified in the system parameters; if the update method currently used is differential update, the partition where the old firmware data is stored is specified in the system parameters. , and the partition where the new firmware data is stored.
  • the embedded device has two firmware partitions app_0 and app_1.
  • update data can only be written to another free partition app_1.
  • Embedded devices can also have more than two firmware partitions, taking three firmware partitions: app_0 ⁇ app_1 ⁇ app_2 as an example.
  • app_0 ⁇ app_1 ⁇ app_2 the compressed firmware is downloaded to app_2 (usually the firmware partition with the largest serial number is set as the partition where the compressed firmware is stored)
  • app_0 is used to store system A and app_1 is used to store system B
  • the compressed firmware can be stored in app_2
  • the bootloader program is used to decompress the data in app_2 and update app_0 respectively.
  • firmware or the firmware of app_1.
  • S308 Call the system interface to restart the device so that the device enters the boot loader to apply the updated firmware.
  • S401 The embedded device enters the boot loader after restarting.
  • the data processing module obtains the file header information from the transmission data and verifies the file header information.
  • the data processing module can verify the file header information.
  • the data processing module obtains the signature information of the update data from the transmission data, and verifies the signature information.
  • the bootloader program will also verify the signature information of the updated data to avoid using unauthorized data and improve system security.
  • S404 The data processing module determines whether the update method is full update. If so, proceed to S411; if not, proceed to S405;
  • S405 The data processing module determines whether the update method is compressed update. If so, proceed to S407; if not, proceed to S406;
  • S406 The data processing module determines that the update method is differential update and enters S409;
  • the data processing module decompresses the compressed data, generates decompressed data, and writes the decompressed data into the partition storing the new firmware data, and enters S408;
  • the update mode is compression update
  • the information of the compressed partition storing the compressed data is obtained by reading the system parameters, and the corresponding decompression algorithm is initialized, the compressed data is decompressed, and the decompressed data is written to the specified The partition where the decompressed data is stored.
  • S408 Rewrite the system identifier and set the partition where the decompressed data is stored as the partition to be booted; enter S411;
  • the data processing module performs differential decoding processing based on the old firmware data and patch data, generates new firmware data, and writes the new firmware data into the partition where the new firmware data is stored, and enters S410;
  • the information of the partition storing the old firmware data and the information of the partition storing the new firmware data are obtained by reading the system parameters, and the corresponding differential update algorithm is initialized. Read the old firmware data and patch data, run the differential update algorithm, and generate new firmware data. Write the obtained new firmware data to the partition where the new firmware data is stored.
  • S410 Rewrite the system identifier and set the partition storing new firmware data as the partition to be booted; enter S411;
  • S411 Read the system identification and apply the new firmware data to complete the firmware update.
  • the data processing module can also obtain the integrity check parameter from the transmission data, and perform the verification on all the data written to the firmware. Verify whether the data of the partition storing the new firmware data is complete. If the integrity check passes, the data processing module performs the operation of setting the partition storing the new firmware data as the partition to be booted; if the integrity check fails, the data processing module does not perform the operation of setting the partition storing the new firmware data as the partition to be booted. The operation of setting the partition storing new firmware data as the partition to be booted.
  • the update method is full update
  • the data in the current partition is the new firmware data. Therefore, when the bootloader program is executed, there is no need to move the data to the partition where the new firmware data is stored, that is, the current normal boot.
  • the partition is where the new firmware data is stored. Therefore, there is no need to rewrite the system identifier in this step.
  • Ping Pong to upgrade
  • the new firmware data is written to the partition where the new firmware data is stored.
  • the new firmware data of the partition will be run directly without moving the data of the partition to another storage partition. The restart speed is faster and the It reduces the loss caused by erasing the storage partition and extends the service life of the storage device.
  • the firmware update method provided in this application is compatible with three update methods: differential update, compressed update, and full update, and can meet the firmware update needs of different devices. Moreover, it can solve the problem of unstable size of patch data for differential update and compressed data for compressed update. When the patch partition is too large, that is, when the update involves a lot of content, causing the actual size of the patch data to exceed the pre-divided patch partition or compressed partition, you can save traffic by compressing the update.
  • this application uses a set of common file formats, involving multiple verification operations such as encryption, integrity verification, and signature verification of data, making the firmware update process more secure and reliable.
  • the storage space division of an embedded device that enables three update methods at the same time is shown in Figure 8.
  • the storage space can include the system parameter partition, bootloader partition, app_0 partition, app_1 partition and patch partition.
  • the system parameter partition is used to store system configuration, network connection information, system boot parameters and other information.
  • the bootloader partition is used to store the bootloader program and load app_0 and app_1.
  • the app_0 partition and app_1 partition are used to store app_0 and app_1 respectively to implement the same or different firmware functions.
  • Patch partitions are used to store patch data when performing differential updates.
  • the patch partition is enough to store the patch data, so you can choose to use differential update to perform this update.
  • the currently running app is stored in the app_0 partition, receive the patch data, and then set the patch partition as the boot partition.
  • the bootloader program detects the patch data in the patch partition, performs differential decoding on app_0 and the patch data, and writes the new firmware data into app_1. This will not destroy the available firmware in app_0, otherwise the device may be downgraded in case of emergencies. Finally, set app_1 as the partition to be booted and apply the new firmware data in app_1.
  • app1 is currently running, the patch data is received in app1, and then the differential decoding operation between app1 and the patch data is performed.
  • differential update algorithm used in this application can be the above-mentioned differential update algorithm and its variant algorithm, which does not affect the implementation of this application.
  • the patch partition may not be able to store the patch data at this time.
  • the previous solution chose to use multiple differential updates, and only update a part each time to finally complete the entire update.
  • Change scenarios (such as the purchased device has not been upgraded and needs to be upgraded from version 1 to version 10) will affect the customer experience.
  • differential updates and compressed updates can save transmission traffic, reduce the parallel pressure on the source device that issues update data, and save the time consumed in transmitting update data. However, they all need to be decompressed or decoded in the bootloader program, which will affect the quick start of the bootloader program. For devices that need to be started quickly (such as illegal capture cameras), or use LAN updates (traffic is not billed), then You can choose to update using full update.
  • the storage space division of the embedded device can be shown in Figure 9.
  • the storage space can include the system parameter partition, the bootloader partition, the app_0 partition, and the app_1 partition.
  • the system parameter partition is used to store system configuration, network connection information, system boot parameters and other information.
  • the bootloader partition is used to store the bootloader program and load app_0 and app_1.
  • the app_0 partition and app_1 partition are used to store app_0 and app_1 respectively to implement the same or different firmware functions.
  • compression ratio (original data size - size of patch or compressed data)/original data size.
  • the data processing module is executed in the boot loader. Since the boot loader does not need to load many operating system functions and does not need a protocol stack for network communication, the boot loader has more available memory, which can be used by the data processing module. Provide more available memory space. For compressed updates and differential updates, more available memory space means that higher-level compression algorithms can be used to perform compression, thereby obtaining smaller compressed packages or patch files and avoiding excessive traffic consumption and time. consumption, improving the efficiency of firmware updates.
  • this application also provides an embedded device 11, as shown in Figure 10, a structural block diagram of the embedded device provided by this application.
  • the embedded device 11 specifically includes: a first memory 111 and a first processor 112,
  • the first memory 111 is used to store a computer program
  • the first processor 112 is used to implement any one of the above embedded device firmware update methods when executing the computer program.
  • this application also provides a development end device 12.
  • the structural block diagram of the development end device provided by this application, the development end device 12 includes: a second memory 121 and a second processor 122, so The second memory 121 is used to store a computer program, and the second processor 122 is used to implement any one of the above embedded device firmware update methods when executing the computer program.
  • development-side device may correspond to the above-mentioned firmware update method applied to the development-side device, and reference may be made to the above content, which will not be described again here.
  • this application also provides an embedded device firmware update system 1, as shown in Figure 12, a structural block diagram of the embedded device firmware update system provided by this application, including an embedded device 11 and a source device 13; the source The device 13 stores transmission data for firmware updates of the embedded device.
  • the embedded device 11 can use the embedded device firmware update method described in this application to perform firmware update.
  • firmware update method described in this application to perform firmware update.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

本申请公开了一种嵌入式设备固件更新方法、嵌入式设备、开发端设备以及嵌入式设备固件更新系统。在更新触发模块检测到对嵌入式设备的固件进行更新的触发事件时，数据接收模块从源设备获取传输数据，将传输数据中供嵌入式设备进行固件更新的更新数据写入到存储传输数据的分区。数据处理模块根据传输数据中的更新方式信息，对接收到的更新数据进行处理，得到新固件数据，在运行引导加载程序期间从存储新固件数据的分区中应用该新固件数据，以完成固件的更新。本申请可以给数据处理模块提供更多的可用内存空间，避免过多的流量消耗和时间消耗，可以部署在软硬件资源受限的设备上，提升固件更新的效率，并且具备更好的兼容性。

Description

嵌入式设备固件更新方法、嵌入式设备、开发端设备 技术领域
本申请涉及嵌入式技术领域，尤其涉及一种嵌入式设备固件更新方法、嵌入式设备、开发端设备以及嵌入式设备固件更新系统。
背景技术
在物联网技术快速发展的时代，FOTA(Firmware Over the Air)远程固件更新功能正在成为物联网设备的必备功能之一。通过使用FOTA功能，物联网设备不仅可以改进功能，消除系统的漏洞，还可以向不同用户提供差异化服务，使得产品在市场上更受欢迎。
传统的嵌入式设备，例如PC或者手机，其内部也集成了FOTA功能。一般情况下，PC或手机拥有强大计算能力的CPU，以及较为充足的内存资源以及物理存储空间。而物联网设备的CPU往往计算能力有限，内存资源以及物理存储空间也受到较多限制。另外，PC或者手机使用FOTA的频率并不高，通常几周更新一次。而物联网设备执行FOTA的频率则较高，以共享单车为例，其平均每周就至少更新一次。这对固件更新的流量消耗和时间消耗也提出了更高的要求，过高的流量消耗将会对运营商造成庞大的费用开销；较长的时间消耗也会影响用户的使用体验。
另外，物联网设备种类多、功能多样，不同型号的设备可用资源不一样，即便是相同型号的设备，由于软件定义的功能不一致，导致用于FOTA的软硬件资源也不一样，导致了采用统一的方案以同时满足多种物联网设备实现FOTA功能的困难。
鉴于此，提供一种能够节省流量和时间，可以部署在软硬件资源受限的设备，且能够适用多种使用场景、功能各异的物联网设备的通用固件更新方案，是本领域技术人员亟待解决的技术问题之一。
应理解，上述所列举的技术问题仅作为示例而非对本发明的限制，本发明并不限于同时解决上述所有技术问题的技术方案。本发明的技术方案可以 实施为解决上述或其他技术问题中的一个或多个。
发明内容
为解决上述和其他问题，本申请提供了一种嵌入式设备固件更新方法，应用于所述嵌入式设备，所述嵌入式设备包括引导加载程序，以及固件更新获取程序；所述引导加载程序存储在引导加载分区中，所述固件更新获取程序存储在对应的固件分区中，其中所述固件更新获取程序包括更新触发模块以及数据接收模块，所述引导加载程序包括数据处理模块，所述方法包括：
所述更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件；
所述数据接收模块从源设备获取传输数据，所述传输数据至少包括供所述嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更新方式的更新方式信息；将所述更新数据写入到存储传输数据的分区；及
所述数据处理模块依据所述更新方式信息，对接收到的所述更新数据进行处理，得到新固件数据，以便在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据。
可选地，所述更新方式信息标识本次固件所采用的更新方式为差分更新时，所述更新数据为补丁数据。
可选地，所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据包括：
将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据；
在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：
所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以便在运行引导加载程序期间从所述待引导分区中应用所述新固件数据。
可选地，在所述数据处理模块将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据之前还包括：
所述数据处理模块从所述传输数据中获取旧固件数据的版本校验信息或摘要校验信息；依据所述版本校验信息或摘要校验信息判断所述补丁数据与所述旧固件数据是否匹配；
如果是，则执行所述将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据的操作。
可选地，所述更新方式信息标识本次固件所采用的更新方式为压缩更新时，所述更新数据为压缩后的数据。
可选地，所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据包括：
对所述压缩后的数据进行解压处理，得到新固件数据；
在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：
所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以便在运行引导加载程序期间从所述待引导分区中应用所述新固件数据。
可选地，在所述更新方式信息标识本次固件所采用的更新方式为全量更新时，所述更新数据为新固件数据，所述存储传输数据的分区为所述存储新固件数据的分区。
可选地，所述更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件包括：
所述更新触发模块接收到所述源设备发送的固件的版本存在更新的推送信息；
所述更新触发模块向所述源设备发送固件的版本是否存在更新的查询请求，并接收到所述源设备发送的版本存在更新的回复信息。
可选地，在所述数据接收模块从源设备获取传输数据之后还包括：
所述数据接收模块判断接收到的传输数据是否为经过封装的数据；如 果是，则从所述传输数据中获取更新方式信息，确定本次固件所采用的更新方式。
可选地，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之前还包括：
所述数据接收模块判断所述更新数据是否执行过加密处理；如果是，则依据所述传输数据中的加密类型信息，对所述更新数据进行解密处理。
可选地，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之前还包括：
所述数据接收模块依据所述传输数据中的完整性校验参数信息，对接收到的更新数据是否完整进行校验。
可选地，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之后还包括：
所述数据接收模块将所述存储传输数据的分区设置为待引导分区，以使所述数据处理模块从所述存储传输数据的分区中获取所述传输数据。
可选地，所述数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之前还包括：
所述数据处理模块从所述传输数据中获取文件头信息，对所述文件头信息进行校验。
可选地，所述数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之前还包括：
所述数据处理模块从所述传输数据中获取更新数据的签名信息，对所述签名信息进行校验。
可选地，所述数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之后还包括：
所述数据处理模块从所述传输数据中获取完整性校验参数信息，对写入到所述存储新固件数据的分区的数据是否完整进行校验。
可选地，所述更新方式信息识别本次固件所采用的更新方式为差分更新或压缩更新时，在所述数据处理模块从所述传输数据中获取完整性校验 参数，对写入到所述存储新固件数据的分区的数据是否完整进行校验之后还包括：
若完整性校验通过，则所述数据处理模块执行将所述存储新固件数据的分区设置为待引导分区的操作；若完整性校验未通过，则所述数据处理模块不执行将所述存储新固件数据的分区设置为待引导分区的操作。
本申请还提供了一种嵌入式设备，包括：第一存储器以及第一处理器，所述第一存储器用于存储计算机程序，所述第一处理器用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。
本申请还提供了一种嵌入式设备固件更新方法，应用于开发端设备，所述方法包括：
确定固件更新所采用的更新方式，生成更新方式信息；
依据所述更新方式信息，生成对应的更新数据；
基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据。
可选地，所述依据所述更新方式信息，生成对应的更新数据包括：
所述更新方式信息为差分更新时，生成的更新数据为补丁数据；
所述更新方式信息为压缩更新时，生成的更新数据为压缩后的数据；
所述更新方式信息为全量更新时，生成的更新数据为新固件数据。
可选地，所述传输数据进一步包括以下信息的任意一种或任意组合：
文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息。
可选地，在所述基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据之后还包括：
将所述传输数据发送至源设备进行存储。
本申请还提供了一种开发端设备，包括：第二存储器以及第二处理器，所述第二存储器用于存储计算机程序，所述第二处理器用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。
本申请还提供了一种嵌入式设备固件更新系统，包括上述所述的嵌入式设备以及源设备；所述源设备存储有供所述嵌入式设备固件更新的传输数据。
可选地，所述源设备为开发端设备或云端设备。
本申请所提供的嵌入式设备固件更新方法，该嵌入式设备包括引导加载程序以及固件更新获取程序；引导加载程序包括数据处理模块，固件更新获取程序包括更新触发模块以及数据接收模块。在更新触发模块检测到对嵌入式设备的固件进行更新的触发事件时，数据接收模块从源设备获取传输数据，将传输数据中供嵌入式设备进行固件更新的更新数据写入到存储传输数据的分区。数据处理模块根据传输数据中的更新方式信息，对接收到的更新数据进行处理，得到新固件数据，以便在运行引导加载程序期间从存储新固件数据的分区中应用该新固件数据，以完成固件的更新。
本申请中数据处理模块以优化的方式在引导加载程序中执行，而由于引导加载程序不需要加载很多操作系统的功能，也不需要有网络通信的协议栈，使得引导加载程序可用内存多，可以给数据处理模块提供更多的可用内存空间。对于采用压缩更新、差分更新而言，更多的可用内存空间意味着可以使用更高级别的压缩算法来执行压缩，从而能够获得更小的压缩包或者补丁文件，避免过多的流量消耗和时间消耗，可以部署在软硬件资源受限的设备上，提升固件更新的效率。此外，与现有方案仅能支持一种固件更新方式相比，本申请具备更好的兼容性，能够采用不同的更新方式适用不同的使用场景和功能各异的物联网设备，满足不同的固件更新需求。此外，本申请还提供了一种具有上述技术优点的嵌入式设备、开发端设备以及嵌入式设备固件更新系统。
附图说明
在下文中，将基于实施例参考附图进一步解释本申请。
图1示出全量更新流程示意图；
图2示出压缩更新流程图示意图；
图3示出差分更新流程示意图；
图4示意性地示出本申请所提供的嵌入式设备固件更新方法的一种具体实施方式的流程图；
图5示意性地示出本申请所提供的嵌入式设备固件更新方法在开发端设备执行的具体流程图；
图6示意性地示出本申请所提供的嵌入式设备固件更新方法中数据接收模块的具体实施方式的流程图；
图7示意性地示出本申请所提供的方案引导加载程序运行的实施方式流程图；
图8示出启用三种更新方式时嵌入式设备的存储空间划分情况示意图；
图9示出仅启用全量更新和压缩更新时嵌入式设备的存储空间划分情况示意图；
图10示意性地示出了本申请所提供的嵌入式设备的结构框图；
图11示意性地示出了本申请所提供的开发端设备的结构框图；
图12示意性地示出了本申请所提供的嵌入式设备固件更新系统的结构框图。
具体实施方式
以下将结合附图和具体的实施方式，对本申请的方法、设备和系统进行详细说明。应理解，附图所示以及下文所述的实施例仅仅是说明性的，而不作为对本申请的限制。
按照固件更新中对传输数据的处理，可以将固件更新方法分为三种：全量更新、压缩更新和差分更新，其中差分更新也可以称为增量更新。
如图1全量更新流程示意图所示，全量更新即将完整的新固件数据传输至嵌入式设备，以完成固件的更新。
如图2压缩更新流程图示意图所示，在开发端设备将新固件数据进行压缩，嵌入式设备接收到压缩后的数据后执行解压操作，然后应用解压后的新固件数据，以完成固件的更新。
如图3差分更新流程示意图所示，在开发端设备对新固件数据以及旧固件数据进行差分处理，生成补丁数据，并将补丁数据传输至嵌入式设备；嵌入式设备结合接收到的旧固件数据以及补丁数据，进行差分解码操作恢复出新固件数据，以完成固件的更新。
本申请所提供的嵌入式设备固件更新方法的一种具体实施方式的流程图如图4所示，参照图4，本方法应用于嵌入式设备，该嵌入式设备包括引导加载程序以及固件更新获取程序。引导加载程序存储在引导加载分区中，固件更新获取程序存储在对应的固件分区中。其中，固件更新获取程序包括更新触发模块以及数据接收模块，引导加载程序包括数据处理模块。
支持FOTA的设备上通常具有两种程序：引导加载程序(bootloader程序)以及固件程序(app程序)。在执行FOTA功能时，引导加载程序主要完成读取系统参数，并依据系统参数加载指定的固件更新获取程序的功能。固件程序负责设备的正常功能，其中集成有固件更新获取程序。本申请中，数据处理模块可以设置在引导加载程序中执行。而包括更新触发模块以及数据接收模块可以设置在固件更新获取程序中执行，主要负责接收更新数据，改写系统参数的功能。
该方法具体包括以下步骤：
S101：更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件。
检测到对嵌入式设备的固件进行更新的触发事件可以具体为：更新触发模块在接收到所述源设备发送的固件的版本存在更新的推送信息；或者更新触发模块向所述源设备发送固件的版本是否存在更新的查询请求，并接收到所述源设备发送的版本存在更新的回复信息。
S102：数据接收模块从源设备获取传输数据，所述传输数据至少包括供所述嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更 新方式的更新方式信息；将所述更新数据写入到存储传输数据的分区。
其中，传输数据至少包括供嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更新方式的更新方式信息。可以理解的是，传输数据还可以进一步包括其他数据，例如，可以包括以下信息的任意一种或任意组合：文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息，这均不影响本申请的实现。
具体地，更新方式信息标识本次固件所采用的更新方式为差分更新时，所述更新数据为补丁数据；更新方式信息标识本次固件所采用的更新方式为压缩更新时，所述更新数据为压缩后的数据。更新方式信息标识本次固件所采用的更新方式为全量更新时，所述更新数据为新固件数据。
数据接收模块获取到传输数据之后，将更新数据写入到存储传输数据的分区中。
S103：数据处理模块依据所述更新方式信息，对接收到的所述更新数据进行处理，得到新固件数据，以便在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据。
具体地，更新方式信息标识本次固件所采用的更新方式为差分更新时，数据处理模块将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据。并在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以在运行引导加载程序期间从所述待引导分区应用新固件数据。
作为一种具体实施方式，在所述数据处理模块将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据之前还包括：数据处理模块从所述传输数据中获取旧固件数据的版本校验信息或摘要校验信息；依据所述版本校验信息或摘要校验信息判断所述补丁数据与所述旧固件数 据是否匹配；如果是，则执行所述将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据的操作。
在实际更新过程中，可能会出现将版本3和版本2的固件差分生成的补丁数据发送到正在运行的版本1的嵌入式设备上的情况，导致补丁数据和版本1进行差分解码，生成错误的版本3。因此，采用上述具体实施方式对补丁数据和旧固件数据进行匹配，能够保证补丁数据以及旧固件数据在成功匹配条件下才能恢复出新固件数据，从而避免了生成错误版本的新固件数据的概率，提高了固件更新过程的可靠性。
更新方式信息标识本次固件所采用的更新方式为压缩更新时，数据处理模块对所述压缩后的数据进行解压处理，得到新固件数据。在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以在运行引导加载程序期间从所述待引导分区应用新固件数据。
更新方式信息标识本次固件所采用的更新方式为全量更新时，更新数据即为新固件数据，存储传输数据的分区即为存储新固件数据的分区。
现有的很多方案中，将更新触发模块、数据接收模块以及数据处理模块均统一设置在固件程序中，因此导致固件程序的体积较为臃肿。而本申请提供的方案中，将数据处理模块设置在引导加载程序中。以嵌入式设备中包括一个引导加载程序和两个固件程序(app_0、app_1)为例，表1示出了现有方案与本申请提供的方案最终FOTA功能需要占用的内存空间比较。
表1

由表1可以看出，与现有的方案相比，本申请提供的方案将数据处理模块存储在引导加载程序中，能够使得整个FOTA功能需要占用的存储空间更少。
此外，每个模块在运行时均会占用一定的内存，导致实施解压、解码的数据处理模块的可用内存较少。以一款网络摄像头为例，其RAM大小为400KB，在引导加载程序、固件程序中可用内存如表2所示。
表2
可见，本申请中数据处理模块在引导加载程序中执行，而由于引导加载程序不需要加载很多操作系统的功能，也不需要有网络通信的协议栈，使得引导加载程序可用内存多，可以给数据处理模块提供更多的可用内存空间。对于采用压缩更新、差分更新而言，更多的可用内存空间意味着可以使用更高级别的压缩算法来执行压缩，从而能够获得更小的压缩包或者补丁文件，避免过多的流量消耗和时间消耗，可以部署在软硬件资源受限的设备上，提升固件更新的效率。此外，与现有方案往能支持一种固件更新方式相比，本申请具备更好的兼容性，能够采用不同的更新方式适用不同的使用场景和功能各异的物联网设备，满足不同的固件更新需求。
本申请所提供的嵌入式设备固件更新方法，可以在开发端设备生成传输数据。生成的传输数据可以直接发送至嵌入式设备，进行固件更新。也可以发送至其他源设备进行存储，嵌入式设备从该源设备中获取到传输数据，进行固件更新。
作为一种具体实施方式，传输数据的文件格式可以如表3所示。
表3
在表3中，序号0～9为开发端设备生成的传输数据的文件头部分。序号10对应的部分为更新数据。更新方式信息为差分更新时，生成的更新数据为补丁数据；更新方式信息为压缩更新时，生成的更新数据为压缩后的数据；更新方式信息为全量更新时，生成的更新数据为新固件数据。
在开发端设备端，可以通过配置项生成指定的传输数据。具体地，参 照图5，本申请所提供的嵌入式设备固件更新方法在开发端设备执行的具体过程包括：
S201：确定固件更新所采用的更新方式，生成更新方式信息。
本步骤中，可以由开发人员结合本次更新的情况，选择本次更新所采用的更新方式。具体地，开发人员可以先在本地验证三种更新方式要传输的数据量，确定出设备完成固件更新所需的时间，对比后选择出最适合的固件更新方式。
S202：依据所述更新方式信息，生成对应的更新数据。
其中，所述更新方式信息为差分更新时，生成的更新数据为补丁数据；所述更新方式信息为压缩更新时，生成的更新数据为压缩后的数据；所述更新方式信息为全量更新时，生成的更新数据为新固件数据。
S203：基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据。
结合更新数据以及更新方式信息，生成供嵌入式设备进行固件更新的传输数据。传输数据进一步可以包括以下信息的任意一种或任意组合：文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息。
具体地，可以在生成的更新数据补充文件头部分。作为一种具体实施方式，文件头部分可以包括表3中序号0～9所列出的信息。进一步地，若要使用签名信息，则可以在更新数据后添加对该更新数据的签名信息。若要使用加密功能，则可以对更新数据执行加密处理。
在所述基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据之后还包括：将所述传输数据发送至源设备进行存储。嵌入式设备可以与该源设备通信，获取源设备发送的传输数据，以进行固件的更新。
图6示出了本申请所提供的嵌入式设备固件更新方法中数据接收模块的具体实施方式的流程图。该方法应用于嵌入式设备，图6示出了嵌入式设备接收更新数据的具体过程，其具体包括：
S301：更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件。
S302：数据接收模块从源设备获取传输数据。
传输数据除包括供所述嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更新方式的更新方式信息之外，还可以进一步包括以下信息：文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息。
传输数据可以由开发端设备生成，数据接收模块直接从该开发端设备获取传输数据。也可以由开发端设备生成后发送到其他源设备，例如云端设备。数据接收模块从该源设备处获取传输数据，这均不影响本申请的实现。
S303：数据接收模块判断接收到的传输数据是否为经过封装的数据；如果是，则从所述传输数据中获取更新方式信息，确定本次固件所采用的更新方式。
具体地，数据接收模块依据传输数据中的信息，例如表3中的Magic num信息，判断接收到的传输数据是否为经过封装的数据。如果是，则从传输数据中获取更新方式信息，确定本次固件所采用的更新方式。
S304：数据接收模块判定所述更新数据执行过加密处理，则依据所述传输数据中的加密类型信息，对所述更新数据进行解密处理。
具体地，数据接收模块可以判断更新数据是否执行过加密处理。在执行过加密处理的情况下，依据传输数据中的加密类型信息，对更新数据进行相应的解密处理。
可以理解的是，本申请所提供的方案在启动加解密功能时，其解密过 程是在固件程序中执行，而固件程序是多任务环境，因此可以实现边解密边执行其他任务。与将解密功能放在引导加载程序中执行的方案相比，由于引导加载程序为单任务环境，无法实现边解密边执行其他任务，采用该种实施方式可以提升固件更新的效率。
解密过程具体可以为边下载边执行解密，例如接收100KB的更新数据，即对接收到的该100KB的更新数据进行解密。当然，也可以在接收到全部的更新数据后再执行解密操作，这均不影响本申请的实现。
S305：数据接收模块将所述更新数据写入到存储传输数据的分区。
数据接收模块依据更新方式信息，将更新数据写入到存储传输数据的分区中。作为一种具体实施方式，若更新方式信息为全量更新，则将更新数据写入到固件分区中；若更新方式为压缩更新，则将更新数据写入到固件分区或预先划分的压缩分区中；若更新方式为差分更新，则将更新数据写入到预先划分的补丁分区中。
S306：数据接收模块依据所述传输数据中的完整性校验参数信息，对接收到的更新数据是否完整进行校验。
在S305更新数据接收完毕后，根据传输数据中的完整性校验参数信息，例如表3中序号8和9，对接收到的更新数据是否完整进行校验。例如，将接收到的更新数据中的文件头校验和与嵌入式设备端计算出的校验和进行比较，若一致则表示数据完整。如果校验通过则进入下一步，如果校验不通过，则产生错误信息并上报。
S307：数据接收模块将所述存储传输数据的分区设置为待引导分区，以使所述数据处理模块从所述存储传输数据的分区中获取所述传输数据。
通过改写FOTA升级的系统参数，将存储传输数据的分区设置为待引导分区。可以理解的是，若当前使用的更新方式为压缩更新，则在系统参数中指定存放解压数据的分区；若当前使用的更新方式为差分更新，则在系统参数中指定存储旧固件数据所在的分区，以及存储新固件数据的分区。
在上述示例中，嵌入式设备具有两个固件分区app_0、app_1，在当前运行app_0时，只能将更新数据写入到另一个空闲的分区app_1中。
嵌入式设备还可以具有两个以上固件分区的情况，以具有三个固件分区：app_0\app_1\app_2为例。在有多个固件分区的情况下，假设压缩固件下载到了app_2(一般将序号最大的固件分区设置为存放压缩固件的分区)，则可以将压缩固件解压到app_0或者app_1，这时需要在系统参数中进行指定，告知bootloader程序将解压的数据写到哪个分区中。
对于嵌入式设备是双系统的情况，例如，app_0中用于存放A系统，app_1用于存放B系统，则其压缩固件都可以存到app_2，然后依靠bootloader程序解压app_2里的数据，分别更新app_0的固件，或者app_1的固件。
S308：调用系统接口，重启设备，以便设备进入引导加载程序应用更新后的固件。
下面对引导加载程序运行时执行的具体操作进行进一步详细介绍。如图7本申请所提供的方案引导加载程序运行的实施方式流程图所示，该过程具体包括：
S401：嵌入式设备重启后进入到引导加载程序中。
S402：数据处理模块从传输数据中获取文件头信息，对所述文件头信息进行校验。
具体地，数据处理模块可以对文件头信息进行校验。
S403：数据处理模块从所述传输数据中获取更新数据的签名信息，对所述签名信息进行校验。
可选地，若启用了数字签名的功能，bootloader程序还会校验更新数据的签名信息，来避免使用未经授权的数据，提高系统的安全性。
S404：数据处理模块判断更新方式是否为全量更新，如果是，则进入S411；如果否，则进入S405；
S405：数据处理模块判断更新方式是否为压缩更新，如果是，则进入S407；如果否，则进入S406；
S406：数据处理模块确定更新方式为差分更新，进入S409；
S407：数据处理模块对压缩后的数据进行解压，生成解压后的数据，并将解压后的数据写入到存储新固件数据的分区中，进入S408；
在更新方式后为压缩更新时，通过读取系统参数，获取存储压缩数据的压缩分区的信息，并且初始化对应的解压算法，对压缩后的数据进行解压，并将解压后的数据写入到指定的存储解压后的数据的分区中。
S408：改写系统标识，将存储解压后的数据的分区设置为待引导分区；进入S411；
S409：数据处理模块依据旧固件数据以及补丁数据，进行差分解码处理，生成新固件数据，并将新固件数据写入到存储新固件数据的分区中，进入S410；
在更新方式后为差分更新时，通过读取系统参数，获取存储旧固件数据的分区的信息，以及存储新固件数据的分区的信息，并初始化对应的差分更新算法。读取旧固件数据以及补丁数据，运行差分更新算法，生成新固件数据。将得到的新固件数据写入到存储新固件数据的分区中。
S410：改写系统标识，将存储新固件数据的分区设置为待引导分区；进入S411；
S411：读取系统标识，应用新固件数据，以完成固件的更新。
本实施例中，在更新方式信息识别本次固件所采用的更新方式为差分更新或压缩更新时，还可以由数据处理模块从所述传输数据中获取完整性校验参数，对写入到所述存储新固件数据的分区的数据是否完整进行校验。若完整性校验通过，则所述数据处理模块执行将所述存储新固件数据的分区设置为待引导分区的操作；若完整性校验未通过，则所述数据处理模块不执行将所述存储新固件数据的分区设置为待引导分区的操作。通过这样的设置，当数据处理模块出现错误、设备断电的情况下，旧固件数据和系统参数不会被破坏，下次会继续尝试执行解压、解码，确保接收到的新固件数据是完整的数据，避免加载不完整的新固件导致设备启动异常，从而提高了系统的可靠性。此外，当采用的更新方式为压缩更新时，在执行完解压或者搬运等操作后，本申请并不会擦除数据，只会在成功解压后改写 系统标识，避免了擦除操作增加bootloader的运行时间，从而使本申请的启动时间更快，也避免了重启失败时设备因无可运行的app而只能恢复出厂设置的风险。
可以理解的是，在更新方式为全量更新时，在当前分区的数据即为新固件数据，因此在bootloader程序执行时不需要再将数据搬运到存储新固件数据的分区中，即当前正常引导的分区即为存储新固件数据的分区。因此，该步骤中不需要改写系统标识。在使用乒乓升级时，新固件数据写到存储新固件数据的分区，重启后直接运行该分区的新固件数据，而不用将该分区的数据搬移到另一个存储分区中，重启速度更快，并减少了对存储分区的擦除操作引起的损耗，延长了存储设备的使用寿命。
现有方案往往仅支持一种固件更新方式，兼容性较差，无法适用不同的使用场景，无法满足功能各异的物联网设备更新的需求。本申请所提供的固件更新方法，兼容差分更新、压缩更新、全量更新三种更新方式，可以满足不同设备的固件更新的需求。并且，可以解决差分更新的补丁数据、压缩更新的压缩数据大小不稳定的问题。在补丁分区过大，即本次更新涉及的内容较多时，导致补丁数据的实际大小超出预先划分的补丁分区或压缩分区时，可以通过压缩更新来实现节省流量的目的。此外，本申请采用了一套通用的文件格式，涉及对数据进行加密、完整性校验以及签名校验等多重校验操作，使得固件更新的过程更加安全可靠。
作为一种具体实施方式，开发人员可以在产品设计阶段决定采用哪种固件更新方式。一种同时启用三种更新方式的嵌入式设备的存储空间划分情况可如图8所示，该存储空间可以包括系统参数分区、bootloader分区、app_0分区、app_1分区以及补丁分区。其中，系统参数分区用于存储系统的配置、网络连接信息、系统引导参数等信息。bootloader分区用于存储bootloader程序，加载app_0以及app_1。app_0分区、app_1分区分别用于存储app_0、app_1，以实现相同或不同的固件功能。补丁分区用于在进行差分更新时存储补丁数据。使用本申请所提供的固件更新方法可以按下述 场景进行选择：
当新固件数据、旧固件数据的差异小时，此时补丁分区足够存放补丁数据，因此此时可以选择使用差分更新来执行本次更新。若当前运行的app存储在app_0分区，接收补丁数据，然后设置补丁分区为引导分区。重启后，bootloader程序检测到补丁分区里的补丁数据，执行对app_0与补丁数据进行差分解码的操作，将得到新固件数据写入app_1。这样就不会破坏app_0里的可用固件，否则如遇突发情况可能导致设备降级，最后设置app_1为待引导分区，应用app_1里的新固件数据。类似地，当前若运行的是app1，就在app1里接收补丁数据，然后执行app1与补丁数据的差分解码操作。
可以理解的是，当前大部分差分更新算法如vcdiff、bsdiff、xdelta都不支持在软硬件资源受限的嵌入式设备上实现本地更新，因此需要划分一块单独的补丁分区来存储补丁数据。本申请所采用的差分更新算法可以是上述差分更新算法及其变体算法，这均不影响本申请的实现。
当新固件数据、旧固件数据的差异较大时，此时补丁分区可能无法存储补丁数据，以往的方案选择采用多次差分更新，每次只更新一部分来最终完成全部的更新，但在较大的更改的场景下(如购买的设备一直没有升级，需要从版本1升级到版本10)会影响客户使用体验。此时，可以选择使用压缩更新，若当前运行的app存储在app_0分区，则将压缩文件下载到app_1分区，然后设置app_1为待引导分区，重启后，bootloader程序能够立即找到压缩数据所在的分区，然后发现有一个压缩更新待完成。然后在bootloader程序中将app_1分区的压缩固件解压到app_0分区，解压完成后改写引导分区为app_0，并应用app_0分区的新固件数据。
虽然差分更新、压缩更新可以节省传输流量，降低下发更新数据的源设备端的并行压力，并节省传输更新数据的时间消耗。但其都需要在bootloader程序中进行解压或者解码处理，这会影响bootloader程序的快速启动，对于需要快速启动(如违章抓拍摄像头)，或者使用局域网更新(流量不计费)的设备而言，则可以选择使用全量更新的方式进行更新。
现有方案很难给出合理的存储空间划分情况，当划分的用于存储压缩 数据或者存储补丁数据的存储空间较小时，会因为没有足够的物理存储空间而无法完成固件的更新。本申请可以在无法使用差分更新的情况下，例如旧固件数据与新固件数据差异较大，导致生成的补丁数据较大，这时可以选择采用压缩更新或者全量更新，从而更大限度地利用设备的资源，提升用户的使用体验。
作为一种具体实施方式，开发人员也可在产品设计阶段仅启用全量更新和压缩更新。此时嵌入式设备的存储空间划分情况可如图9所示，该存储空间可以包括系统参数分区、bootloader分区、app_0分区、app_1分区。其中，系统参数分区用于存储系统的配置、网络连接信息、系统引导参数等信息。bootloader分区用于存储bootloader程序，加载app_0以及app_1。app_0分区、app_1分区分别用于存储app_0、app_1，以实现相同或不同的固件功能。这种场景下，用本本申请所提供的方案可以按下述场景进行选择：
当需要节省流量，或者节省传输更新数据的时间消耗时，本次更新可以选择压缩更新。若当前正在运行的是app_0分区，则将压缩的固件下载到app_1分区；在bootloader程序中执行解压，并将解压得到的新固件数据写到app_0分区，然后引导app_0分区的新固件数据运行。
当需要快速启动，或者网络环境好，不需要节省流量时，本次更新使用全量更新。
以当前比较流行的xz压缩算法、以及bsdiff差分更新算法为例，其不同压缩率下的设备端处理数据需要的内存消耗如表4所示。越大的压缩率，代表要传输的数据越小，嵌入式设备端需要的内存越大。
其中，压缩率＝(原始数据大小-补丁或者压缩后的数据的大小)/原始数据大小。
表4

本申请中数据处理模块在引导加载程序中执行，而由于引导加载程序不需要加载很多操作系统的功能，也不需要有网络通信的协议栈，使得引导加载程序可用内存多，可以给数据处理模块提供更多的可用内存空间。对于采用压缩更新、差分更新而言，更多的可用内存空间意味着可以使用更高级别的压缩算法来执行压缩，从而能够获得更小的压缩包或者补丁文件，避免过多的流量消耗和时间消耗，提升了固件更新的效率。
此外，本申请还提供了一种嵌入式设备11，如图10本申请所提供的嵌入式设备的结构框图所示，该嵌入式设备11具体包括：第一存储器111以及第一处理器112，所述第一存储器111用于存储计算机程序，所述第一处理器112用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。
可以理解的是，该嵌入式设备执行固件更新的过程与上述应用于嵌入式设备的固件更新方法相对应，可参照上述内容，在此不再赘述。
此外，本申请还提供了一种开发端设备12，如图11本申请所提供的开发端设备的结构框图所示，该开发端设备12包括：第二存储器121以及第二处理器122，所述第二存储器121用于存储计算机程序，所述第二处理器122用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。
可以理解的是，该开发端设备可以与上述应用于开发端设备的固件更新方法相对应，可参照上述内容，在此不再赘述。
此外，本申请还提供了一种嵌入式设备固件更新系统1，如图12本申请所提供的嵌入式设备固件更新系统的结构框图所示，包括嵌入式设备11以及源设备13；所述源设备13存储有供所述嵌入式设备固件更新的传输数据。
其中，嵌入式设备11与源设备13之间可以通过多种通信协议进行数据传输。所述源设备13可以为开发端设备或云端设备。其中，嵌入式设备11可以采用本申请所记载的嵌入式设备固件更新方法进行固件更新，具体实施方式可参照方法内容的记载，在此不再赘述。
虽然出于本公开的目的已经描述了本申请各方面的各种实施例，但是不应理解为将本公开的教导限制于这些实施例。在一个具体实施例中公开的特征并不限于该实施例，而是可以和不同实施例中公开的特征进行组合。例如，在一个实施例中描述的根据本申请的方法的一个或多个特征和/或操作，亦可单独地、组合地或整体地应用在另一实施例中。本领域技术人员应理解，还存在可能的更多可选实施方式和变型，可以对上述系统进行各种改变和修改，而不脱离由本申请权利要求所限定的范围。

Claims (24)

  1. 一种嵌入式设备固件更新方法，其特征在于，应用于所述嵌入式设备，所述嵌入式设备包括引导加载程序，以及固件更新获取程序；所述引导加载程序存储在引导加载分区中，所述固件更新获取程序存储在对应的固件分区中，其中所述固件更新获取程序包括更新触发模块以及数据接收模块，所述引导加载程序包括数据处理模块，所述方法包括：
    所述更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件；
    所述数据接收模块从源设备获取传输数据，所述传输数据至少包括供所述嵌入式设备进行固件更新的更新数据以及标识本次固件所采用的更新方式的更新方式信息；将所述更新数据写入到存储传输数据的分区；及
    所述数据处理模块依据所述更新方式信息，对接收到的所述更新数据进行处理，得到新固件数据，以便在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据。
  2. 如权利要求1所述的嵌入式设备固件更新方法，其特征在于，所述更新方式信息标识本次固件所采用的更新方式为差分更新时，所述更新数据为补丁数据。
  3. 如权利要求2所述的嵌入式设备固件更新方法，其特征在于，所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据包括：
    将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据；
    在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：
    所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以便在运行引导加载程序期间从所述待引导分区中应用所述新固件数据。
  4. 如权利要求3所述的嵌入式设备固件更新方法，其特征在于，在所述数据处理模块将接收到的所述补丁数据与旧固件数据进行差分解码处理， 得到新固件数据之前还包括：
    所述数据处理模块从所述传输数据中获取旧固件数据的版本校验信息或摘要校验信息；依据所述版本校验信息或摘要校验信息判断所述补丁数据与所述旧固件数据是否匹配；
    如果是，则执行所述将接收到的所述补丁数据与旧固件数据进行差分解码处理，得到新固件数据的操作。
  5. 如权利要求1所述的嵌入式设备固件更新方法，其特征在于，所述更新方式信息标识本次固件所采用的更新方式为压缩更新时，所述更新数据为压缩后的数据。
  6. 如权利要求5所述的嵌入式设备固件更新方法，其特征在于，所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据包括：
    对所述压缩后的数据进行解压处理，得到新固件数据；
    在所述数据处理模块对接收到的所述更新数据进行处理，得到新固件数据之后还包括：
    所述数据处理模块将所述新固件数据写入到存储新固件数据的分区，并将所述存储新固件数据的分区设置为待引导分区，以便在运行引导加载程序期间从所述待引导分区中应用所述新固件数据。
  7. 如权利要求1所述的嵌入式设备固件更新方法，其特征在于，在所述更新方式信息标识本次固件所采用的更新方式为全量更新时，所述更新数据为新固件数据，所述存储传输数据的分区为所述存储新固件数据的分区。
  8. 如权利要求1至7任一项所述的嵌入式设备固件更新方法，其特征在于，所述更新触发模块检测到对所述嵌入式设备的固件进行更新的触发事件包括：
    所述更新触发模块接收到所述源设备发送的固件的版本存在更新的推送信息；
    所述更新触发模块向所述源设备发送固件的版本是否存在更新的查询请求，并接收到所述源设备发送的版本存在更新的回复信息。
  9. 如权利要求1至7任一项所述的嵌入式设备固件更新方法，其特征在于，在所述数据接收模块从源设备获取传输数据之后还包括：
    所述数据接收模块判断接收到的传输数据是否为经过封装的数据；如果是，则从所述传输数据中获取更新方式信息，确定本次固件所采用的更新方式。
  10. 如权利要求1至7任一项所述的嵌入式设备固件更新方法，其特征在于，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之前还包括：
    所述数据接收模块判断所述更新数据是否执行过加密处理；如果是，则依据所述传输数据中的加密类型信息，对所述更新数据进行解密处理。
  11. 如权利要求1至7任一项所述的嵌入式设备固件更新方法，其特征在于，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之前还包括：
    所述数据接收模块依据所述传输数据中的完整性校验参数信息，对接收到的更新数据是否完整进行校验。
  12. 如权利要求1至7任一项所述的嵌入式设备固件更新方法，其特征在于，在所述数据接收模块将所述更新数据写入到存储传输数据的分区之后还包括：
    所述数据接收模块将所述存储传输数据的分区设置为待引导分区，以使所述数据处理模块从所述存储传输数据的分区中获取所述传输数据。
  13. 如权利要求12所述的嵌入式设备固件更新方法，其特征在于，所述数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之前还包括：
    所述数据处理模块从所述传输数据中获取文件头信息，对所述文件头信息进行校验。
  14. 如权利要求12所述的嵌入式设备固件更新方法，其特征在于，所述数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之前还包括：
    所述数据处理模块从所述传输数据中获取更新数据的签名信息，对所述签名信息进行校验。
  15. 如权利要求12所述的嵌入式设备固件更新方法，其特征在于，所述 数据处理模块在运行引导加载程序期间从存储新固件数据的分区中应用所述新固件数据之后还包括：
    所述数据处理模块从所述传输数据中获取完整性校验参数信息，对写入到所述存储新固件数据的分区的数据是否完整进行校验。
  16. 如权利要求15所述的嵌入式设备固件更新方法，其特征在于，所述更新方式信息识别本次固件所采用的更新方式为差分更新或压缩更新时，在所述数据处理模块从所述传输数据中获取完整性校验参数，对写入到所述存储新固件数据的分区的数据是否完整进行校验之后还包括：
    若完整性校验通过，则所述数据处理模块执行将所述存储新固件数据的分区设置为待引导分区的操作；若完整性校验未通过，则所述数据处理模块不执行将所述存储新固件数据的分区设置为待引导分区的操作。
  17. 一种嵌入式设备，其特征在于，包括：第一存储器以及第一处理器，所述第一存储器用于存储计算机程序，所述第一处理器用于执行所述计算机程序时实现如权利要求1至16任一项所述的嵌入式设备固件更新方法。
  18. 一种嵌入式设备固件更新方法，其特征在于，应用于开发端设备，所述方法包括：
    确定固件更新所采用的更新方式，生成更新方式信息；
    依据所述更新方式信息，生成对应的更新数据；
    基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据。
  19. 如权利要求18所述的嵌入式设备固件更新方法，其特征在于，所述依据所述更新方式信息，生成对应的更新数据包括：
    所述更新方式信息为差分更新时，生成的更新数据为补丁数据；
    所述更新方式信息为压缩更新时，生成的更新数据为压缩后的数据；
    所述更新方式信息为全量更新时，生成的更新数据为新固件数据。
  20. 如权利要求18所述的嵌入式设备固件更新方法，其特征在于，所述传输数据进一步包括以下信息的任意一种或任意组合：
    文件头信息、更新数据的签名信息、对所述更新数据进行加密的加密类型信息、文件格式版本信息、更新数据的版本信息、对数据是否经过封 装的校验信息、压缩算法信息、差分更新算法信息、更新数据的长度信息、完整性校验参数信息、签名信息、版本校验信息或摘要校验信息。
  21. 如权利要求18至20任一项所述的嵌入式设备固件更新方法，其特征在于，在所述基于所述更新数据以及更新方式信息，生成供所述嵌入式设备进行固件更新的传输数据之后还包括：
    将所述传输数据发送至源设备进行存储。
  22. 一种开发端设备，其特征在于，包括：第二存储器以及第二处理器，所述第二存储器用于存储计算机程序，所述第二处理器用于执行所述计算机程序时实现如权利要求18至21任一项所述的嵌入式设备固件更新方法。
  23. 一种嵌入式设备固件更新系统，其特征在于，包括如权利要求17所述的嵌入式设备以及源设备；所述源设备存储有供所述嵌入式设备固件更新的传输数据。
  24. 如权利要求23所述的嵌入式设备固件更新系统，其特征在于，所述源设备为开发端设备或云端设备。
PCT/CN2023/089849 2022-05-09 2023-04-21 嵌入式设备固件更新方法、嵌入式设备、开发端设备 WO2023216845A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210501784.0 2022-05-09
CN202210501784.0A CN114780127A (zh) 2022-05-09 2022-05-09 嵌入式设备固件更新方法、嵌入式设备、开发端设备

Publications (1)

Publication Number Publication Date
WO2023216845A1 true WO2023216845A1 (zh) 2023-11-16

Family

ID=82436605

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/089849 WO2023216845A1 (zh) 2022-05-09 2023-04-21 嵌入式设备固件更新方法、嵌入式设备、开发端设备

Country Status (2)

Country Link
CN (1) CN114780127A (zh)
WO (1) WO2023216845A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114780122A (zh) * 2022-04-11 2022-07-22 乐鑫信息科技（上海）股份有限公司 嵌入式设备固件更新方法以及嵌入式设备
CN114780127A (zh) * 2022-05-09 2022-07-22 乐鑫信息科技（上海）股份有限公司 嵌入式设备固件更新方法、嵌入式设备、开发端设备
CN116594661B (zh) * 2023-07-19 2023-09-19 成都泰格微电子研究所有限责任公司 一种编译阶段确保固件与工程匹配的单片机升级方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120102477A1 (en) * 2010-10-21 2012-04-26 Samsung Electronics Co., Ltd. Firmware update method and apparatus for a mobile device
CN106020861A (zh) * 2016-05-05 2016-10-12 惠州Tcl移动通信有限公司 一种智能手表的fota升级方法及系统
CN111212121A (zh) * 2019-12-24 2020-05-29 浙江大学 一种用于物联网设备的空中固件升级方法及系统
CN111831308A (zh) * 2020-04-15 2020-10-27 腾讯科技（深圳）有限公司 快充设备的固件更新方法、程序、快充设备及存储介质
CN113986313A (zh) * 2021-12-09 2022-01-28 北京奕斯伟计算技术有限公司 软件升级方法、装置、电子设备以及存储介质
CN114780127A (zh) * 2022-05-09 2022-07-22 乐鑫信息科技（上海）股份有限公司 嵌入式设备固件更新方法、嵌入式设备、开发端设备

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120102477A1 (en) * 2010-10-21 2012-04-26 Samsung Electronics Co., Ltd. Firmware update method and apparatus for a mobile device
CN106020861A (zh) * 2016-05-05 2016-10-12 惠州Tcl移动通信有限公司 一种智能手表的fota升级方法及系统
CN111212121A (zh) * 2019-12-24 2020-05-29 浙江大学 一种用于物联网设备的空中固件升级方法及系统
CN111831308A (zh) * 2020-04-15 2020-10-27 腾讯科技（深圳）有限公司 快充设备的固件更新方法、程序、快充设备及存储介质
CN113986313A (zh) * 2021-12-09 2022-01-28 北京奕斯伟计算技术有限公司 软件升级方法、装置、电子设备以及存储介质
CN114780127A (zh) * 2022-05-09 2022-07-22 乐鑫信息科技（上海）股份有限公司 嵌入式设备固件更新方法、嵌入式设备、开发端设备

Also Published As

Publication number Publication date
CN114780127A (zh) 2022-07-22

Similar Documents

Publication Publication Date Title
WO2023216845A1 (zh) 嵌入式设备固件更新方法、嵌入式设备、开发端设备
US8880049B2 (en) Wireless communication apparatus and wireless communication method
Moran et al. A firmware update architecture for internet of things
RU2419839C2 (ru) Система и способ обновления программы для мобильного терминала с поддержкой ота
WO2019062635A1 (zh) 升级方法和装置
JP5576983B2 (ja) 非ローカル記憶装置からのサブシステムのセキュアなブート及び構成
CN112912847B (zh) 空中下载升级的方法及相关装置
TWI518595B (zh) 軟體更新方法及系統以及行動裝置
WO2011127845A2 (zh) 一种移动通信终端间进行系统升级的方法、系统及终端
CN103645910A (zh) 用于更新应用程序的方法
KR101541112B1 (ko) Ｆｏｔａ 시스템 및 그 실행 방법
EP3148114A1 (en) Device management session triggering method, device, system and computer storage medium
US20140068598A1 (en) Information processing apparatus, information processing method, and program
CN111459524A (zh) 软件的升级方法、装置、系统
WO2009129687A1 (zh) Wimax终端及其启动方法
EP3764224B1 (en) Resource permission processing method and apparatus, and storage medium and chip
WO2023198056A1 (zh) 嵌入式设备固件更新方法以及嵌入式设备
CN105242910A (zh) 基于中间件插件框架的插件状态控制方法及客户端
CN110955442B (zh) 一种适用于PCI-E密码卡的Bootloader
WO2023092994A1 (zh) 嵌入式软件的加密式差分升级方法、装置、设备及介质
CN113691619B (zh) 一种报文处理方法、装置、电子设备及存储介质
JP2003173260A (ja) 遠隔プログラム更新システム
CN108365973A (zh) 用于在虚拟隧道上进行传输的方法和设备
CN114138317A (zh) 一种软件增量升级的方法和系统
CN111897562A (zh) 一种程序升级方法和设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23802619

Country of ref document: EP

Kind code of ref document: A1