Follow and star our official account for exciting content
Source: https://blog.csdn.net/weixin_39847099/article/details/111802365Organized by: ZYNQ | Xiao Mo
The JTAG Configuration Process of Zynq
When first learning Zynq, I believe everyone, like me, follows the usual practice of opening the Vivado software, setting up the programmable logic (PL) part of Zynq, exporting the hardware deployment, then opening the SDK for programming the ARM core (PS) software design, and finally downloading the hardware bitstream file (.bit) and the executable link file (.elf) to the Zynq development board for debugging and verification of the hardware-software design. This design approach can be well described by the diagram below:
The above diagram illustrates the most basic development process that one needs to understand when first engaging with Zynq hardware-software design, perfectly embodying the integration of PL and PS design. However, the above development process has a fundamental premise: the Zynq development board is directly connected to the computer via JTAG, allowing for program downloads. From another perspective, both PL and PS configurations can be considered as being completed by the host computer through JTAG. However, in practice, the Zynq development board cannot be connected to the computer in real-time. When JTAG is not operational, how does the Zynq chip achieve its configuration? This is the question that this article will discuss with everyone.
The Boot Process of Zynq
In non-JTAG mode, Zynq completes its configuration through the on-chip CPU, meaning that the PS and PL configurations are accomplished by the ARM core of the PS processor. It is important to note that, unlike traditional Xilinx 7 series FPGA chips, Zynq does not support direct boot configuration from the PL side; it must be completed through the PS part.
The specific boot configuration of Zynq is hierarchical and can be divided into three stages, represented as 0 to 2:
Stage 0: BootROM Stage
Stage 1: FSBL (First Stage Boot Loader) Stage
Stage 2: SSBL (Second Stage Boot Loader) Stage
Those familiar with ARM development should find the above boot process quite familiar, yet there may be some unfamiliar aspects. Don’t worry, below we will analyze these three stages in detail.
Zynq Boot Stage 0 – BootROM
Stage 0, also known as the BootROM stage. As everyone knows, ROM stands for Read-Only Memory; it means that Boot refers to booting. Therefore, BootROM literally means a read-only boot memory. In fact, the function of BootROM is exactly as its literal meaning suggests: it refers to the program that the ARM core needs to read from the BootROM immediately after power-up to complete the initial configuration of the chip. Because it is read-only, the program in BootROM cannot be modified due to the nature of ROM. Some may ask what configurations this part of the BootROM code mainly completes for Zynq?
Before detailing what configurations BootROM performs, we first need to describe the boot pin configuration of Zynq. Zynq has five configurable MIO pins, MIO[6:2], which appear as five jumper caps in hardware form that can be connected to GND or 3V3 for high-level signals. Their functions are as follows:
MIO[2]: Selects JTAG mode
MIO[5:3]: Selects the boot method, including SD card, QSPI Flash, etc.
MIO[6]: PLL enable control
From the description of the different pin functions, we can see that when JTAG is not operational, it is necessary to change the connections of MIO[5:3] to boot from different storage media such as the SD card.
The most important role of BootROM is to determine from which medium to load the boot image needed for stage 1 by reading the configuration of MIO[6:2]. Of course, before loading, BootROM will first initialize the SD card, NAND, NOR, QSPI Flash, etc., so that the ARM core can successfully access and use these peripherals. While completing the above tasks, BootROM also configures operational modes such as secure mode, which the author is not too familiar with, so I will not elaborate further.
After BootROM reads the boot image from external storage devices, it usually loads it into OCM. OCM, On-Chip Memory, is the on-chip memory of the ARM core in Zynq, also known as on-chip RAM. At this point, the boot task of the BootROM stage is considered complete, and control is handed over to stage 1.
Note: The BootROM stage does not configure the PL.
Zynq Boot Stage 1 – FSBL
FSBL, (First Stage Boot Loader), is the boot image loaded into OCM by BootROM. The tasks completed by FSBL are a key part of the Zynq boot process and can be divided into the following four items:
-
Initialize the PS
-
Load the PL bitstream file and complete the PL configuration
-
Load the SSBL boot program or the bare-metal program to DDR
-
Jump to execute SSBL or the bare-metal program
The tasks of FSBL are as listed above, and the overall idea is quite clear. The first step is to initialize the PS side, including DDR, MIO, etc. The second step is the configuration of the PL, which is the traditional process of downloading the bitstream to the FPGA, but it is important to note that in Zynq’s non-JTAG mode, the PL cannot configure itself directly. The third step is to load the SSBL or bare-metal program into DDR memory, where SSBL, the Second Stage Boot Loader, is loaded only when Zynq needs to run an operating system. The LED blinking experiment we do in the beginning is just a bare-metal program. Finally, in the fourth step, the ARM will jump to execute the loaded program in DDR. Thus, the operational thought of the FSBL stage is easy to understand.
Zynq Boot Stage 2 – SSBL
The SSBL is an optional stage in the Zynq boot process, just like the LED blinking experiment mentioned earlier, including some other smaller programs. If there is no need to use an operating system, then the Zynq boot process is sufficient up to the FSBL stage. Therefore, SSBL is aimed at applications that need to run an operating system. Those familiar with operating system boot knowledge should be clear that SSBL is the boot loader in the operating system’s startup process. For Linux, the role of Zynq’s SSBL stage is the same as that of u-boot. Specifically, the role of SSBL is to load the operating system required by Zynq into DDR memory.
Thus, the boot and configuration of Zynq are complete. The Zynq boot process is actually similar to traditional ARM development processes, with the difference being that it is a PS + PL architecture, so during the boot process, an additional binary bitstream file needs to be loaded. Xilinx divides the Zynq boot process into three stages, which is scientifically reasonable from a structural perspective.
Summary
This article mainly shares the boot configuration process of Zynq in non-JTAG mode, aiming to provide everyone with a concrete understanding of Zynq’s three-stage boot mode. I hope everyone can communicate more.
https://blog.csdn.net/weixin_39847099/article/details/111802365
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧Recommended Reading:ZYNQ | Development Board RecommendationsZYNQ | Learning PathZYNQ | Recommended ResourcesZYNQ | Development ToolsFollow the WeChat official account ‘ZYNQ’, reply ‘Join Group’ to join the FPGA/ZYNQ technical exchange group. Reply ‘m’ in the background for more exciting content.