Multi-storage medium and multi-system online upgrading method based on ZYNQ embedded system

Abstract

The application provides a multi-storage medium and multi-system online upgrading method based on ZYNQ embedded system, the method divides a nonvolatile memory into a Golden program area and an upgraded program area; after power-on of the device, the Golden program is loaded to a DDR high address for running, thereby effectively avoiding memory address conflict during FPGA bit stream loading; the Golden program requests upgrading through a network port, if there is no upgrading instruction, Header information of the upgraded area is analyzed, a bare machine APP, UBOOT or FPGA bit stream is dynamically guided; if there is an upgrading instruction, a new program is received and written into the upgraded area and is verified.The application has the beneficial effects that the upgrading brick risk and address conflict problem are solved, and safe and flexible upgrading of the multi-system is realized.

Description

Technical Field

[0001] This invention belongs to the field of embedded system technology, and in particular relates to a method for online upgrade of multiple storage media and multiple systems based on ZYNQ embedded systems. Background Technology

[0002] The ZYNQ series chips integrate ARM processors and FPGA logic, and are widely used in industrial control, communications, and other fields. In these applications, the device firmware, including FSBL, FPGA bitstream, U-Boot, and operating system kernel, often needs to be upgraded online as features are updated.

[0003] Existing ZYNQ online upgrade solutions typically have the following problems: (1) High upgrade risk. If a power outage or data verification error occurs during the upgrade process, the system may fail to start, and there is a lack of reliable rollback mechanism. (2) Address conflict risk. When loading the FPGA bit stream, the configuration process may occupy the low address space of DDR memory. If the upgrade program or boot program runs in the low address DDR area at this time, the running code will be overwritten or polluted, causing the program to crash or the system to crash. (3) Poor startup flexibility. The traditional partition table is fixed and it is difficult to flexibly support the mixed startup of bare metal programs and Linux system programs and environment variable configuration, making it difficult for an upgrade program to support different types of systems for online upgrades. (4) Existing solutions occupy a lot of space. In the existing technology, the two programs Updateimage and golden image are packaged with very high structural redundancy, resulting in a flash space occupation of 1 times more. Therefore, flash smaller than 32M cannot be used at all, increasing hardware costs. Moreover, Update image and golden image must be packaged into a larger BOOT.bin for the first burning. The two programs cannot be burned completely independently, resulting in a long single burning time. (5) In the prior art, users need to update the update image through the golden image program every time. If the fsbl in the update image has a functional problem and cannot be started, it is impossible to switch to the fsbl in the golden image to start the backup file. (6) In the prior art, if the user program in the update image encounters an error, the FSBL still needs to traverse other backup images in the flash memory in 32kb units. This will result in a very slow startup time, which can be measured in minutes, and users often cannot accept this. This is because two images are packaged into a larger image. The standard header information carried by this larger image contains the packet information of the current update image. If the size of the update image that is updated separately is different from the original size, the mismatch in header information will pose a startup risk. (7) In the prior art, QSPI flash must erase the existing data before writing new data. Therefore, after the device powers on, it reads the program in the flash into the DDR and runs it. When the program in the DDR receives the upgrade command, it needs to erase the program in the flash first. If the device loses power during the erasure, the erased data cannot be recovered, resulting in the program stored in the device's flash being damaged, and the device becoming unusable. Assuming that the erasure and file writing are correct and the data read from the flash is also correct, if the image updated remotely has functional problems and cannot be used normally, it will also prevent remote updates from being performed again.

[0004] Therefore, a ZYNQ online upgrade solution is needed that can ensure upgrade security, avoid memory address conflicts, and support multi-system booting. Summary of the Invention

[0005] In view of this, the present invention aims to propose an online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded systems, so as to solve the problems of high upgrade risk, address conflict risk and poor startup flexibility in the existing technology.

[0006] To achieve the above objectives, the technical solution of the present invention is implemented as follows: A method for online upgrade of multiple storage media and multiple systems based on ZYNQ embedded systems includes the following steps: S1. Storage Resource Planning: The non-volatile memory of the ZYNQ platform is divided into an upgrade bootloader storage area and a user program storage area; the upgrade bootloader storage area is used to store the upgrade bootloader, and the user program storage area is used to store the user program package to be upgraded; the upgrade bootloader includes FSBL and Golden program; S2. Upgrade bootloader startup: After the device is powered on, the FSBL loads the Golden program into the high address region of DDR memory and runs it; S3. Send upgrade request: The Golden program sends an upgrade request through the communication interface; S4. Wait for a reply and proceed with branch processing: If an upgrade reply is received, enter upgrade mode: Receive user program package data sent from outside, write it into the user program storage area, and perform data verification after writing is completed; If no upgrade reply is received or the data verification passes within a preset time, enter system boot mode: Read the header information of the user program storage area, parse the header information to identify the type of user program package, and load the corresponding program into the specified location of DDR memory for execution according to the identification result.

[0007] Furthermore, in step S4, loading the corresponding program into a specified location in DDR memory for execution based on the identification result includes: If it is identified as an FPGA bitstream, then the FPGA bitstream is loaded into the FPGA logic section for configuration; If the system is identified as the second-level bootloader UBOOT, then the second-level bootloader UBOOT is copied to DDR memory, started, and booted by the second-level bootloader UBOOT to start the Linux operating system. If it is identified as a bare-metal application (APP), then the bare-metal application is copied to DDR memory and launched directly; If the program is identified as the first-level bootloader FSBL, then skip the program and continue parsing the next entry in the header information.

[0008] Furthermore, the user program package includes header information, which is automatically generated by the packaging software when packaging the user program package, and the header information is located at the beginning of the user program storage area.

[0009] Furthermore, the Linux environment variable configuration of the second-level bootloader UBOOT is as follows: the offset address of the loaded Linux kernel is increased by the size of the upgrade bootloader storage area to compensate for the physical address offset caused by the occupation of the upgrade bootloader storage area.

[0010] Furthermore, in step S2, the high address region of the DDR memory is at address 0x10000000; The Golden program runs in the high address region to avoid the Golden program code being overwritten during the FPGA bitstream configuration process, which occupies the low address space of DDR memory.

[0011] Furthermore, the non-volatile memory is a Flash memory with a capacity of 16MB or greater; the upgrade boot program storage area is located in the storage space from 0 to 2MB-1 of the Flash memory; the user program storage area is located in the storage space from 2MB to the end of the Flash memory.

[0012] Compared with existing technologies, the online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded systems described in this invention has the following advantages: (1) The ZYNQ embedded multi-storage medium and multi-system online upgrade method described in this invention has high reliability. By retaining the Golden program area, it ensures that the device can be repeatedly upgraded after power-on when the upgrade fails. It ensures that the whole machine can be repeatedly and reliably upgraded until the upgrade is successful without disassembling the whole machine. It can run safely by migrating the Golden program running address to 256MB of DDR, which effectively avoids the occupation conflict of low address memory during FPGA bit stream loading and prevents the program from running away. It has flexible compatibility function. Through automatic HEADER generation and parsing mechanism, it can support online upgrade of multiple bare metal systems or Linux and FreeRTOS systems. (2) The online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded system described in this invention has a small program size and less flash space because the Golden image and update image (user program) are not redundant backups of each other, thus saving hardware costs. Furthermore, the Golden image and update image (user program) are decoupled, i.e., they are generated separately. This ensures that the packet information carried in the standard header structure is consistent with the entire packet, and also saves a lot of burning time.

[0013] (3) The online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded system described in this invention is that the Golden image of this invention is only responsible for starting and updating the update image (user program). It has a single function and stronger robustness. After being decoupled from the user program, it does not need to be updated repeatedly. It only needs to be burned once with JTAG during the entire life cycle of the device. After that, the user program can be remotely updated. It can also avoid the risk that if the fsbl in the update image has a functional problem and cannot start, it will be impossible to switch to the fsbl in the golden image to start the backup file.

[0014] (4) The online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded in this invention has modified the fsbl in the Golden image. It does not need to traverse the entire flash in 32kb units to find the next correct image standard header structure, but directly calls the user program, which greatly shortens the program startup time and improves the real-time performance of the program.

[0015] (5) The online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded according to the present invention has only user functions in the update image and can be remotely updated in any environment. During the update process, since the golden image only erases the user area data for updating, no matter what unexpected situation is encountered or the updated program has functional problems, the user program can be upgraded again by restarting the device and entering the golden image. Attached Figure Description

[0016] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram of storage resource planning according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the upgrade bootloader construction and solidification process described in an embodiment of the present invention; Figure 3 This is a schematic diagram of the user program package described in an embodiment of the present invention; Figure 4 This is a schematic diagram of the Golden program upgrade process according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the user package loading process according to an embodiment of the present invention; Figure 6 This is a schematic diagram of Linux environment variable configuration as described in an embodiment of the present invention; Figure 7 A schematic diagram of the minimum hardware system for an application example; Figure 8 A schematic diagram of the SDK hardware driver interface for an application example; Figure 9 A schematic diagram of the packaged Golden program for application instances; Figure 10 A schematic diagram illustrating the Golden program burning process for an application example; Figure 11 This is a schematic diagram of the host computer configuration interface for upgrading an application instance. Detailed Implementation

[0017] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0018] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0019] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0020] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] like Figures 1 to 6 As shown, the online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded systems includes the following steps: S1. Storage Resource Planning: The non-volatile memory of the ZYNQ platform is divided into an upgrade bootloader storage area and a user program storage area; the upgrade bootloader storage area is used to store the upgrade bootloader, and the user program storage area is used to store the user program package to be upgraded; the upgrade bootloader includes FSBL and Golden program; S2. Upgrade bootloader startup: After the device is powered on, the FSBL loads the Golden program into the high address region of DDR memory and runs it; S3. Send upgrade request: The Golden program sends an upgrade request through the communication interface; S4. Wait for a reply and proceed with branch processing: If an upgrade reply is received, enter upgrade mode: Receive user program package data sent from outside, write it into the user program storage area, and perform data verification after writing is completed; If no upgrade reply is received or the data verification passes within a preset time, enter system boot mode: Read the header information of the user program storage area, parse the header information to identify the type of user program package, and load the corresponding program into the specified location of DDR memory for execution according to the identification result.

[0022] The beneficial effects of this invention are: It boasts high reliability by preserving the Golden program area, ensuring repeated upgrades after power-on in case of upgrade failure. This allows for multiple stable and reliable upgrades without disassembling the entire device until a successful upgrade is achieved. It ensures safe operation by migrating the Golden program's execution address to 256MB of DDR memory, effectively avoiding memory conflicts during FPGA bitstream loading and preventing program crashes. It also features flexible compatibility, supporting online upgrades for multiple bare-metal systems or Linux and FreeRTOS systems through automatic header generation and parsing mechanisms.

[0023] Because the Golden image and update image (user program) of this invention are not redundant backups of each other, the program is small, occupies less flash space, and saves hardware costs. Furthermore, the Golden image and update image (user program) of this invention are decoupled, that is, they are generated separately. This ensures that the packet information carried in the standard header structure is consistent with the entire packet, and also saves a lot of burning time. The Golden image of this invention is only responsible for starting and updating the update image (user program). It has a single function and is more robust. After being decoupled from the user program, it does not need to be updated repeatedly. It only needs to be burned once with JTAG throughout the entire life cycle of the device. After that, remote updates of the user program can be realized. It can also avoid the risk that if the fsbl in the update image has a functional problem and cannot start, it will be impossible to switch to the fsbl in the Golden image to start the backup file. The fsbl in the Golden image of this invention has been modified. It does not need to traverse the entire flash in 32kb units to find the next correct image standard header structure. Instead, it directly calls the user program, which greatly shortens the program startup time and improves the real-time performance of the program. The update image of this invention has only user functionality and can be remotely updated in any environment. During the update process, since the golden image only erases the user area data for updating, no matter what unexpected situation occurs or if the updated program has functional problems, the user program can be upgraded again by restarting the device and entering the golden image.

[0024] In a preferred embodiment of the present invention, step S4, loading the corresponding program into a specified location in DDR memory for execution based on the identification result, includes: If it is identified as an FPGA bitstream, then the FPGA bitstream is loaded into the FPGA logic section for configuration; If the system is identified as the second-level bootloader UBOOT, then the second-level bootloader UBOOT is copied to DDR memory, started, and booted by the second-level bootloader UBOOT to start the Linux operating system. If it is identified as a bare-metal application (APP), then the bare-metal application is copied to DDR memory and launched directly; If the program is identified as the first-level bootloader FSBL, then skip the program and continue parsing the next entry in the header information.

[0025] In this embodiment, the FPGA bitstream contains connection information for all logic parts inside the FPGA, supports dynamic loading, and can update the hardware logic in real time during Linux operation.

[0026] In a preferred embodiment of the present invention, the user program package includes header information, which is automatically generated by the packaging software when packaging the user program package, and the header information is located at the beginning of the user program storage area. In this embodiment, the user program package is suitable for loading at boot time, is in pure binary format, and is suitable for dynamic loading during Linux operation.

[0027] In a preferred embodiment of the present invention, the Linux environment variable configuration of the second-level bootloader UBOOT is as follows: the offset address for loading the Linux kernel is increased by the size of the upgrade bootloader storage area to compensate for the physical address offset caused by the occupation of the upgrade bootloader storage area. In this embodiment, the Linux environment variable configuration can resolve Flash partition conflicts. When an independent upgrade bootloader storage area is partitioned in Flash, the starting address of the user program area will be shifted accordingly; UBOOT needs to compensate for this offset through environment variable configuration to ensure that the kernel image is loaded to the correct DDR address. The address offset must strictly correspond to the Flash partition plan, which is usually the size of the upgrade bootloader storage area.

[0028] In a preferred embodiment of the present invention, in step S2, the high address region of the DDR memory is at address 0x10000000; The Golden program runs in the high address region to avoid its code being overwritten during the FPGA configuration process, which occupies the low address space of DDR memory. In this embodiment, the high address region allows the Golden program to be loaded and run at address 0x10000000, avoiding memory conflicts with the FPGA configuration process; ensuring that the Golden program's code and data are not overwritten during FPGA configuration; automatically starting from the Golden program when user program upgrades fail or system startup is abnormal; and ensuring that the system can always be restored to a working basic state. Improve the reliability and stability of the system.

[0029] In a preferred embodiment of the present invention, the non-volatile memory is a Flash memory with a capacity of 16MB or greater; the upgrade bootloader storage area is located in the storage space from 0 to 2MB-1 of the Flash memory; the user program storage area is located in the storage space from 2MB to the end of the Flash memory. In this embodiment, the upgrade bootloader is stored in a separate 2MB partition to avoid interference with the user program, ensuring that the system can still boot from the upgrade bootloader area if the user program upgrade fails.

[0030] Example 1 In this embodiment, the method is based on the Xilinx ZYNQ series chip, which integrates an ARM processor and FPGA logic. By introducing the Golden Image protection mechanism, a high-address memory operation strategy, and dynamic header resolution technology, it solves the problems of easy bricking, memory address conflicts, and difficulty in supporting mixed booting of multiple systems (bare metal / Linux / RTOS) during traditional ZYNQ upgrades. Specifically, it includes the following steps: Step 1: As Figure 1 As shown, storage resource planning The non-volatile memory of the ZYNQ platform is divided into an upgrade bootloader storage area and a user program storage area. The upgrade bootloader storage area is used to store the upgrade bootloader, and the user program storage area is used to store the user program package to be upgraded (the program being upgraded). The upgrade bootloader includes FSBL (First Stage Boot Loader) and the Golden program.

[0031] Specifically, the non-volatile memory is a Flash memory with a capacity of ≥16MB, the bare metal capacity of the Flash memory must be ≥16MB, and the capacity with the Linux operating system must be ≥32MB; the upgrade boot program storage area is located in the storage space from 0 to 2MB-1 of the Flash memory; the user program storage area is located in the storage space from 2MB to the end of the Flash memory.

[0032] Step Two: As Figure 2 As shown, the upgrade bootloader is built and solidified. (1) Hardware resource setup In Vivado software, the ZYNQ processing system is built based on the target hardware schematic.

[0033] Specifically, configure the basic parameters of the ZYNQ7 Processing System; enable the Flash controller to store the program, and enable the Ethernet controller to receive upgrade data from the host computer; after configuration, export the hardware description file (.hdf) for use by the SDK.

[0034] (2) Software Engineering Creation and FSBL Generation Import the hardware platform exported from Vivado into the Xilinx SDK. The SDK will automatically generate an FSBL (First Stage Boot Loader) project based on the hardware configuration. The FSBL is the first software program executed after the ZYNQ is powered on. It is responsible for initializing DDR memory, configuring FPGA logic (PL part), and loading subsequent applications.

[0035] (3) Modify the compilation and linking address Before compiling the Golden program, modify its linker script (.ld file) to change the program's starting execution address to 0x10000000. Normally, programs run at low addresses in DDR (e.g., 0x00000000), but during FPGA bitstream loading, the hardware configuration process occupies low address space in DDR. If the Golden program runs at a low address, loading the FPGA configuration will overwrite its own code, causing the program to crash or freeze. By moving the Golden program to 0x10000000 (256MB offset), the memory occupied during FPGA configuration is completely avoided, ensuring the safety of the upgrade process.

[0036] (4) Compile and package to generate a complete program Write TCP client code in the SDK to implement functions such as receiving files, writing to Flash, and verification. Use the SDK's packaging tool to package and merge the FSBL and Golden program to generate a complete binary file, i.e., the upgrade bootloader, which is usually named Golden.bin.

[0037] (5) Burning and Deployment Using a JTAG debugger, the generated Golden.bin is burned into the Flash memory. The Flash memory starts at address 0x00000000, occupying the first 2MB of space, which establishes the Golden program area, i.e. the upgrade bootloader storage area. All subsequent user program upgrades can only be written from 2MB (0x200000) onwards, and the first 2MB of the Golden program can never be destroyed, thus achieving high reliability that can be recovered even if the device is bricked.

[0038] Step 3: As Figure 3 As shown, package the user program package When creating user application packages that require upgrades, a dynamic packaging mechanism is used.

[0039] At the beginning of the user program storage area, at an offset of 2MB in Flash, a header information HEADER, i.e., the file header, is automatically generated by the packaging software. Following the HEADER, the FSBL, FPGA bitstream, and bare-metal application APP or Linux operating system (including U-Boot, Kernel, and Rootfs) are stored sequentially. The HEADER records the type, length, and address information of subsequent files, enabling the Golden program to understand what is contained in the package.

[0040] Step Four: As Figure 4 As shown, the Golden program upgrade process (1) Upgrade bootloader startup: After the device is powered on, the hardened FSBL first loads and runs the Golden program. It should be noted that, based on the linker script modified in step two, the Golden program is loaded into the high address region of DDR memory to run. The high address region is 0x10000000. The Golden program runs in the high address region to avoid the Golden program code being overwritten due to the FPGA configuration process occupying the low address space of DDR memory during the loading of FPGA bitstream configuration.

[0041] (2) Send upgrade request: The Golden program actively sends an upgrade request command through the network port.

[0042] (3) Wait for a reply and perform branch processing: If an upgrade reply is received from the host computer, enter the upgrade mode, receive the user program package sent by the user, write it into the user program storage area of ​​Flash, i.e., the beginning of 2MB, and perform data verification after writing is completed; if no upgrade reply is received or the data verification is passed within the preset time (e.g., 3s), enter the system boot mode and perform the user program package loading process in step five.

[0043] In this embodiment, the Golden program is a secure boot image in the FPGA system, which is usually stored in a non-erasable ROM or a dedicated Flash partition, physically isolated from the user program area; it is firmly written at the factory and will not be modified or overwritten during the upgrade process; it has the highest boot priority to ensure that the system can restore basic functions under any abnormal situation; When allocating DDR address space, address 0x10000000 belongs to the high address region of DDR; this region avoids the low address space occupied during FPGA configuration, which is usually used to load bit streams. This design prevents the Golden program code from being accidentally overwritten during configuration, ensuring the reliability of the boot process.

[0044] In the partitioning of the user program storage area in Flash memory, a 2MB boundary is usually used as the dividing line between the Golden program area and the user program area; this partition size can accommodate the complete boot program while reserving enough space for the user program.

[0045] Step 5: As Figure 5 As shown, the user package loading process (1) Read HEADER: The Golden program reads the HEADER in the 2MB Flash memory and parses it according to the format.

[0046] (2) Dynamic loading: The content to be loaded is determined based on the parsing results. If it is the first-level bootloader FSBL, then skip this program and continue parsing the next entry in the header information.

[0047] If it is an FPGA bitstream, load the FPGA bitstream into the FPGA logic section and configure the PL terminal.

[0048] If it is the second-level bootloader UBOOT, copy UBOOT to the specified location in DDR, start UBOOT, and let UBOOT further boot Linux.

[0049] If it is a bare-metal application (APP), copy the APP to the specified location in DDR and launch the APP directly.

[0050] (3) Loop / End: After loading is complete, the system enters normal working state.

[0051] Step Six: As Figure 6 As shown, configure Linux environment variables. The Linux environment variables of the U-Boot secondary bootloader are modified to increase the offset address for loading the Linux kernel by the size of the upgrade bootloader's storage area. This compensates for the physical address offset caused by the upgrade bootloader's storage area. This step is mandatory if upgrading a Linux system; otherwise, booting will fail. Because the first 2MB of Flash memory is occupied by the Golden program, the physical address of the Linux kernel in Flash is actually offset by 2MB. Therefore, the offset address for loading the Linux kernel must be modified in the U-Boot Linux environment variables. For example, if the original offset is 0xB2000, it needs to be changed to 2M + 0xB2000. This allows U-Boot to read the Linux kernel from the correct Flash address and boot successfully.

[0052] Application examples: This example provides a complete Golden program upgrade solution, with the following steps: 1. Create the Golden program 1.1. Based on the hardware schematic, build a hardware platform using the VIVADO tool, i.e., a minimal hardware system, for the Golden program to call FLASH to read and write the upgraded program, and for the network port to be used by the user to transmit the upgraded program, such as... Figure 7 The figure shows the minimum hardware system.

[0053] 1.2 After configuring the minimum hardware system, compile the code and export the compiled hardware platform to the SDK using VIVADO. This will generate the network port and FLASH drivers for the Golden program to use. Figure 8 The image shows the SDK hardware driver interface.

[0054] 1.3. Generate the golden upgrade program golden.bin by packaging FSBL and tcp_client.elf, such as... Figure 9 The image shows the packaged Golden program.

[0055] 1.4. Burn the packaged golden.bin file into the FLASH memory, starting from address 0 to 2M. Subsequent updateimage (user program) loading from address 2M onwards will require starting from there. The two programs can be burned completely independently, avoiding excessively long single-burning times. After setting as shown in the image, click "program" to burn the golden.bin program into the FLASH memory. Figure 10 The image shows the Golden programming procedure.

[0056] 2. Upgrade via the Golden program 2.1 Computer Environment Configuration Set your local computer's IP address to 192.168.1.7, and then open the online upgrade program's host computer. For example... Figure 11 The image shows the configuration interface for upgrading the host computer.

[0057] 2.2 Click Figure 11 In the process, select the file and choose the user program that needs to be upgraded. After preparation, power on the device that has the Golden upgrade program burned on it. The host computer will automatically send the upgrade program to the device for program upgrade.

[0058] The Golden program upgrade scheme of this invention has significant application value in embedded system development and is one of the key technologies for achieving remote upgrades and improving system reliability. Through detailed operation steps and technical implementation details, developers can quickly master and apply it to practical projects, improving system maintainability and reliability.

[0059] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for online upgrade of multiple storage media and multiple systems based on ZYNQ embedded systems, characterized in that: Includes the following steps: S1. Storage Resource Planning: The non-volatile memory of the ZYNQ platform is divided into an upgrade bootloader storage area and a user program storage area; the upgrade bootloader storage area is used to store the upgrade bootloader, and the user program storage area is used to store the user program package to be upgraded; the upgrade bootloader includes FSBL and Golden program; S2. Upgrade bootloader startup: After the device is powered on, the FSBL loads the Golden program into the high address region of DDR memory and runs it; S3. Send upgrade request: The Golden program sends an upgrade request through the communication interface; S4. Wait for a reply and proceed with branching: If an upgrade reply is received, enter upgrade mode: Receive user program package data sent from outside, write it into the user program storage area, and perform data verification after writing is completed; If no upgrade reply is received or the data verification passes within a preset time, enter system boot mode: Read the header information of the user program storage area, parse the header information to identify the type of user program package, and load the corresponding program into the specified location of DDR memory for execution according to the identification result; In step S4, loading the corresponding program into a specified location in DDR memory for execution based on the identification result includes: If it is identified as an FPGA bitstream, then the FPGA bitstream is loaded into the FPGA logic section for configuration; If the system is identified as the second-level bootloader UBOOT, then the second-level bootloader UBOOT is copied to DDR memory, started, and booted by the second-level bootloader UBOOT to start the Linux operating system. If it is identified as a bare-metal application (APP), then the bare-metal application is copied to DDR memory and launched directly; If it is identified as the first-level bootloader FSBL, then skip the program and continue parsing the next entry in the header information; The non-volatile memory is a Flash memory with a capacity of 16MB or greater; the upgrade boot program storage area is located in the storage space from 0 to 2MB-1 of the Flash memory; the user program storage area is located in the storage space from 2MB to the end of the Flash memory.

2. The online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded systems according to claim 1, characterized in that: The user program package includes header information, which is automatically generated by the packaging software when packaging the user program package, and the header information is located at the beginning of the user program storage area.

3. The online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded systems according to claim 1, characterized in that: The Linux environment variable configuration for the second-level bootloader UBOOT is as follows: the offset address of the loaded Linux kernel is increased by the size of the upgrade bootloader storage area to compensate for the physical address offset caused by the occupation of the upgrade bootloader storage area.

4. The online upgrade method for multiple storage media and multiple systems based on ZYNQ embedded systems according to claim 1, characterized in that: In step S2, the high address region of the DDR memory is at address 0x10000000; The Golden program runs in the high address region to avoid the Golden program code being overwritten during the FPGA bitstream configuration process, which occupies the low address space of DDR memory.

Images