DOWNLOAD COURSE PRESENTATIONS

Scan to download course presentations

ZYNQ BOOT PROCESS AND DEBUGGING
AGENDA

> Configuration and Boot

> Debug
> Tool Demo (time permitting)
> Q/A
ZYNQ-7000 SOC CONFIGURATION AND BOOT
 CPU configures the PS and PL

 Two boot modes

– Secure boot
– Non-secure boot Static Memory Controller Dynamic Memory Controller
Quad-SPI, NAND, NOR DDR3, DDR2, LPDDR2
– Mode determined by Boot Header
AMBA® Switches AMBA® Switches

 Four master boot methods ARM® CoreSight™ Multi-core & Trace Debug

(secure or non-secure boot) NEON™/ FPU Engine NEON™/ FPU Engine

– QSPI (16MB, 50MB/Sec) Cortex™-A9 MPCore™

32/32 KB I/D MI
MI
Caches
OO
Cortex™-A9 MPCore™
32/32 KB I/D Caches

– NOR (64MB, 20MB/Sec)

512 KB L2
Snoop Control Unit (SCU)
Cache

Timer Counters 256 KB On-Chip Memory

– NAND (tested up to 1GB, 10MB/Sec) General Interrupt
DMA Configuration
Controller

– SD (Up to 32GB)
® ®
AMBA
AMBA Switches
Switches
 One slave boot method (non-secure)
– JTAG for debug and development
NON-SECURE BOOT
STAGE 0
 CPU starts executing code from internal Processing System
boot ROM ROM CPU
1) Initializes the Cortex-A9 CPU 0
2) Checks CRC on ROM code On-Chip
RAM
3) Reads the boot mode pins to determine the stage (256KB)

1 boot mode NAND

Central DDR
AXI Memory
• Can boot from QSPI, NAND, NOR, SD card, NOR
Switch Controller
or JTAG
QSPI
• Stage 1 boot from SD requires SD to be
SD
connected to pre-defined MIO pins
IOP AXI
4) Typically, first stage boot loader is read from
external non-volatile memory and copied into the Device Configuration
Unit
OCM (192KB max)
PCAP
• If the Execute In Place (XIP) feature is
enabled, first stage boot can be executed
directly from QSPI or NOR Device
AES-256 HMAC
• Stage 1 boot header specifies the use of XIP Key

feature
Programmable Logic
1) Arrow shows the direction of the master
NON-SECURE BOOT
STAGE 1 (FIRST STAGE BOOT LOADER)
 CPU starts executing FSBL from OCM Processing System
1) Code execution can also be ROM CPU
performed directly from QSPI or NOR
if the Execute In Place (XIP) feature On-Chip
RAM
is used (256KB)

• 192KB code size limit is removed NAND

Central
AXI
DDR
Memory
Switch Controller
2) DDR controller, clock generation NOR

module, and selected peripherals are QSPI

initialized SD
IOP
3) PS application and/or second stage AXI

boot is loaded into the DDR memory Device Configuration

Unit
4) Optionally, bitstream is loaded from PCAP
non-volatile memory and PL is
configured
Device
5) Second stage boot is optionally Key
AES-256 HMAC

enabled
Programmable Logic
SECURE BOOT
STAGE 0
• CPU starts executing code from internal Processing System
boot ROM ROM CPU

1) Initializes the Cortex-A9 CPU 0 On-Chip

2) Checks CRC on ROM code RAM
(256KB)

3) Reads the boot mode pins NAND

Central
AXI
DDR
Memory
Switch Controller
4) First stage boot loader is read from NOR

external non-volatile memory, FSBL is QSPI

RSA authenticated, decrypted using SD

AES, bit file and other software IOP AXI

authenticated via the HMAC block, Device Configuration

Unit
and copied into the OCM PCAP

 Can boot from QSPI, NAND, NOR, or

SD Device
AES-256 HMAC
Key
 The PL power must be on to use the
AES/HMAC for secure boot Programmable Logic
1) PCAP – Processor Configuration Access Port
2) Device Configuration Unit – 32-bit AXI, 32-bit PCAP
3) AES – Advanced Encryption Standard
4) HMAC - Hash-based Message Authentication Code
SECURE BOOT
STAGE 1
 CPU starts executing code from OCM Processing System
1) DDR controller, clock generation ROM CPU
module, and selected peripherals are
initialized On-Chip
RAM
(256KB)
2) PS application and/or second stage
Central DDR
boot is decrypted, authenticated via NAND AXI Memory
HMAC (SHA-256), and put into the NOR
Switch Controller

DDR memory QSPI

3) Optionally, bitstream is loaded from the SD

non-volatile memory, decrypted, IOP AXI

authenticated, and PL is configured Device Configuration

Unit
4) Second stage boot is optionally enabled
PCAP

Device
AES-256 HMAC
Key

Programmable Logic
1) Decryption key is stored in eFUSE or BRAM
2) Separate 256-bit key for the AES and HMAC
3) Keys are programmed using iMPACT via JTAG port
4) SHA – Secure Hash Algorithm
STAGE 2 BOOT

 Stage 2 boot loader such as U-Boot Processing System

runs from the DDR memory ROM CPU

1) Responsible for loading OS kernel On-Chip

2) OS image can be sourced from any of RAM
(256KB)
the following peripherals Central DDR
NAND
• NAND
AXI Memory
Switch Controller
NOR
• NOR QSPI

• QSPI USB

• USB GigE AXI

SD Device Configuration
• GigE IOP Unit

• SD PCAP

3) U-boot from Xilinx does not support

encryption at this point Device
AES-256 HMAC
Key
4) PL can optionally be configured in
stage 2 Programmable Logic
JTAG NON-SECURE BOOT (DEBUG/DEVELOPMENT)

• CPU starts executing code from boot ROM Processing System

1) Initializes the Cortex-A9 CPU 0 ROM CPU DAP

2) Checks CRC on ROM code On-Chip

RAM
3) Reads the boot mode pins (256KB)

4) Disables all security features NAND

Central DDR
AXI Memory
5) Enables DAP controller and the JTAG NOR
Switch Controller

chain QSPI

6) Boot ROM shuts down, releases CPU SD

control to JTAG IOP AXI

7) JTAG port is used to load the PS Device Configuration

Unit
image into the OCM PCAP
8) CPU starts executing code from OCM
9) Optionally, JTAG or CPU is used to Device
AES-256 HMAC JTAG
Key
configure the PL
Programmable Logic
PROCESSING SYSTEM CONFIGURATION TIME

 Factors determining the PS configuration time

– Power supply ramp time
– Selected configuration mode
– External non-volatile memory used
– PS boot image size
– PL image size

10ms to 50ms 50us to 500us PS Image Size (KB) PL Image Size (KB)
PLL Lock ms ms
Power Ramp Boot Device Speed (MB/s) Boot Device Speed (MB/s)

PS Image Load PL Image Load

 The following assumptions are made to simplify boot time analysis

– Secure boot code execution is ignored
– Boot duration starts when the user flips the power switch to when the
CPU branches to the user code
PROCESSING SYSTEM CONFIGURATION TIME EXAMPLE

 Given the high internal configuration bandwidth (100MB/s for secure and
400MB/s for non-secure)
– Image load time is typically limited by the non-volatile memory bus
bandwidth (100MHz QSPI Flash device throughput of up to 50MB/s)
– An example of a PS boot time is given below using a 100MHz QSPI
device

PS Configuration Time Example

Parameter Time (ms)
Power Ramp 50
PLL Lock 0.05
PS Image Load (5MB) 100
Flash Device: S25FL128S
PL Image Load (5MB) 100 Core Voltage: 2.7V to 3.6V
Total Boot Time 250.05 I/O Voltage: 1.65V to 3.6V

In a PCIe system, in order to meet the 100ms configuration time

requirement, the PS and PL image sizes for the first stage boot must be
kept as small as possible
AGENDA

> Configuration and Boot

> Debug
> Walkthroughs (time permitting)
> Q/A
 TOOLS: SOFTWARE DEVELOPMENT TOOLS
Xilinx Supplied
ARM Supplied Xilinx ARM® 3rd Party
3rd Party Supplied Basic Features Fully Featured Cortex™A9 Vendors

Software Standalone and Drives Operating Systems

Linux Drivers Connected Middleware
Platform Example Boot Code Community Codecs, etc.

Software Platform Studio SDK ARM®

(Eclipse IDE) Development Studio IDE IDEs, OS-specific
Development ARM GNU CC (DS-5)

Platform Studio SDK DS-5 Debuggers

SDK Profiler Debugger / Profiler & Profilers
Debug USB Cable RVI Debug ICE
download, run-time control DSTREAM Trace & Trace

JTAG / ARM CoreSight™ Infrastructure

Page 15
 3RD PARTY DEBUG TOOLS - ARM

• ARM DS-5 / Streamline / DSTREAM

> Supports JTAG, Ethernet, USB debug in bare metal, kernel aware, and
OS application configurations
> Profiling support
> Trace Support
 4KB on-chip ETB
 4GB off-chip DSTREAM
> SMP, AMP Debug
> ARM Compiler
> Sampling of PMU counters

Page 16
 3RD PARTY DEBUG TOOLS - LAUTERBACH

• Lauterbach Debug Support

> JTAG Debugger or external TRACE module
> Supports Cortex-A9 multi-core debug
> Trace Support
 4KB on-chip ETB
 4GB off-chip
> SMP, AMP Debug
> RTOS awareness
 Several OSes supported (noted exception – GHS)
> Interface to all compilers
> High Speed Download
> Flash Programming
> Real-time access to system memory and peripheral registers through
Debug Access Port without halting the core

Page 17
 CONNECTING HW AND SW
DDR Memory ARM Cortex-A9 PL Peripheral 1
MPCore
PL Peripheral 2
Hardware Designer Perspective PL Peripheral 3
 Peripheral blocks can be standard core Fixed I/O
offerings or custom logic cores Peripherals
Programmable
 Logic controls exposed to Processor 256KB OCM
Logic
System via register interface

Software Developer Perspective 0x00000000

DDR Memory
 Processor System controls
0x40000000
Programmable Logic blocks via PL Peripheral 1
exposed register interface 0x60000000
PL Peripheral 2
0x80000000
 Standard address-mapped architecture PL Peripheral 3
similar to any other ASSP 0xE0000000
Fixed I/O
Peripherals
Processor Address 0xFC000000
Space 256KB OCM
HANDOFF FROM HARDWARE TO SOFTWARE FLOW
• What is needed to enable the software team to run application code
on the hardware?
> Source code to configure the PS DDR controller, selected
peripherals, clock generation module, and the MIO
> Hardware description for FSBL and BSP generation
• Generated by XPS during export to SDK

Component Description

ps7_init.c(.h)
Source files containing PS configuration setup
ps7_init.tcl

system.xml Hardware platform description for FSBL and BSP generation

Documentation of register level details, use as a reference

ps7_init.html
alternative to browsing through initialization source code
SDK APPLICATION DEVELOPMENT FLOW

XPS SDK
Import
Generate Hardware HW Spec Generate Software
Platform (XML), Board Support Package
PS7_INIT and
Bitstream
Create Software Libraries and
Application Project Drivers

Build

Run on HW Debug and Profile

No
Works?

Yes
 BOARD SUPPORT PACKAGE (BSP)

• Board Support Packages are collections of parameterized drivers for

a specific µP system
MSS
AXI Master AXI Interconnect Block

SPI
Ethernet UART Timer Intc
EEPROM

xscutimer.h
xemacps.h
XScuTimer_Start ( … );
XEmacPs_PhyWrite ( … ); XScuTimer_Stop ( … );
XEmacPs_GetOperatingSpeed ( … ); ... XIntc_mEnableIntr ( … );
... xuartps.h ...
XUartPs_Send( … );
xqspips.h
XUartPs_Recv( … );
XQspiPs_Transfer ( … ); ...
XQspiPs_LqspiRead ( … );
...
SDK WORKBENCH VIEWS
C/C++ PERSPECTIVE Active Perspective
indicated here
C/C++ project outline
displays the elements of a
project with file decorators
(icons) for easy
identification

C/C++ editor for integrated

software creation

Code outline displays

elements of the software
file under development
with file decorators (icons)
for easy identification

Problems, Console,
Properties views list output
information associated with
the software development
flow
BUILDING THE SOFTWARE APPLICATION

• The software toolchain consists of the following GNU tools

> Compiler
> Assembler
> Linker

• A software build executes produces an ELF file

> ELF = Executable Linker Format
> Debug configuration is created by default
• A software build happens when
> Saving a resource file
> Cleaning a project
> Selecting Project > Build All
DIRECTORY STRUCTURE
• SDK projects are placed in SDK Directory
> SDK_Export is default
> Can open SDK directly by pointing to this directory

• Each project will have multiple directories

for system files and configurations

• Each application configuration has project

properties set depending on needs. An ELF file is
generated for each.
> Release configuration
> Debug configuration
> Profile configuration

• Board Support Packages associated with

each software application

• Hardware Platform
DEBUG CAPABILITIES

• Gnu Debugger used as source and assembly-level debugger

> 3rd Party trace tools available

C Code

Instruction
Memory Location

Assembly
Instruction Equivalent
XILINX C PROJECT WIZARD

• Target applications
to a Linux Software
Platform

26
REMOTE SYSTEM EXPLORER (LINUX APPLICATION DBG)

• Secure remote network connection to target running Linux

o Transfer files between PC and target Zynq file system
o Explore target root file system
AGENDA 28

> Configuration and Boot

> Debug
> Tool Demo (time permitting)
> Q/A
AGENDA 29

> Configuration and Boot

> Debug
> Tool Demo (time permitting)
> Q/A
THANKS! 30

• Thanks for your time!