A qspi mirror recovery method of a zynq device

Abstract

The application relates to the technical field of electric digital data processing, in particular to a QSPI image recovery method of a Zynq device, which comprises the following steps: for the device with the chip starting mode fixed as QSPI, when a QSPI Flash image is damaged or empty, a maintenance host is connected through JTAG and a serial port, the host scans a JTAG link through XSCT / XSDB, a debugging target is switched to a processor core and a core reset is executed, then a maintenance FSBL is downloaded and run, after basic initialization, a QSPI mode is identified, and a resident waiting state is entered, and an original image is not loaded; then U-Boot and a DTB are injected into DDR and run, a serial port CLI is entered, a to-be-recovered image is loaded into DDR, a QSPI Flash is erased and written through an sf command of U-Boot, read confirmation is performed after writing, and the device is reset and started from the recovered image; the application can complete QSPI image recovery of the Zynq device under the condition that the Zynq device chip starting mode is fixed as QSPI and the starting dial code is not switched on site.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to a QSPI image recovery method for Zynq devices. Background Technology

[0002] The Zynq series of programmable system-on-chips integrates an ARM processor system and programmable logic, and is widely used in embedded systems. Its boot mode is typically set via hardware DIP switches or pin configuration. Pins are used to configure the chip's power-on operating mode, allowing selection of booting from media such as QSPI Flash, NAND Flash, or SD card, or entering JTAG debug mode. Among these, QSPI Flash, due to its non-volatility, simple interface, and high read speed, has become the preferred boot mode in many product designs. In actual products, the chip boot mode is often fixed to QSPI during the product design phase. However, during field maintenance, situations may arise where the boot image in the QSPI Flash is empty, corrupted, has an incorrect version, or requires updating and reprogramming. In such cases, because the chip boot mode is fixed to QSPI and changing the boot DIP switches is not permitted or convenient in the field, the device cannot enter the U-Boot or Linux operating system through the normal boot chain, causing difficulties for maintenance.

[0003] In existing technologies, AMD's official documentation, "Zynq 7000 Embedded Design Tutorial (UG1165)," discloses the process of writing U-Boot and the boot image to QSPI Flash using JTAG. Typical operations include downloading U-Boot and downloading BOOT.BIN data to QSPI FLASH. Furthermore, the AMD Vitis software development platform discloses a debugging process for loading U-Boot via JTAG. The official documentation for the AMD Vitis software development platform, "Embedded Software Development (UG1400)," discloses a process for loading components such as FSBL, DTB, and U-Boot via JTAG and running U-Boot on the target board. The official U-Boot documentation, "The U-Boot Documentation," discloses the `sf` command, along with SPI Flash operation commands such as `sf probe`, `sf read`, `sf write`, `sf erase`, `sf update`, and `sf test`. This command set can be used to access SPI / QSPI Flash after U-Boot is running. AMD's official documentation for the PetaLinux software development kit, in its "Reference Guide (UG1144)," discloses changes to the PetaLinux U-Boot image artifacts, indicating that `u-boot.elf` needs to be distinguished from artifacts containing the device tree. This prior art demonstrates that downloading only the bare U-Boot ELF may not be sufficient to form a complete runtime environment during maintenance; DTB requirements must also be met. Additionally, in engineering practice, developers can also use Vitis / Vivado Flash programming tools, JTAG downloads, and U-Boot commands to process Flash images. However, the aforementioned prior art has the following shortcomings: First, while AMD and U-Boot have publicly disclosed their basic capabilities for loading U-Boot via JTAG and writing to QSPI, these publicly available procedures do not treat "fixing the chip boot mode to QSPI and not switching DIP switches on-site" as a core constraint. Second, in the general JTAG boot mode, burning the image to QSPI FLASH or developing debugging functions often assumes that maintenance personnel can load components according to the tool's recommended process. If JTAG mode is required, the boot mode selection DIP switch must be manually configured to JTAG mode before firmware burning can proceed. Third, the goal of a regular FSBL is usually to continue loading the boot image or enter fallback processing; when the QSPI image is abnormal, the regular boot chain may reset, freeze, or enter an unexpected path, failing to reliably provide a maintenance window where DDR is available and JTAG can take over. Fourth, U-Boot's QSPI write-back capability requires U-Boot to be running; when the official image in QSPI is corrupted, the device may not automatically reach the U-Boot CLI. Fifth, the organization of U-Boot and DTB in PetaLinux versions must match; if only U-Boot is downloaded during maintenance without meeting the DTB requirements, U-Boot may download successfully but fail to enter the serial communication environment. Sixth, the official Flash programming tool, if limited by the current boot mode or tool support boundaries, cannot be considered the sole primary path for fixed QSPI boot mode field maintenance.

[0004] The reasons for the above shortcomings are as follows: Zynq's BootROM first selects the boot mode based on the hardware boot mode. When the product design is fixed to QSPI, the field maintenance process must operate within this hardware constraint. Basic resources such as DDR, serial port, and QSPI controller are usually initialized by FSBL or the pre-boot process. If the pre-boot process does not enter a stable waiting state, the reliability of subsequent JTAG injection into U-Boot / DTB will decrease. The U-Boot sf command only provides QSPI access capabilities and is not responsible for constructing a pre-maintenance environment when the QSPI image is corrupted. The capabilities of existing general toolchains are scattered across multiple stages such as FSBL, JTAG, U-Boot, DTB, and QSPI drivers, lacking a complete takeover method for fixed QSPI boot devices, from hardware initialization to image recovery.

[0005] Therefore, how to restore the QSPI image of a Zynq device under the condition that the Zynq device chip boot mode is fixed in QSPI and the boot DIP switch is not switched on site is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The purpose of this invention is to provide a method for restoring a QSPI image of a Zynq device, which can restore the QSPI image of a Zynq device under the condition that the Zynq device chip boot mode is fixed in QSPI and the boot DIP switch is not switched on site.

[0007] To achieve the above objectives, the present invention provides a QSPI image recovery method for a Zynq device, comprising: For target Zynq devices whose chip boot mode is fixed to QSPI at the factory, if the target Zynq device cannot boot normally from the QSPI Flash due to a corrupted, empty, or abnormal boot image stored in the QSPI Flash, the following steps are performed: Step S1: Connect the JTAG interface and serial port interface of the target Zynq device to the maintenance host respectively. The maintenance host scans the JTAG link through the XSCT / XSDB debugging environment and switches the current debugging target to the processor core of the target Zynq device. Step S2: Perform a processor core-level reset on the currently selected processor core to return it to its initial execution state. The maintenance host downloads the maintenance FSBL to the target Zynq device and runs it through the XSCT / XSDB debugging environment. The maintenance FSBL performs basic initialization of PS, DDR, and PCAP to provide the basic conditions for subsequent DDR access and program injection. Step S3: Maintain the FSBL boot mode register. When the current boot mode is QSPI, perform basic initialization of the QSPI controller and output the maintenance log. Step S4: The maintenance FSBL enters a resident waiting state and does not continue to execute the normal QSPI image loading process. During the maintenance FSBL resident period, the maintenance host injects the U-Boot bootloader and device tree binary file DTB into DDR through the XSCT / XSDB debugging environment. Step S5: The maintenance host restores the CPU to run, enabling U-Boot to run from DDR and enter the command line interface (CLI). At this time, the target device still maintains the chip boot mode as QSPI. The maintenance host loads the QSPI image to be restored into DDR. Step S6: Execute the QSPI Flash probe command in the U-Boot command line interface CLI to identify the QSPI Flash, and execute erase, write or update commands according to the target Flash layout to write the QSPI image to be recovered in DDR to the specified offset address of the QSPI Flash; Step S7: After writing is complete, read the QSPI image to be restored from the QSPI Flash back to DDR using sf read, confirm the writing result, and then reset the target Zynq device. The target Zynq device will then boot from the restored QSPI image in a fixed QSPI boot mode.

[0008] In step S1, after connecting the JTAG interface and serial port interface of the target Zynq device to the maintenance host, the maintenance host can access the CPU of the target Zynq device through the XSCT / XSDB debugging environment and observe the serial port output.

[0009] In step S2, the maintenance FSBL is the first-stage startup loading program, which is a rescue maintenance version manually downloaded via JTAG. It is used to initialize the basic hardware and provide a maintenance residency point, and does not assume the responsibility of mass production self-starting.

[0010] In step S3, the maintenance log includes QSPI mode indication, QSPI initialization result, DDR availability status, and waiting U-Boot / DTB download status information.

[0011] In step S4, before the maintenance FSBL enters the resident waiting state, a cleanup operation can be performed first. The cleanup operation includes stopping the watchdog, clearing the FSBL running flag, and locking the SLCR.

[0012] In step S5, the source of the QSPI image includes XSCT / XSDB data download, TFTP, or SD card loading.

[0013] In step S7, the confirmation of the write result is achieved by host comparison, U-Boot available verification command, or engineering tools.

[0014] This invention provides a QSPI image recovery method for Zynq devices, based on the premise that the chip boot mode is fixed as QSPI and the boot DIP switch is not changed on-site, rather than using switching to JTAG boot mode as a recovery condition. This invention uses a maintenance FSBL instead of a standard mass-produced FSBL; this maintenance FSBL completes basic initialization and resides after recognizing the QSPI boot mode. The maintenance FSBL of this invention does not continue to attempt to load potentially corrupted normal images from QSPI, thereby avoiding the disruption of the maintenance takeover window by bad images, empty images, or fallback behavior. This invention uses DDR availability, JTAG takeover capability, and U-Boot / DTB injection capability as the construction targets for the maintenance entry point, ensuring the subsequent U-Boot QSPI write-back capability has the necessary prerequisites. This invention incorporates the PetaLinux U-Boot / DTB artifact relationship into the maintenance process, avoiding the two-stage maintenance environment anomalies caused by only downloading the U-Boot ELF without the DTB. This invention can complete the QSPI image recovery of Zynq devices under the condition that the Zynq device chip boot mode is fixed as QSPI and the boot DIP switch is not changed on-site. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0016] Figure 1 This is a flowchart of a QSPI image recovery method for a Zynq device according to the present invention. Detailed Implementation

[0017] The embodiments of the present invention are described in detail below. Examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, but should not be construed as limiting the present invention.

[0018] To better understand this invention, the meanings of the various English abbreviations of this invention are explained below: Zynq: Xilinx / AMD Zynq-7000 programmable system-on-a-chip, integrating an ARM processor system with programmable logic.

[0019] CLI: Command Line Interface, refers to the way to interact with a system or tool through terminal commands.

[0020] ELF: Executable and Linkable Format, commonly used for executable files of bare-metal programs or Linux applications.

[0021] TFTP: Trivial File Transfer Protocol, commonly used to transfer kernel, device tree, program, and other files to development boards over a network.

[0022] SD: Secure Digital, often used as a boot or storage medium for embedded development boards.

[0023] SoC: System on Chip, refers to a system that integrates functional modules such as processor, peripheral controller, bus, and memory interface within a single chip.

[0024] ARM: Advanced RISC Machine, ARM processor architecture, the Zynq-7000 PS uses the ARM Cortex-A9 processor core.

[0025] GIC: Generic Interrupt Controller, used to manage peripheral interrupts and inter-processor interrupts in ARM systems.

[0026] TTC: Triple Timer Counter, a three-channel timer / counter, is a timer peripheral provided by the Zynq PS side.

[0027] SLCR: System Level Control Registers, used to configure Zynq's system-level resources such as clock, reset, MIO, and PL control.

[0028] MMC: MultiMediaCard, a multimedia storage card interface, commonly used in Linux to represent storage devices such as eMMC and SD / MMC.

[0029] PL: Programmable Logic, referring to the FPGA logic section in Zynq.

[0030] PS: Processing System refers to the ARM processor system portion of Zynq.

[0031] DMA: Direct Memory Access, used by peripherals or PL logic to directly access DDR memory without the CPU transferring data byte by byte.

[0032] AXI: Advanced eXtensible Interface, is a high-performance on-chip bus interface in the ARM AMBA bus architecture.

[0033] CPU: Central Processing Unit, usually referring to the ARM Cortex-A9 processor core in Zynq-7000.

[0034] FPGA: Field Programmable Gate Array, refers to hardware logic resources that can be reconfigured by the user.

[0035] QSPI: Quad Serial Peripheral Interface, a four-wire serial peripheral interface commonly used to connect to boot Flash.

[0036] FSBL: First Stage Boot Loader, is one of the first software programs to run during the Zynq startup process.

[0037] JTAG: Joint Test Action Group, is an interface commonly used for chip debugging, program downloading, accessing processor cores, and scanning for debugging targets.

[0038] XSCT: Xilinx Software Command-line Tool, a Xilinx software command-line tool used for operations such as project building, program downloading, and JTAG debugging.

[0039] XSDB: Xilinx System Debugger, is the low-level debugging command environment in the Xilinx / AMD toolchain.

[0040] U-Boot: Universal Boot Loader, is a commonly used two-stage bootloader in embedded systems.

[0041] DTB: Device Tree Blob, a binary file used to describe hardware resource information to the Linux kernel.

[0042] DDR: Double Data Rate Synchronous Dynamic Random Access Memory, usually referring to the external running memory in a Zynq system.

[0043] PCAP: Processor Configuration Access Port, is the configuration access path from PS to PL in Zynq, which can be used to configure programmable logic by the processor system.

[0044] MIO: Multiplexed Input / Output, is a physical pin on the Zynq PS side that can be reused for different peripheral functions.

[0045] DAP: Debug Access Port, is an interface module in the ARM debugging architecture used to access processor and system debugging resources.

[0046] JTAG boot mode: This indicates the JTAG boot mode. When the DIP switch on the development board is set to JTAG boot mode and the power is on, the chip enters JTAG mode. In JTAG mode, the computer can download the code into the chip's RAM and run it directly and perform single-step debugging without going through the storage device. However, the code is lost after power is turned off.

[0047] Boot ELF: Represents the U-Boot executable file in ELF format. It is the core file generated by the U-Boot bootloader after compilation in embedded development, containing complete debugging information and file structure.

[0048] CPU0: Indicates the first core of a multi-core processor.

[0049] Please see Figure 1 This invention provides a method for restoring a QSPI image of a Zynq device, comprising: For target Zynq devices whose chip boot mode is fixed to QSPI at the factory, if the target Zynq device cannot boot normally from the QSPI Flash due to a corrupted, empty, or abnormal boot image stored in the QSPI Flash, the following steps are performed: Step S1: Connect the JTAG interface and serial port interface of the target Zynq device to the maintenance host respectively. The maintenance host scans the JTAG link through the XSCT / XSDB debugging environment and switches the current debugging target to the processor core of the target Zynq device. In this step, after connecting the JTAG interface and serial port interface of the target Zynq device to the maintenance host, the maintenance host can access the CPU of the target Zynq device through the XSCT / XSDB debugging environment and observe the serial port output.

[0050] In this embodiment of the invention, the target Zynq device is a Zynq device to be maintained, whose chip boot mode is fixed at QSPI, and includes a Zynq SoC, DDR, QSPI Flash, JTAG interface, and serial port interface. The maintenance environment of the maintenance host is: running XSCT / XSDB, serial terminal, and saving maintenance FSBL, U-Boot / DTB, and the image to be restored. Here, QSPI Flash represents the non-volatile boot medium to be restored or updated. Since the target Zynq device's factory chip boot mode is fixed at QSPI, when the target Zynq device cannot boot normally from the QSPI Flash due to a corrupted, empty, or abnormal normal boot image stored in the QSPI Flash, the target device's chip boot mode remains QSPI, the boot DIP switch is not switched, and JTAG and the serial port are connected, allowing the host to access the target CPU via XSCT / XSDB and observe the serial port output. When using JTAG on a Zynq, the host first scans for debuggable target devices on the current JTAG link, such as Zynq PS, ARMDAP, and dual-core Cortex-A9. The command `targets -set -filter {name =~ "ARM Cortex-A9 MPCore#0"}` switches the current debug target to Cortex-A9 core 0. This means that subsequent debug commands such as reset, download, run, pause, and read / write registers will, by default, operate on ARM Cortex-A9MPCore #0. This command itself does not start running on core 0; rather, it selects core 0 as the current target.

[0051] Step S2: Perform a processor core-level reset on the currently selected processor core to return it to its initial execution state. The maintenance host downloads the maintenance FSBL to the target Zynq device and runs it through the XSCT / XSDB debugging environment. The maintenance FSBL performs basic initialization of PS, DDR, and PCAP to provide the basic conditions for subsequent DDR access and program injection. In this step, the maintenance FSBL is the first-stage startup loader, which is a rescue maintenance version manually downloaded via JTAG. It is used to initialize the basic hardware and provide a maintenance residency point, and does not assume the responsibility of mass production self-starting.

[0052] In this embodiment of the invention, a processor reset is performed on the currently selected processor core. Since ARM Cortex-A9 MPCore #0 has already been selected, the reset here is for Cortex-A9 core 0. From a debugging perspective, its function is to return CPU0 to a relatively clean initial state, clear the current execution state, and allow it to start again from the state after the processor reset, facilitating subsequent ELF downloads, setting entry addresses, running programs, or continuing debugging. It is important to distinguish that `rst -processor` is typically a processor core-level reset, not a system reset of the entire Zynq chip, nor a PL logic reset. It primarily affects the currently selected ARM core and is not equivalent to a power-on, nor does it necessarily reinitialize peripheral resources such as DDR, MIO, clock, and PL. The maintenance host downloads the maintenance FSBL to the target Zynq device via XSCT / XSDB and runs it. This maintenance FSBL is a JTAG manual maintenance version, whose responsibility is to initialize basic hardware and provide a maintenance residency point. It is not the official FSBL in the mass production boot image and does not assume the responsibility of mass production self-booting. The FSBL maintenance process performs basic initializations of the PS, DDR, and PCAP, providing the necessary conditions for subsequent DDR access and program injection. Specifically, the PS initialization performed by the FSBL includes the following: First, CPU initialization is performed, enabling the ARM Cortex-A9 CPU core and setting the exception vector table, cache control (including L1 / L2 cache), and auxiliary control registers. Next, the GIC general interrupt controller is initialized to prepare the interrupt environment for subsequent Linux kernel or bare-metal programs. Simultaneously, the system timer and TTC are configured as clock sources for delays and task scheduling. Additionally, the system-level control register SLCR is configured to control the clock, reset, and multiplexing functions of the system PS. The FSBL maintenance process initializes the DDR controller according to pS9_init.c or the hardware configuration file, including configuring timing parameters (such as tRCD, tRP, tRAS, etc.), setting address mapping relationships, and performing verification and read / write tests to ensure DDR availability. After completing the above configurations, DDR can be used as runtime memory for the FSBL itself and the subsequently loaded Linux system. Maintaining the FSBL also involves PCAP / PL FPGA initialization: This involves accessing the programmable logic (PL) section via the PCAP interface to configure the FPGA (load the bitstream) and support DMA / AXI bus communication with the PL. It's important to note that FPGA initialization is only triggered when loading the bitstream is required; otherwise, the PCAP interface can be managed by the FPGA manager driver after Linux boots.

[0053] Step S3: Maintain the FSBL boot mode register. When the current boot mode is QSPI, perform basic initialization of the QSPI controller and output the maintenance log. In this step, the maintenance log includes QSPI mode indication, QSPI initialization result, DDR availability status, and waiting U-Boot / DTB download status information.

[0054] In this embodiment of the invention, the FSBL reads the boot mode register. When it detects that the current BootMode=QSPI, it first cancels the original conversion to MMC_MODE, and instead performs basic initialization of the QSPI controller and outputs maintenance logs, such as "Boot mode is QSPI", "QSPI Init Done", "DDR ready", "Entering maintenance mode", and "Waiting for XSCT / U-Boot download". Specifically, the boot mode of the Zynq device is determined by the hardware pin BOOT_MODE (corresponding to the PS pin BANK0[7:4]). This pin is used to select the system's power-on operation behavior, including booting from storage media such as QSPI Flash, NAND Flash, and SD card, or entering JTAG debug mode.

[0055] After the FSBL boots, it reads the BOOT_MODE register to obtain the boot mode value. For example, 0b0010 indicates booting from QSPI, which can be read by calling XilBootModeGet() or a similar function. Based on the read BootMode, the FSBL executes the corresponding loading process: if it's a non-volatile storage medium boot mode such as QSPI, NAND, or MMC, it initializes the corresponding peripherals and reads the boot image into DDR; if it's JTAG mode, it waits for external debugging tools to download it via JTAG. Through this mechanism, the FSBL can support multiple boot sources and switch flexibly.

[0056] Step S4: The maintenance FSBL enters a resident waiting state and does not continue to execute the normal QSPI image loading process. During the maintenance FSBL resident period, the maintenance host injects the U-Boot bootloader and device tree binary file DTB into DDR through the XSCT / XSDB debugging environment. In this step, before the maintenance FSBL enters the resident waiting state, a cleanup operation can be performed first. The cleanup operation includes stopping the watchdog, clearing the FSBL running flag, and locking the SLCR.

[0057] In this embodiment of the invention, the FSBL maintenance process does not proceed to the normal QSPI image loading process, nor does it call or enter the normal boot image loading path. Instead, it enters a resident waiting state after completing necessary cleanup. Necessary cleanup may include stopping the watchdog timer, clearing the FSBL running flag, locking the SLCR, etc., to reduce the risk of resets or state inconsistencies during subsequent JTAG takeover. During the FSBL maintenance residency period, the host injects U-Boot / DTB into DDR via XSCT / XSDB. For PetaLinux 2021.1 and similar products, it is preferable to download the U-Boot maintenance ELF containing the DTB; if a separate U-Boot ELF is used, the DTB should be placed at the address expected by U-Boot or the device tree requirements should be met through an equivalent method. The U-Boot / DTB maintenance runtime environment is: running after being injected into DDR by JTAG, providing serial port interaction and QSPI Flash access capabilities.

[0058] Step S5: The maintenance host restores the CPU to run, enabling U-Boot to run from DDR and enter the command line interface (CLI). At this time, the target device still maintains the chip boot mode as QSPI. The maintenance host loads the QSPI image to be restored into DDR. In this step, the source of the QSPI image includes XSCT / XSDB data download, TFTP, or SD card loading.

[0059] In this embodiment of the invention, the host computer resumes CPU operation, enabling U-Boot to run from DDR and enter the serial CLI. At this time, the device still maintains Hardware BootMode=QSPI, but the maintenance process has obtained an interactive two-stage maintenance environment via JTAG injection. Maintenance personnel load the QSPI image to be restored into DDR. The image source can be XSCT / XSDB data download, TFTP, SD card, or other loading methods permitted by the project; this invention does not limit the image source.

[0060] Step S6: Execute the QSPI Flash probe command in the U-Boot command line interface CLI to identify the QSPI Flash, and execute erase, write or update commands according to the target Flash layout to write the QSPI image to be recovered in DDR to the specified offset address of the QSPI Flash; In this embodiment of the invention, maintenance personnel execute sf probe in U-Boot CLI to identify QSPI Flash, and execute sf erase, sf write, sf update or equivalent commands according to the target Flash layout to write the image in DDR to the specified offset of QSPI Flash.

[0061] Step S7: After writing is complete, read the QSPI image to be restored from the QSPI Flash back to DDR using sf read, confirm the writing result, and then reset the target Zynq device. The target Zynq device will then boot from the restored QSPI image in a fixed QSPI boot mode.

[0062] In this step, the confirmation of the write result is achieved by host comparison, U-Boot availability verification command, or engineering tools.

[0063] In this embodiment of the invention, after the write operation is completed, maintenance personnel can read the target area in the QSPI Flash back to DDR using `sf read`, and confirm the write result using host comparison, U-Boot availability verification commands, or other engineering tools. After confirmation, the device is reset, and the device continues to boot from the restored QSPI image in a fixed QSPI boot mode.

[0064] This invention provides a QSPI image recovery method for Zynq devices. This method allows maintenance personnel to download a maintenance FSBL via JTAG without altering the hardware boot DIP switches, relying on the original QSPI image for booting, or using the official Flash programming tool as the sole recovery path. The maintenance FSBL completes basic initializations for PS, DDR, PCAP, and QSPI, and enters a resident waiting state after recognizing BootMode=QSPI. After the maintenance FSBL is resident, the target board is in a state where DDR is available, JTAG is manageable, and subsequent programs can be injected. Maintenance personnel then inject U-Boot / DTB into the DDR via XSCT / XSDB, enabling U-Boot to enter the serial CLI. Finally, they utilize the U-Boot running QSPI driver and the sf command to recover the boot image or other target image from the QSPI Flash. The main objective of this invention is to construct a maintenance entry point that does not rely on the original QSPI image for normal booting, by pre-resident the maintenance FSBL within the product constraints of a fixed QSPI boot mode. This invention enables the download of a maintenance FSBL via JTAG, even when the Zynq device chip boot mode is fixed to QSPI and the boot DIP switch is not switched on-site. This maintenance FSBL, upon recognizing the QSPI boot mode, completes basic initialization and resides there, thus constructing a maintenance environment where DDR is available, JTAG is manageable, and U-Boot / DTB is injectable. U-Boot then performs QSPI image recovery. The advantages of this invention are: First, it does not require on-site changes to the hardware boot DIP switch, making it suitable for devices whose boot mode is fixed by product structure, casing, installation environment, customer maintenance specifications, or on-site conditions. Second, it does not rely on an existing image in QSPI for booting; even if QSPI is a blank chip, a bad image, or has an incorrect version, a management entry point can be constructed first through the JTAG maintenance FSBL. Third, it does not use the official Flash programming tool as the sole recovery path; instead, it first initializes the hardware with the maintenance FSBL, and then the running U-Boot driver accesses the QSPI Flash. Fourth, the FSBL in this invention has a clear function: it serves only as the entry point for manual JTAG maintenance and does not replace the official FSBL in the mass production boot chain, thus reducing the impact on the normal product boot process. Fifth, basic conditions such as DDR, QSPI, and serial port are initialized before entering the resident state, facilitating subsequent JTAG download of U-Boot / DTB and the image to be restored. Sixth, the matching relationship between U-Boot and DTB is clearly handled, which reduces the risk of maintenance failure where U-Boot downloads successfully but fails to enter the CLI.Seventh, the toolchain and runtime environment required for this invention are based on existing Zynq, XSCT / XSDB, PetaLinux, U-Boot and QSPI Flash capabilities, resulting in lower engineering implementation costs.

[0065] The above-disclosed embodiments are merely one or more preferred embodiments of this application and should not be construed as limiting the scope of this application. Those skilled in the art can understand that all or part of the processes for implementing the above embodiments and equivalent changes made in accordance with the claims of this application still fall within the scope of this application.

Claims

1. A method for restoring a QSPI image of a Zynq device, characterized in that, include: For target Zynq devices whose chip boot mode is fixed to QSPI at the factory, if the target Zynq device cannot boot normally from the QSPI Flash due to a corrupted, empty, or abnormal normal boot image stored in the QSPI Flash, the following steps are performed: Step S1: Connect the JTAG interface and serial port interface of the target Zynq device to the maintenance host respectively. The maintenance host scans the JTAG link through the XSCT / XSDB debugging environment and switches the current debugging target to the processor core of the target Zynq device. Step S2: Perform a processor core-level reset on the currently selected processor core to return it to its initial execution state. The maintenance host downloads the maintenance FSBL to the target Zynq device and runs it through the XSCT / XSDB debugging environment. The maintenance FSBL performs basic initialization of PS, DDR, and PCAP to provide the basic conditions for subsequent DDR access and program injection. Step S3: Maintain the FSBL read boot mode register. When the current boot mode is QSPI, perform basic initialization of the QSPI controller and output the maintenance log. Step S4: The maintenance FSBL enters a resident waiting state and does not continue to execute the normal QSPI image loading process. During the maintenance FSBL resident period, the maintenance host injects the U-Boot bootloader and device tree binary file DTB into DDR through the XSCT / XSDB debugging environment. Step S5: The maintenance host restores the CPU to run, enabling U-Boot to run from DDR and enter the command line interface (CLI). At this time, the target device still maintains the chip boot mode as QSPI. The maintenance host loads the QSPI image to be restored into DDR. Step S6: Execute the QSPI Flash probe command in the U-Boot command line interface CLI to identify the QSPI Flash, and execute erase, write or update commands according to the target Flash layout to write the QSPI image to be recovered in DDR to the specified offset address of the QSPI Flash; Step S7: After writing is complete, read the QSPI image to be restored from the QSPI Flash back to DDR using sf read, confirm the writing result, and then reset the target Zynq device. The target Zynq device will then boot from the restored QSPI image in a fixed QSPI boot mode.

2. The QSPI image recovery method for Zynq devices as described in claim 1, characterized in that, In step S1, After connecting the JTAG interface and serial port interface of the target Zynq device to the maintenance host, the maintenance host can access the CPU of the target Zynq device through the XSCT / XSDB debugging environment and observe the serial port output.

3. The QSPI image recovery method for Zynq devices as described in claim 1, characterized in that, In step S2, The maintenance FSBL is the first-stage startup loader, a rescue maintenance version manually downloaded via JTAG. It is used to initialize the basic hardware and provide a maintenance residency point, and does not assume the responsibility of mass production self-starting.

4. The QSPI image recovery method for Zynq devices as described in claim 1, characterized in that, In step S3, The maintenance log includes QSPI mode indication, QSPI initialization result, DDR availability status, and waiting U-Boot / DTB download status information.

5. The QSPI image recovery method for Zynq devices as described in claim 1, characterized in that, In step S4, Before the maintenance FSBL enters the resident waiting state, a cleanup operation can be performed first. The cleanup operation includes stopping the watchdog, clearing the FSBL running flag, and locking the SLCR.

6. The QSPI image recovery method for Zynq devices as described in claim 1, characterized in that, In step S5, The QSPI image can be obtained from XSCT / XSDB data download, TFTP, or SD card loading.

7. The QSPI image recovery method for Zynq devices as described in claim 1, characterized in that, In step S7, The confirmation of the write result is achieved by host comparison, using U-Boot's available verification commands, or engineering tools.

Images