top of page

Zynq-7000 Boot Process

Updated: May 15, 2023



This post lists the Zynq-7000 boot process as documented in the UltraFast Embedded Design Methodology Guide UG1046 (v2.3) April 20, 2018 at [link] on pages 156-161.


From Doc


The Zynq-7000 AP SoC boot process can be a multistage boot, depending on the system

requirements. This section describes three broadly divided stages of booting and their role

in the booting process.


Figure 4-6 shows the steps while booting embedded Linux and

application code on a Zynq-7000 AP SoC:


When power is applied to the SoC, the boot process starts from the BootROM. This process loads and then starts executing the first-stage boot loader (FSBL) from on-chip memory (OCM). The FSBL configures the specific initialization. Then, based on the software architecture, the second-stage boot loader (SSBL), such as U-Boot in the case of embedded Linux, is initialized and executed. The FSBL and/or SSBL start the RTOS or embedded Linux and the application code.


Stage 0


At power-on or reset, the ARM core runs initialization code from the BootROM. The

BootROM code cannot be changed; it is a factory pre-programmed code that comes with

each Zynq-7000 AP SoC. The BootROM code determines the device on which the next-level

loader is located by reading the boot-mode pins. Depending on the boot-mode setting, the

FSBL is copied from either NAND, parallel NOR, serial NOR (Quad-SPI), or Secure Digital

(SD) flash memories to the OCM.


Figure 4-7 shows the standard (non-secure) boot flow. The secure boot flow is described in

Embedded Device Security (see the doc for this, pages 46-50):

Stage 1


The FSBL gets execution control from the BootROM and either runs from the OCM or

execute-in-place flash based on the boot mode settings. The FSBL initializes the PS and

looks for a bit file in the boot device. If found, the FSBL writes the bit file to the PL. Whether

or not a bit file is found, the FSBL loads application binaries and data files into memory until

the complete image has been read from the boot device. Then the FSBL starts executing the

first application binary that was loaded.


Typically, the FSBL initializes the external RAM and loads the second-stage boot loader

(SSBL) or a stand-alone application. Based on the software architecture, if it is a full featured

OS like embedded Linux the SSBL (such as U-Boot in the case of embedded Linux) is

initialized and executed. The FSBL and/or SSBL start the RTOS or embedded Linux and the

application. Then, the FSBL hands over control by jumping to the start address of the SSBL,

in the case of a full-featured OS like embedded Linux, or to an RTOS or application.


Stage 1 can include the user application if it is small enough to fit in OCM memory.


The Zynq-7000 AP SoC supports both secure and non-secure boot methods. The boot-ROM

code flow for both methods is described below.


For secure boot, the principal security objective of the SoC is to lay a foundation of trust. It

does this using integrity, confidentiality, and authentication from the time power is applied

to the time control is asserted. The SoC also provides a method for maintaining this trust.

The SoC does this by using the PL's built-in Advanced Encryption Standard (AES-256) and

hashed message authentication code (HMAC) engines, and the RSA authentication

capability of the PS.


The SoC boots securely unless it is changed from a secure to a non-secure mode. The first

decision point is the initial load of the FSBL. If the FSBL is encrypted, the BootROM code

boots securely and hands control off to the FSBL securely, while disabling JTAG. If the FSBL

is not encrypted, the AES 256 and HMAC engines are disabled and the JTAG ports can be

accessed. To enable RSA authentication, the RSA Enable eFUSE must be programmed.


The Xilinx design tools allow specifying whether the software and bit-stream partitions are

authenticated using the public-key RSA algorithm and whether subsequent images are

encrypted and authenticated using the AES and HMAC engines. An unencrypted partition

can also be specified. This allows use of both public- and private-key algorithms on a

partition basis.


Alternatively, when configuration time is critical, a trade off can be made between security

and boot time, because configuration speed is faster for unencrypted partitions than for

encrypted partitions. A relatively large, open-source U-Boot or Linux image, for example,

loads faster if the image is unencrypted. If any of the secure features are selected, the initial

FSBL, at a minimum, must be encrypted with AES-256 and authenticated with the HMAC

algorithm.


Figure 4-8 shows the FSBL flow for secure boot mode.


Figure 4-9 shows the FSBL flow for non-secure boot mode.


For more information about secure boot of the Zynq-7000 AP SoC, refer to the following

documents:

  • Secure Boot in the Zynq-7000 All Programmable SoC (WP426) [Ref 35]

  • Secure Boot of Zynq-7000 All Programmable SoC (XAPP1175) [Ref 42]


Stage 2


This stage could be a second-stage boot loader (SSBL) like U-Boot, or it could be an RTOS

or application. In the case of a full-featured OS like embedded Linux, the SSBL U-Boot runs

in CPU0 to initialize and set up the environment in which the OS will boot. The initialization

includes configuring the MMU to use flat memory (that is, virtual and physical locations are

the same). The boot loader then fetches the kernel image (per the boot-mode setting) and

other information, such as boot arguments, into RAM. Then the loader passes control to the

OS, such as embedded Linux.


In the case of Linux, the OS detects and enables the second processor core, configures and

activates the MMU and data caches, and performs other actions to make a complete system

available to applications.


There is no limit to what each stage can actually do, although some things can be done

more easily in one stage than in others. For example, reading a file from an NTFS USB drive

is possible from Linux, but it requires some development effort to do it from the boot

loader. U-Boot can be adapted to such requirements.


Zynq-7000 All Programmable SoC Software Developers Guide (UG821) [Ref 7] covers the

architecture details, programming model, OS considerations, and complete development

steps for running Linux and applications on Zynq-7000 AP SoC.



Reference


Xilinx logo found via https://twitter.com/xilinxinc at [link]

© 2025 by Centennial Software Solutions LLC.

bottom of page