Following the successful testing of our software application using the Zynq All Programmable SoC’s launch-on-hardware option—(see “Running your programs on the MicroZed – Adam Taylor’s MicroZed Chronicles, Part 4”)—we now want to ensure that our software application can be stored in non-volatile memory so it will run after a power on or reset. We’ll need a boot loader to do this. The boot loader loads both the FPGA configuration and the software running on the Zynq SoC’s dual-core ARM Cortex-A9 MPCore processor. So to start, it’s important to understand the way the Zynq SoC boots and configures itself.
The Zynq SoC requires configuration information for both the ARM-based processor system (PS) and the programmable logic (PL). To simplify the process of configuring both the PS and PL, the configuration sequence is slightly different than the sequence used for a Xilinx FPGA. This difference results from the use of two file types:
The FPGA Bit File – Defines the behavior of the PL
The software ELF file – The software program to be executed by the PS
Within a Zynq SoC, the PS is the master and therefore configures the PL. The only exception to this is when the JTAG interface is being used to configure the PL. The advantage of this fixed sequence (PS configures PL) is that it allows the PS to power up and operate while the PL remains unpowered. You can use this feature to reduce system power consumption. Of course, if you want to use the Zynq PL, you will need to power it up at some point during the operation of your product.
The software code and the FPGA configuration bit file can be stored within the same configuration-memory device attached to the PS. The PS supports configuration using a number of different off-chip, non-volatile memories (Quad SPI Flash, NAND Flash, NOR Flash or SD Card). The MicroZed board design allows for SD Card and Quad SPI configuration memories.
The Zynq SoC on the MicroZed board follows a typical processor boot sequence to configure both sides of the device, initially running from an on-chip, non-modifiable BootROM. The Zynq SoC’s on-chip BootROM contains drivers for the supported non-volatile memories, which is rather convenient.
The Zynq SoC’s BootROM is configured by a header contained within off-chip, non-volatile memory. This header defines a number of boot options and it’s the first thing the BootROM code looks for. The header defines boot options such as execute in place (not possible from all memories), FSBL offset, and secure or not-secure configuration. The header ensures the BootROM operates compatibly with the way that the configuration memory has been formatted.
You have the option of using either secure (encrypted) or not-secure configuration files. Both are supported and defined by the boot ROM header. If you choose the secure configuration, the PL must be powered to activate the on-chip AES and SHA decryption hardware. These hardware security blocks are located within the Zynq SoC’s PL but they are implemented as hard macros, not constructed from programmable logic.
The next configuration stage is called the First-Stage Boot Loader (FSBL) and it is created by the system design team. The FSBL can configure the DDR SDRAM memory controller and other on-chip peripherals as defined in the Xilinx Platform Studio (XPS) hardware definition. These devices should be configured before loading the software application and configuring the PL.
Overall the FSBL is responsible for
Initializing the PS with the information provided by XPS
Programming the Zynq SoC’s PL if the appropriate bit file is provided
Loading either a Second-Stage Boot Loader (SSBL) if an operating system is being used or loading a bare-metal application into DDR SDRAM
Starting the execution of the SSBL or the bare-metal application
The Zynq SoC’s PL is programmed via the Processor Configuration Access Port (PCAP), which allows both partial and full PL configuration. (If you’d like more detailed information about the Zynq SoC’s PCAP, see “Partial Reconfiguration of a Hardware Accelerator on Zynq-7000 All Programmable SoC Devices”) The PL can be configured at any time once the PS is up and running. The PS can also read back the PL configuration and check for errors, which can be very handy if you are using the Zynq SoC in an environment where it may be subject to single-event functional interrupts (SEFI).
To create a bootable image for your Zynq solution you will need at least the following:
Boot ROM Header – Controls Boot ROM settings such as execute in place, encryption, Quad SPI configuration, FSBL offset, and image length
First stage boot loader
PL configuration bit file
Software application to run on the PS
Like Xilinx FPGA’s, the Xilinx Zynq All Programmable SoC uses a number of mode pins to determine which type of memory the configuration and software files are stored in, along with other crucial system settings. On the Zynq SoC, these mode pins share the multiuse I/O pins on the PS side of the device. In all, there are seven mode pins mapped to MIO[8:2]. The first four pins define the boot mode; the fifth pin determines whether the PLL is used or not; and the sixth and seventh pins define the bank voltages on MIO bank 0 and bank 1 during power up. The voltage standard defined on MIO bank 0 and 1 can later be changed by the first stage boot loader if needed.
In the next blog we will look at how we create and implement a bootable Zynq image within SDK.
Note: Please see the previous entries in this MicroZed series by Adam Taylor: