A method for updating ZYNQ local firmware based on USB interface

Abstract

The application discloses a kind of based on USB interface's ZYNQ local firmware update method, the PS end of ZYNQ is used as processing hub, for U disk identification, user interaction, firmware reading, firmware verification and burning, after system normal start and run, insert the U disk containing new firmware file;The management program of the PS end of ZYNQ running is parsed to the firmware package read into memory, synchronously starts three independent burning threads or processes, is responsible for the update of boot partition, start partition and program partition respectively.Utilize USB mass storage device (U disk) as update carrier, so that field personnel need not professional training, can complete firmware update by the operation of "inserting U disk".This design transforms complex system maintenance task into zero threshold user interaction, especially suitable for network coverage inconvenient or operating personnel technical background various industrial field, terminal equipment and so on.

Description

Technical Field

[0001] This invention relates to ZYNQ local firmware update technology, and more particularly to a method for ZYNQ local firmware update based on a USB interface. Background Technology

[0002] In the field of embedded systems, especially on heterogeneous platforms such as the ZYNQ (XC7Z020) that integrate a processor system (PS) and programmable FPGA logic (PL), system firmware is complex. A complete system firmware not only includes a bootloader, operating system kernel, and applications, but also a bitstream file configuring the PL-side hardware functions. As device functionality continues to expand, firmware upgrades have become an essential means of fixing vulnerabilities, improving performance, and adding new features throughout the product lifecycle.

[0003] However, in field applications such as industrial control and IoT gateways, devices are often deployed in a dispersed and numerous manner, and most lack a stable and reliable network environment. This reality poses a significant challenge to firmware update technology, urgently requiring a localized solution that allows field personnel to quickly, securely, and reliably complete the entire system upgrade without relying on a network.

[0004] Existing technology and its limitations:

[0005] Existing firmware update methods for such embedded systems all have significant limitations.

[0006] The commonly used JTAG interface update method in the industry is frequently employed during the development phase, but it is complex and inefficient. This method requires expensive dedicated simulators and supporting software, as well as operators with specialized technical backgrounds. Furthermore, the cumbersome process makes it particularly unsuitable for the rapid maintenance needs of large-scale field deployments.

[0007] While another remote network update method solves the geographical distance problem, it has significant limitations. This method heavily relies on a stable and reliable network environment, making it difficult to implement in scenarios with poor network coverage, such as factory workshops or remote areas. Furthermore, this method requires an additional update device to connect to the update terminal, increasing the number of components needed. The security risks posed by the network environment cannot be ignored; the system needs to incorporate complex security mechanisms to prevent firmware tampering, which undoubtedly increases the complexity and cost of the system design.

[0008] Another simple replacement method is based on an SD card. This method directly places the running system and programs on the SD card, and replaces the SD card when an update is needed. While it offers the convenience of local updates, its functionality is too limited, making it difficult to perform complex operations such as security checks, and firmware information is easily modified. Removable SD cards are prone to loosening during transportation, causing system instability. More importantly, this method is prone to version incompatibility, which can easily lead to serious consequences such as the system failing to boot.

[0009] In summary, existing methods are either overly complex, overly reliant on external conditions, or unable to efficiently and reliably complete the overall update of heterogeneous systems. Therefore, there is an urgent need for a local firmware update solution that integrates universality, convenience, update completeness, efficiency, and high reliability.

[0010] In view of this, the present invention is hereby proposed. Summary of the Invention

[0011] The purpose of this invention is to provide a method for local firmware update of ZYNQ based on a USB interface, so as to solve the above-mentioned technical problems existing in the prior art.

[0012] The objective of this invention is achieved through the following technical solution:

[0013] A method for local firmware update of ZYNQ based on USB interface, using ZYNQ's PS terminal as the processing center for USB flash drive recognition, user interaction, firmware reading, firmware verification and flashing, including the following steps:

[0014] After the system starts up and is running normally, insert the USB flash drive containing the new firmware file;

[0015] Subsequently, the USB controller recognizes it as a storage device, the system mounts it to the specified directory, and the firmware update management program then scans the directory to look for predefined firmware packages;

[0016] If a new firmware is detected, the management program will ask the user whether to initiate the update. The user can make the selection via the touchscreen or buttons.

[0017] If the user chooses to update, the entire firmware package file will be read into the system memory of the ZYNQ's PS terminal to avoid data incompleteness caused by unloading from the USB drive during the update process;

[0018] Afterwards, the management program running on the ZYNQ's PS end parses the firmware package read into memory;

[0019] After the data is verified, the ZYNQ PS terminal simultaneously starts three independent burning threads or processes, which are responsible for updating the boot partition, startup partition and program partition respectively.

[0020] Compared with existing technologies, the ZYNQ local firmware update method based on a USB interface provided by this invention utilizes a USB mass storage device (USB flash drive) as the update carrier, allowing field personnel to complete firmware updates simply by "inserting the USB flash drive" without requiring professional training. This design transforms complex system maintenance tasks into a zero-threshold user interaction, making it particularly suitable for industrial sites and terminal equipment where network coverage is inconvenient or where operators have diverse technical backgrounds. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating a method for local firmware update of ZYNQ based on a USB interface, as provided in an embodiment of the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them, and do not constitute a limitation on the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the protection scope of the present invention.

[0023] First, the following explanations are provided for the terms that may be used in this article:

[0024] The terms “including,” “contains,” “comprising,” “having,” or other similar semantic descriptions shall be interpreted as non-exclusive inclusion.

[0025] The term "composed of" excludes any technical features not expressly listed. When used in a claim, it closes the claim to exclude all technical features other than those expressly listed, except for associated conventional impurities. If the term appears only in a clause of a claim, it limits the claim to the elements expressly listed in that clause; elements recited in other clauses are not excluded from the overall claim.

[0026] The technical solution provided by this invention will be described in detail below. Contents not described in detail in the embodiments of this invention are prior art known to those skilled in the art. Where specific conditions are not specified in the embodiments of this invention, they shall be performed according to conventional conditions in the art or conditions recommended by the manufacturer. Reagents or instruments used in the embodiments of this invention whose manufacturers are not specified are all conventional products that can be purchased commercially.

[0027] like Figure 1As shown, a method for local firmware update of ZYNQ based on a USB interface uses the ZYNQ's PS terminal as a processing hub for USB flash drive recognition, user interaction, firmware reading, firmware verification, and flashing, including the following steps:

[0028] After the system starts up and is running normally, insert the USB flash drive containing the new firmware file;

[0029] Subsequently, the USB controller recognizes it as a storage device, the system mounts it to the specified directory, and the firmware update management program then scans the directory to look for predefined firmware packages;

[0030] If a new firmware is detected, the management program will ask the user whether to initiate the update. The user can make the selection via the touchscreen or buttons.

[0031] If the user chooses to update, the entire firmware package file will be read into the system memory of the ZYNQ's PS terminal to avoid data incompleteness caused by unloading from the USB drive during the update process;

[0032] Afterwards, the management program running on the ZYNQ's PS end parses the firmware package read into memory;

[0033] After the data is verified, the ZYNQ PS terminal simultaneously starts three independent burning threads or processes, which are responsible for updating the boot partition, startup partition and program partition respectively.

[0034] The firmware package is a packaged and formatted file that is divided into three file areas: the flash boot partition, the EMMC boot image partition, and the EMMC program file system partition, and contains necessary data verification information.

[0035] The management program parses out the independent data segments of these three file areas and verifies the data to prepare for subsequent parallel burning.

[0036] Use CRC32 for verification to avoid errors during transmission; if the verification fails, the update will be canceled.

[0037] In addition, the management program can identify the version of each partition and decide whether to update based on whether the versions match.

[0038] After verification, the ZYNQ PS terminal simultaneously starts three independent burning threads or processes, which are responsible for updating the boot partition, startup partition and program partition respectively.

[0039] The burning and updating of the boot partition, startup partition, and program partition respectively include:

[0040] Burn the QSPI-FLASH boot partition:

[0041] First, read the firmware version of the flash partition for matching. If an update is needed, write the data of the "flash boot partition" in the firmware package to the boot partition of QSPI-FLASH.

[0042] This data segment is a complete boot image, which integrates the First Stage Bootloader, boot script files, and U-Boot; it can also contain a separate Linux kernel and device tree file as needed.

[0043] The burning process uses the flash library program operation interface of the Linux system to directly and completely write the boot image data to the specified address of the QSPI-FLASH;

[0044] If the versions match, the burning process will be skipped, and no update operation will be performed on the partition.

[0045] Burn the EMMC boot partition:

[0046] First, read the firmware version of the eMMC boot partition for matching. If an update is needed, write the data of the "boot image area" in the firmware package to the eMMC boot partition.

[0047] This data segment is typically a complete boot image, which integrates the FPGA bitstream file, the Linux kernel, and the device tree file;

[0048] The burning process writes the boot image data directly and completely to the specified boot partition of the EMMC through the block device operation interface of the Linux system.

[0049] If the versions match, the burning process will be skipped, and no update operation will be performed on the partition.

[0050] Burning EMMC program partition:

[0051] First, read the firmware version of the eMMC program partition for matching. If an update is needed, write the data of the "program file system area" in the firmware package to the eMMC program partition.

[0052] This data segment is typically a compressed root file system archive that contains operating system libraries, user interface applications, configuration files, and the software required to run the system.

[0053] The burning process may first require unloading the currently running program partition to ensure data integrity, and then decompressing the new file system data and writing it to the EMMC's program partition.

[0054] For full image updates, a pre-made file system image is written directly.

[0055] If the versions match, the burning process will be skipped, and no update operation will be performed on the partition.

[0056] ZYNQ's PS-side management program waits for all three parallel burning steps to complete before executing a data synchronization command to ensure that all data has been physically written to the Flash / EMMC memory.

[0057] Subsequently, the management program records the successful update status and triggers a system restart;

[0058] After the system restarts, it will load the boot partition from the updated boot partition, then mount and run the updated program partition, thus completing the entire firmware update process.

[0059] In summary, the ZYNQ local firmware update method based on the USB interface of this invention constructs a highly integrated, efficient, and reliable local firmware update system. Its principle deeply aligns with the system architecture characteristics of heterogeneous computing platforms like ZYNQ and fully leverages the versatility and convenience of the USB interface. Traditional update methods, such as those using JTAG or network interfaces, often require dedicated emulators, specific software environments, or complex network configurations, limiting rapid deployment in the field.

[0060] This invention utilizes a USB mass storage device (USB flash drive) as the update medium, allowing on-site personnel to complete firmware updates simply by "inserting the USB flash drive" without requiring specialized training. This design transforms complex system maintenance tasks into a user-friendly, barrier-free interaction, making it particularly suitable for industrial sites and terminal equipment environments with poor network coverage or where operators have diverse technical backgrounds.

[0061] To more clearly demonstrate the technical solution and its effects provided by the present invention, the following detailed description of the method for local firmware update of ZYNQ based on USB interface provided by the present invention is based on specific embodiments.

[0062] Traditional ZYNQ platform update methods often separate FLASH and EMMC updates, resulting in cumbersome and inefficient steps.

[0063] This invention defines a special firmware package format that logically integrates the boot image (containing U-Boot, First Stage Bootloader, and boot scripts), the boot image area (containing FPGA bitstream, kernel, and device tree), and the program file system area (containing root file system and applications). This allows a single update operation to simultaneously complete a comprehensive upgrade of the flash / eMMC. This not only simplifies the operation but also ensures consistency between the PS and PL versions at the system level, avoiding risks such as system boot failures due to version incompatibility.

[0064] To improve update efficiency, this invention introduces a "parsing-verification-parallel burning" execution mechanism. Unlike the traditional sequential burning method, after the system reads the firmware package into memory via the USB interface, it fully utilizes the multi-tasking capabilities of the ZYNQ PS terminal to simultaneously launch three independent burning processes, which respectively verify and burn the FLASH boot partition, EMMC boot partition, and EMMC program partition. This ensures the efficient completion of the entire process.

[0065] Ultimately, the intelligent central hub coordinating all of this is located on the ZYNQ's PS terminal. By running a complete Linux operating system and update management program, this invention endows the update process with powerful "intelligence" and "robustness." The management program can not only drive the USB interface and parse the file system, but also call upon rich software resources to digitally sign and verify the integrity of the firmware package, thereby preventing the intrusion of malicious software while taking advantage of the universal convenience of USB.

[0066] In summary, this invention organically integrates four core principles—the convenience of the USB interface, the unified encapsulation system thinking, the efficient parallel burning strategy, and the secure control of the intelligent hub—to form a complete solution. It achieves the goal of efficient, secure, and one-click firmware updates for complex heterogeneous embedded systems in an offline environment, demonstrating significant technological advancement and practical value.

[0067] Example 1

[0068] The specific implementation method of the present invention is as follows: Figure 1 As shown, its core function is to use the ZYNQ's PS terminal as the processing hub, which is responsible for USB flash drive identification, user interaction, firmware reading, firmware verification and burning.

[0069] After the system boots up and runs normally, insert the USB drive containing the new firmware file. The USB controller then recognizes it as a storage device, and the system mounts it to the specified directory. The firmware update management program then scans this directory, searching for predefined firmware packages. If new firmware is found, the management program will ask the user whether to initiate the update. The user can select this via the touchscreen or buttons. If the user selects to update, the entire firmware package file is read into the system memory (DDR) of the ZYNQ PS terminal to prevent data incompleteness caused by unmounting the USB drive during the update process.

[0070] The management program running on the ZYNQ PS terminal is responsible for parsing the firmware package read into memory. The firmware package used in this invention is a specially packaged and formatted file, divided into three sections: a flash boot sector, an EMMC boot image sector, and an EMMC program file system sector, containing necessary data verification information. The management program parses these three independent data sections and verifies the data, preparing for subsequent parallel flashing. CRC32 verification is used to avoid errors during transmission. If verification fails, the update is canceled. Furthermore, the management program can identify the version of each partition and decide whether to update based on version matching.

[0071] After successful verification, the ZYNQ PS terminal simultaneously starts three independent burning threads or processes, each responsible for updating the boot partition, startup partition, and program partition respectively:

[0072] Burn the QSPI-FLASH boot partition:

[0073] First, the firmware version of the flash partition is read for matching. If an update is required, the data from the "flash boot sector" in the firmware package is written to the boot partition of the QSPI-FLASH. This data segment is a complete boot image, which integrates the First Stage Bootloader, boot script files, and U-Boot; depending on the requirements, it may contain a separate Linux kernel and device tree file. This burning process uses the Linux system's flash library program operation interface to directly and completely write the boot image data to the specified address of the QSPI-FLASH. If the version matches, the burning process is skipped, and no update operation is performed on the partition.

[0074] Burn the EMMC boot partition:

[0075] First, the firmware version of the eMMC boot partition is read and matched. If an update is required, the data from the "boot image area" in the firmware package is written to the eMMC boot partition. This data segment is typically a complete boot image, integrating the FPGA bitstream file, Linux kernel, and device tree file. This programming process directly and completely writes the boot image data to the specified eMMC boot partition through the Linux system's block device operation interface. If the version matches, programming is skipped, and no update operation is performed on the partition.

[0076] Burning EMMC program partition:

[0077] First, the firmware version of the eMMC program partition is read and matched. If an update is required, the data from the "program file system area" in the firmware package is written to the eMMC program partition. This data segment is typically a compressed root file system archive containing all the necessary software for operation, including operating system libraries, user interface applications, configuration files, etc. This flashing process may first need to unmount the currently running program partition to ensure data integrity, and then decompress the new file system data and write it to the eMMC program partition. For a full image update, a pre-made file system image is written directly. If the version matches, flashing is skipped, and no update operation is performed on the partition.

[0078] The ZYNQ PS-side management program waits for the three parallel burning steps to complete before executing a data synchronization command to ensure all data has been physically written to the Flash / EMMC memory. Subsequently, the management program records the successful update status and triggers a system reboot. After rebooting, the system will load the updated boot partition, mount and run the updated program partition, thus completing the entire firmware update process.

[0079] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims. The information disclosed in the background section is intended only to enhance the understanding of the overall background technology of the present invention and should not be construed as an admission or implication in any way that such information constitutes prior art known to those skilled in the art.

Claims

1. A method for local firmware update of ZYNQ based on a USB interface, characterized in that, The ZYNQ's PS terminal is used as the processing hub for USB flash drive identification, user interaction, firmware reading, firmware verification, and flashing, including the following steps: After the system starts up and is running normally, insert the USB flash drive containing the new firmware file; Subsequently, the USB controller recognizes it as a storage device, the system mounts it to the specified directory, and the firmware update management program then scans the directory to look for predefined firmware packages; If a new firmware is detected, the management program will ask the user whether to initiate the update. The user can make the selection via the touchscreen or buttons. If the user chooses to update, the entire firmware package file will be read into the system memory of the ZYNQ's PS terminal to avoid data incompleteness caused by unloading from the USB drive during the update process; Afterwards, the management program running on the ZYNQ's PS end parses the firmware package read into memory; After the data is verified, the ZYNQ PS terminal simultaneously starts three independent burning threads or processes, which are responsible for updating the boot partition, startup partition and program partition respectively.

2. The method for local firmware update of ZYNQ based on a USB interface according to claim 1, characterized in that, The firmware package is a packaged and formatted file that is divided into three file areas: the flash boot partition, the EMMC boot image partition, and the EMMC program file system partition, and contains necessary data verification information.

3. The method for local firmware update of ZYNQ based on a USB interface according to claim 2, characterized in that, The management program parses out the independent data segments of these three file areas and verifies the data to prepare for subsequent parallel burning.

4. The method for local firmware update of ZYNQ based on a USB interface according to claim 3, characterized in that, Use CRC32 for verification to avoid errors during transmission; if the verification fails, the update will be canceled. In addition, the management program can identify the version of each partition and decide whether to update based on whether the versions match.

5. The method for local firmware update of ZYNQ based on a USB interface according to claim 4, characterized in that, After verification, the ZYNQ PS terminal simultaneously starts three independent burning threads or processes, which are responsible for updating the boot partition, startup partition and program partition respectively.

6. The method for local firmware update of ZYNQ based on a USB interface according to claim 5, characterized in that, The burning and updating of the boot partition, startup partition, and program partition respectively include: Burn the QSPI-FLASH boot partition: First, read the firmware version of the flash partition for matching. If an update is needed, write the data of the "flash boot partition" in the firmware package to the boot partition of QSPI-FLASH. This data segment is a complete boot image, which integrates the First Stage Bootloader, boot script files, and U-Boot; it can also contain a separate Linux kernel and device tree file as needed. The burning process uses the flash library program operation interface of the Linux system to directly and completely write the boot image data to the specified address of the QSPI-FLASH; If the versions match, the burning process will be skipped, and no update operation will be performed on the partition. Burn the EMMC boot partition: First, read the firmware version of the eMMC boot partition for matching. If an update is needed, write the data of the "boot image area" in the firmware package to the eMMC boot partition. This data segment is typically a complete boot image, which integrates the FPGA bitstream file, the Linux kernel, and the device tree file; The burning process writes the boot image data directly and completely to the specified boot partition of the EMMC through the block device operation interface of the Linux system. If the versions match, the burning process will be skipped, and no update operation will be performed on the partition. Burning EMMC program partition: First, read the firmware version of the eMMC program partition for matching. If an update is needed, write the data of the "program file system area" in the firmware package to the eMMC program partition. This data segment is typically a compressed root file system archive that contains operating system libraries, user interface applications, configuration files, and the software required to run the system. The burning process may first require unloading the currently running program partition to ensure data integrity, and then decompressing the new file system data and writing it to the EMMC's program partition. For full image updates, a pre-made file system image is written directly. If the versions match, the burning process will be skipped, and no update operation will be performed on the partition.

7. The method for local firmware update of ZYNQ based on a USB interface according to any one of claims 1 to 6, characterized in that, ZYNQ's PS-side management program waits for all three parallel burning steps to complete before executing a data synchronization command to ensure that all data has been physically written to the Flash / EMMC memory. Subsequently, the management program records the successful update status and triggers a system restart; After the system restarts, it will load the boot partition from the updated boot partition, then mount and run the updated program partition, thus completing the entire firmware update process.

Images