Xilinx Zynqmp Guide
Uploaded by
Mohammed PublicationsXilinx Zynqmp Guide
Uploaded by
Mohammed PublicationsBuilding Xilinx ZynqMP System
ELECTGON
www.electgon.com
25.04.2024
Contents
1 ZynqMP Description 1
1.1 APU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 RPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Programmable Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1.1 AXI Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1.2 Interrupts Interfaces . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1.3 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1.4 EMIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1.5 Dedicated Streams . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1.6 PMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1.7 DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Memory Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1.1 On-Chip Memory (OCM) . . . . . . . . . . . . . . . . . . . 5
1.4.1.2 Tightly-Coupled-Memory (TCM) . . . . . . . . . . . . . . . 6
1.4.1.3 PL Memories . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 PS Memory Controllers . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2.1 General Purpose DMA Controllers . . . . . . . . . . . . . . 7
1.4.2.2 Peripheral DMA . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.3 External Memory Interfaces . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Interconnects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.8 Booting Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.8.1 Non-Secure Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8.2 Secure Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8.3 Bootings Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.9 Isolation and Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.9.1 Trustzone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.9.2 Exception Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.10 Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2
Contents Contents
1.10.1 Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Hardware 12
2.1 Processor Con guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 HDF and Bitstream Generation . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Firmware 15
3.1 Preparations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Cross Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 First Stage Boot Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4 Procedure Using HSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.5 Procedure Using XSCT . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.6 Procedure Using SDK . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 PMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1 PMU ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1.1 Functions at Power On . . . . . . . . . . . . . . . . . . . . 20
3.3.2 PMU RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3 Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.4 Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.5 Procedure Using XSCT . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.6 Procedure Using SDK . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 ATF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.1 Procedure in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.2 Procedure in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.3 Procedure Using SDK (GUI) . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Device Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.1 Device Tree Important Parameters . . . . . . . . . . . . . . . . . . . 27
3.5.1.1 Label and Name . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1.2 Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1.3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1.4 Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1.5 Custom Arbitrary Parameters . . . . . . . . . . . . . . . . 29
3.5.1.6 Overwriting . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.2 DTS Organization in Xilinx . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.3 Other User DTS Con guration . . . . . . . . . . . . . . . . . . . . . 33
3.5.4 Using SDK to build DTS le . . . . . . . . . . . . . . . . . . . . . . 33
3.5.4.1 Procedure Using SDK GUI . . . . . . . . . . . . . . . . . . 33
3.5.4.2 Procedure Using XSCT Command Line . . . . . . . . . . . 36
3.5.5 Generating DTB Binary . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 UBoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3
Contents Contents
3.6.1 Quick Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2 U-Boot Con guration . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2.1 System Con guration . . . . . . . . . . . . . . . . . . . . . 38
3.6.2.2 Device Tree Con guration . . . . . . . . . . . . . . . . . . . 38
3.6.2.3 Board Con guration . . . . . . . . . . . . . . . . . . . . . . 38
3.6.3 Debugging U-boot Settings . . . . . . . . . . . . . . . . . . . . . . . 39
3.6.4 Adding Customized Con gurations . . . . . . . . . . . . . . . . . . . 40
3.6.5 Booting from Correct SD Partition . . . . . . . . . . . . . . . . . . . 40
3.6.6 Booting from TFTP Server . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.7 Booting From NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.8 Scripting Boot Procedure . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.8.1 Boot Script Sample . . . . . . . . . . . . . . . . . . . . . . 43
3.6.8.2 Boot Script Format . . . . . . . . . . . . . . . . . . . . . . 43
3.6.8.3 Boot Script Loading . . . . . . . . . . . . . . . . . . . . . . 44
3.7 FileSystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.7.1 De nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.7.2 Building File System . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.7.2.1 Build Using Busybox . . . . . . . . . . . . . . . . . . . . . 46
3.7.2.2 Build Using Buildroot . . . . . . . . . . . . . . . . . . . . . 46
3.7.3 Buildroot Quick Guides . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7.3.1 Add Overlays . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7.3.2 Modify Using Post Script . . . . . . . . . . . . . . . . . . . 48
3.7.3.3 Modify Using Patches . . . . . . . . . . . . . . . . . . . . . 49
3.7.3.4 Rebuild Packages . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7.3.5 Get Package from User Speci c Location . . . . . . . . . . 51
3.7.3.6 User Control During Build Process . . . . . . . . . . . . . . 51
3.7.3.7 Format of Zipped Output . . . . . . . . . . . . . . . . . . . 52
3.7.4 File System Location . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8 Linux Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.1 Kernel Image Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.2 Flattened Image Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.9 Boot Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9.1 Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9.2 Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9.4 Procedure Using Command Line . . . . . . . . . . . . . . . . . . . . 57
3.9.4.1 Create BIF le . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9.5 Procedure Using SDK . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.10 Boot Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.10.1 Boot Through TFTP Server . . . . . . . . . . . . . . . . . . . . . . . 61
3.10.2 Boot Through SD Card . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.10.2.1 SD Card Partitioning . . . . . . . . . . . . . . . . . . . . . 61
4
Contents Contents
3.10.3 Booting Through QSPI . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.10.3.1 QSPI Partitioning . . . . . . . . . . . . . . . . . . . . . . . 63
3.10.3.2 Writing on QSPI . . . . . . . . . . . . . . . . . . . . . . . . 64
3.10.4 Booting During Development Phases . . . . . . . . . . . . . . . . . . 66
3.10.4.1 Replacing Kernel, DTB, Filesystem Images . . . . . . . . . 66
3.10.4.2 Replacing Boot File . . . . . . . . . . . . . . . . . . . . . . 66
3.10.5 Loading Bitstream File . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4 Software 68
4.1 Linux Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.1 Build and Run Linux Kernel . . . . . . . . . . . . . . . . . . . . . . 68
4.1.2 Create Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.3 Build Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.4 Running Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2 Linux Drivers Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.1 Platform Hardware Link . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.2 Kernel Platform Link . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2.3 Major Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.4 User Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3 Driver Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.3.1 Integration with Kernel Image . . . . . . . . . . . . . . . . . . . . . 77
4.4 GPIO Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.4.1 Using sysfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.4.2 Using GPIOLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.4.2.1 Prepare Device Tree le . . . . . . . . . . . . . . . . . . . . 81
4.4.2.2 Recognize GPIO Pins in the Platform Driver . . . . . . . . 81
4.4.2.3 Writing to the GPIO . . . . . . . . . . . . . . . . . . . . . 82
4.4.3 Using Generic UIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.3.1 De ne Driver in Hardware Node . . . . . . . . . . . . . . . 82
4.4.3.2 Enable UIO Driver in Kernel Con guration . . . . . . . . . 82
4.4.3.3 Set Driver Identi cation in Kernel . . . . . . . . . . . . . . 83
4.4.3.4 Writing to UIO . . . . . . . . . . . . . . . . . . . . . . . . . 83
5
Abstract
This book is a practical guide for building an integrated system for Xilinx FPGA - Zynq
family. What is meant by integrated system is the complete ow starting from the hardware
logic up to a running application on an Operating System. Zynq device from Xilinx is an
FPGA that consists of a Programmable Logic part (PL) and a built-in Processing System
(PS). This means that this FPGA can be used to build a customized hardware that can be
attached to the Processing System as a peripheral. Controlling the customized hardware
is done then through an Operating System which is usually a Linux build that can be
obtained from a Xilinx repository. Therefore this book is showing important steps needed
to build both the hardware and Operating System stu.
Chapter 1
ZynqMP Description
Understanding the target hardware platform shall be rst step to be achieved in order to
build needed binaries and bitstream easily as well as to know capabilities of this platform
for best use. This book is discussing build procedures based on Xilinx ZynqMP Ultras-
cale+. Xilinx has already very bene cial documentations and support platform that makes
explaining the ZynqMP here is not an added-value. A summarized overview of this plat-
form can be su cient as a starting point but for real explanations it is advised always to
refer to available Xilinx User Guides and tutorials.
ZynqMP is partitioned basically into Processing System (PS) and Programmable Logic
(PL). PS is a hard-wired ARM processors that are implemented into the chip, PL is the
con gurable hardware part of the FPGA. The chip can be classi ed also in terms of power
domain consumed by its components. So it can be classi ed into
Full Power Domain (FPD).
Low Power Domain (LPD).
PL Power Domain (PPD).
Battery Power Domain (BPD).
with a component called Platform Management Unit (PMU), power management and
isolation between these domains are controlled. Figure 1.1 shows other main components
of ZynqMP.
1
Chapter 1. ZynqMP Description
Figure 1.1: Power Domains in ZynqMP
Or it can be summed up according to the power domains as in table 1.1
FPD LPD PPD BPD
Processing - APU - RPU -
- GPU - PMU
- CSU
Peripheral/Accelerator - PCI / SATA - OCM - PL -
/Display Port - MIO Peripherals - PL Peripherals
Table 1.1: Main Components in Power Domains
Table 1.1 includes also an indication if the component is a processing system or a
peripheral that serves a special function. This means that some components have running
processors inside. The fact is each processing system can run independently. That is called
they are Asymmetric processing systems. For example APU has four cores, they can run
with dierent Operating Systems and they don't share workload. RPU has 2 cores they
2
Chapter 1. ZynqMP Description 1.1. APU
can run independently. So the user has the option to choose which processor to work with
(APU, RPU, etc) and how to employ cores of the target processor.
1.1 APU
Application Processing Unit consists of mainly a Quad-Core A53 ARM processor. Some
chips have only a Dual-Core. A53 processor. This A53 processor is based on ARMv8-A
architecture, 64 bit., can operate up to 1.5 GHz. It has independent Memory Management
Unit (MMU) and dedicated L1 cache.
The four cores of A53 can run symmetrically (they can share workload) and also they
can run independently (Asymmetric MultiProcessing); in this later case they can be unsu-
pervised (no arbiter between AMP blocks) or Supervised (there is a hypervisor coordinating
AMP blocks).
1.2 RPU
Realtime Processing Unit to be used for realtime applications. It consists of mainly a
Dual-Core ARM R5 processor which is built on ARMv7 architecture, 32 bit, can operate
up to 600 MHz. It has also 128 KB of tightly coupled Memory and a dedicated L1 cache.
The cortex-R5 can operate in two dierent modes: split mode or lock-step mode.
Step mode:
This is the default mode.
each core operates independently.
one core may be running OS while the other is running bare-metal or both are running
dierent OS.
Lock-Step mode:
The dual core will act as single CPU.
Both cores are running same instructions in parallel delayed by 1.5 cycle.
1.3 Programmable Logic
1.3.1 Connections
There are several connections to/from the PL
3
Chapter 1. ZynqMP Description 1.3. Programmable Logic
1.3.1.1 AXI Interfaces
Bi-directional From PL To PL
Coherent S_AXI_ACE_FPD S_AXI_HPC0_FPD
S_AXI_HPC1_FPD
Belongs to LPD S_AXI_LPD M_AXI_HPM0_LPD
Performance S_AXI_ACP_FPD
General Purpose, S_AXI_HP0_FPD M_AXI_HPM0_FPD
non-coherent S_AXI_HP1_FPD M_AXI_HPM0_FPD
S_AXI_HP2_FPD
S_AXI_HP3_FPD
Table 1.2: PL AXI Interfaces
1.3.1.2 Interrupts Interfaces
Figure 1.2: Interrupts Interfaces
1.3.1.3 Clocks
There are four clock signals that can be provided from PS to PL.
1.3.1.4 EMIO
ZynqMP has ready GPIO peripherals that can be con gured by the user. These GPIO
peripherals can be routed directly outside the chip through MIO or it can be routed into
the PL part through EMIO interface.
1.3.1.5 Dedicated Streams
The PL part has also interface to high speed modules like Gigabit Ethernet and Display
port peripherals.
4
Chapter 1. ZynqMP Description 1.4. Memory
1.3.1.6 PMU
PL can communicate with the PMU, there are 32 bit signals for data exchange in addition
to some other control signals.
1.3.1.7 DMA
Interfaces to the Memory units is also available to the PL part.
1.3.2 Logic
Any implemented PL logic should have AXI interface to communicate with the PS
for data transfer.
If there are more than one logic, the designer should instantiate AXI Interconnect
IP to allow multiple masters to talk to multiple slaves.
The PL includes integrated blocks for PCI Express, Interlaken, 100 G-Ethernet,
System Monitor and video codec unit.
PL part is con gured by the FSBL at startup.
It is possible to partially load the bitstream le. That is it, FSBL can load part of
the bitstream and the rest can be loaded dynamically while the initial loaded logic
continues to operate without interruption. To accomplish this, you must implement
multiple con gurations that result in full bitstream. This procedure is called Partial
Recon guration and is discussed in Xilinx UserGuide UG947.
1.4 Memory
Zynq Ultrascale+MPSoC devices include:
1. Memory components
2. Memory access controllers
3. External memory interfaces
1.4.1 Memory Components
1.4.1.1 On-Chip Memory (OCM)
256 KB.
has interfaces to PS and PL as well.
can't be accessed through DDR Controller.
FSBL loads the code for booting the PS into the OCM.
used to program non volatile ash memory through JTAG boot mode.
5
Chapter 1. ZynqMP Description 1.4. Memory
1.4.1.2 Tightly-Coupled-Memory (TCM)
Included in cortex-R5 (each core of R5 has TCM).
128 KB each.
each TCM is formed by 2 banks ATCM and BTCM. So in total there are 4 banks in
RPU.
each of ATCM or BTCM is 64 KB - 64 bit wide.
when RPU is operating in split mode, each RPU core can access two 64KB TCM
memory.
when RPU is operating in Lock-step mode, the RPU can access a block of 256 KB
TCM memory.
TCM is also mapped into the global system memory so that it can be accessed by
the APU or PL part. It can be accessed then as two blocks of 128 KB or one block
of 256 KB. The APU access it directly without memory arbitrators.
1.4.1.3 PL Memories
PL has three types of memory blocks which are faster and consume less power: BRAM -
UltraRAM - LUTRAM.
BRAM UltraRAM LUTRAM
These are traditional These are additional aka Distributed
FPGA RAM blocks. in ZynqMP. RAM.
each block is 36 KB. each block is 288 it is built out of
KB. LUT primitives.
each block can be
used as 2x18 KB ZynqMP has in total
or1x36 KB (both can 128 MB
be used as double or
single port).
ZynqMP has in total
35 MB.
1.4.2 PS Memory Controllers
ZynqMP has two general purpose DMA controllers and several peripheral speci c DMA
engines.
6
Chapter 1. ZynqMP Description 1.5. Peripherals
1.4.2.1 General Purpose DMA Controllers
supports memory to memory, memory to I/O, I/O to memory, I/O to I/O transfers.
one is located in FPD, the other is located in LPD.
both manage 8 independent DMA channels.
The FPD-DMA is connected to 128 bit AXI bus, uses 4K buer. The LPD-DMA is
connected to 64 bit AXI bus, uses 2K buer.
1.4.2.2 Peripheral DMA
High speed peripherals on ZynqMP (USB 3.0 - PCI Express - Gigabit Ethernet -
SATA - SDIO - Display Port - QSPI) come with their own DMA controllers.
1.4.3 External Memory Interfaces
Nevertheless, external memory can be connected or attached to ZynqMP e ciently.
ZynqMP provides IP block called Memory Interface Generator (MIG) to handle
attached external memory interfaces (DDR, QDR, RLDRAM).
ZynqMP can support external DDR memory with capacity up to 32 GB.
The external memory will be connected to the system through AXI interconnect
using 6 AXI interfaces.
The interface supports multiple memory standards (DDR3, DDR3L, LPDDR3, DDR4,
LPDDR4, UDIMM, RDIMM).
1.5 Peripherals
As any system block of ZynqMP, peripherals are distributed over four power domains.
Figure 1.3 locates each peripheral in its operation power domain along with the interface
to which it has a way.
7
Chapter 1. ZynqMP Description 1.5. Peripherals
Figure 1.3: ZynqMP Peripherals
GPIO: Although 78 pins of MIO are shared between LPD peripherals, in case we don't
use other peripherals, GPIO can control the entire 78 pins. It can also use pins of
EMIO (96 pins as input, 192 pins as output).
SPI: SPI controllers don't support direct memory access (DMA), hence the communica-
tion is done through register reads and writes to the controller AXI interface.
UART: UART in ZynqMP devices supports a wide variety of parameters; programmable
baud rate; 6 or 7 or 8 data bits; 1 or 1.5 or 2 stop bits; odd or even or space or mark
or no parity.
UART can operate either in normal mode or 3 dierent loopback modes.
QSPI: The Quad SPI controller of ZynqMP includes two types of controllers: the Generic
8
Chapter 1. ZynqMP Description 1.6. Interconnects
QSPI and the legacy QSPI..
Ethernet: 4 Gigabit Ethernet Controllers. Implemented as MAC. Supporting 10/100/1000
Mb/s. Supporting GMII (through PL pins using EMIO), RGMII (through MIO),
SGMII (through PS-GTR).
1.6 Interconnects
It links together all of the processing blocks and enables them to interface with the
outside world through access peripherals, devices and memory.
It is based on AXI.
AXI interface consists of ve dierent channels: Read Address channel, Read Data
channel, Write Address channel, Write Data channel, Write Response channel.
Because there are several components in Zynq, there almost no direct connection
between Master and Slave of the AXI bus.
1.7 Interrupts
In Zynq there are two interrupt controllers
GIC-V1: It is implemented for RPU. Each cortex-r5 will have two interrupt lines (normal
interrupt nIRQ, normal high priority nFIQ).
GIC-V2: This is same as GIC-V1 but enables interrupt virtualization and it is implemen-
ted for APU. Each cortex-a53 will have four interrupt lines (normal interrupt nIRQ,
normal high priority nFIQ, virtual interrupt vIRQ, virtual high priority vFIQ).
Interrupt Sources:
Software Generated Interrupts (SGI).
Private Peripheral Interrupts (PPI).
Shared Peripheral Interrupts (SPI).
Interprocessor Interrupts (IPI); In ZynqMP there are 11 IPI channels four, of them
are reserved for communication with PMU.
1.8 Booting Process
Booting ZynqMP can be done in two modes
9
Chapter 1. ZynqMP Description 1.9. Isolation and Protection
1.8.1 Non-Secure Booting
It can be declared as shown in gure1.4.
Figure 1.4: ZynqMP Boot Sequence
Firmware of the CSU is stored by the manufacturer into a ROM so it is not customi-
zable. This rmware when it starts it loads FSBL rmware into OCM to be accessed by
the APU (or RPU).
1.8.2 Secure Booting
It is same as Non-Secure booting but with addition that the loaded image is encrypted. In
this case the CSU performs decryption and loads FSBL into OCM.
1.8.3 Bootings Devices
CSU supports booting from QSPI, NAND, SD, eMMC, JTAG. CSU doesn't support NOR,
SATA, Ethernet, PCI Express.
1.9 Isolation and Protection
Xilinx ZynqMP provides some mechanisms to protect the device resource from tampering.
These mechanisms are mainly ltering tra c passing to the resource based on its ID.
ZynqMP resources can be mainly described as: Processing Units, Memory Units, Pe-
ripherals Units. Therefore each of these units resources is protected by SMMU (System
Memory Management Unit), XMPU(Xilinx Memory Protection Unit), XPPU (Xilinx Pe-
ripheral Protection Unit).
10
Chapter 1. ZynqMP Description 1.10. Power Management
1.9.1 Trustzone
The APU provides further additional mechanism (Trustzone) for isolating and partitioning
software running on it.
Trustzone mechanism makes partitioning of software to secure or non-secure. This
partitioning is communicated across AXI interactions.
This mechanism adds more security level beneath OS level. Traditional processing
systems give OS more privilege than the running software, which is known as user space
and kernel space. Trustzone-capable ARM processor gives more privilege to this layer more
than the OS. The OS still thinks as if it has the highest privilege.
1.9.2 Exception Levels
Trustzone as implemented on the APU (ARMv8-a53) de nes four privilege levels or as it
is called Exception Levels. Level 0 is lowest privilege, level 3 is the highest.
EL0: Applications SW are given this privilege.
EL1: OS are given this privilege (OS are called also supervisor).
EL2: Hypervisor is given this privilege (this is when running multicore processor).
EL3: ARM Trusted Firmware (ATF) is given this privilege as it is the security monitor.
1.10 Power Management
Five main techniques which we can use to tune system's power management on ZynqMP
1. Feature Disabling
2. Dynamic Power Management
3. Frequency Scaling
4. Clock Gating
5. Use of PL Acceleration
1.10.1 Power Domains
Battery Power Mode: 180 nW ~ 3uW : used for realtime clock and battery backed
RAM.
Low Power Mode: 20 mW ~ 450 mW.
Full Power Mode: 450 mW ~ 2.5 W.
PL Power Mode: depends on implemented logic.
11
Chapter 2
Hardware
ZynqMP can't be used without it processing unit. i.e. developers can't utilize the PL part
independently. That is because the PL is programmed through the FSBL rmware which
is executed by the processing system. Therefore any hardware used in ZynqMP must be
associated with a processing unit.
This leads us to conclude that Xilinx tools are needed in order to instantiate the
processing unit into the hardware model, which means we have to use Vivado to build that
and we have to make sure that we have appropriate license for the instantiated modules
or IPs.
A typical system should look like what is shown in gure 2.1 which shows a simple
system consists of the processing unit, AXI interconnect and a GPIO unit. The GPIO
unit is a peripheral that is attached to the processing system through AXI interconnect
instance, this is mandatory; i.e. we can't attach the peripheral directly to the processing
system.
12
Chapter 2. Hardware 2.1. Processor Con guration
Figure 2.1: Sample Hardware Model [1]
In Vivado to build such a model, we have to create what is called Block Design. This
Block Design contains important instances of the Hardware model such as the processing
system and IP peripheral of Xilinx (GPIO, Gigabit transceivers, etc). It is important to
note that, the Hardware model shall contain this block design at the second level. That
means that the top design le shall contain a wrapper of a block design that contains
ZynqMP processor. Without that, device tree model will not be generated for the design
as putting the ZynqMP processor in any lower level will not allow to the processor to be
seen or detected using SDK tool.
2.1 Processor Con guration
The processing system of ZynqMP can be con gured according to the user needs. In
Vivado GUI double click on the processing system instance in the block design. Figure
2.2 shows main processing system components, you can then choose which component to
enable or to con gure.
13
Chapter 2. Hardware 2.2. HDF and Bitstream Generation
Figure 2.2: Processing System Con guration[1]
2.2 HDF and Bitstream Generation
After building the needed Hardware model, what is important to extract from it is to
have HDF le and Bitstream File. HDF le is used to as a description of the Hardware
and it is used in Software ow in order to generate Devicetree and other needed rmware.
Bitstream le is optional to have and it is needed only if the hardware model is utilizing
the PL part. To generate HDF le in Vivado GUI, choose from top menu File >> Export
>> Export Hardware.Choose then where you want to store this HDF le.
Figure 2.3: Export Hardware Window[1]
Alternatively, you can use the following Vivado TCL command.
write_hwdef - force - file path / to / preferred / filename . hdf
Generation of bitstream is similar to any PL ow; in Vivado GUI click on 'Generate
Bitstream'.
14
Chapter 3
Firmware
3.1 Preparations
3.1.1 Cross Compiler
ZynqMP has ARM Cortex a53 and Cortex r5 processors. For applying any rmware or
software that should run in these processors, we have to cross compile the rmware or soft-
ware. By default, Xilinx tools (namely SDK) provides cross compiler toolchain for both
processors. If you prefer to work with another cross compiler, it is ne.
Cross Compiler provided by SDK can be found in
<INSTALLATION_DIR>/SDK/<version>/gnu/
In this directory you can nd cross compiler for ARM64 architecture (aarch64), and for R5
architecture (armr5). Inside aarch64, you can nd cross compiler for Linux-based rmware
(aarch64-linux) or for Bare-metal rmware (aarch64-none).
3.2 First Stage Boot Loader
After powering on ZynqMP (or any processing system in general), a built-in routine starts
up and handles the booting process to next routine. In our case here, FSBL is rst routine
that initializes the ZynMP FPGA and make necessary setting. The following lines describes
how to build FSBL for ZynqMP.
3.2.1 Input Files
hdf (or BMM) le, bit le is optional.
3.2.2 Output Files
elf le
15
Chapter 3. Firmware 3.2. First Stage Boot Loader
3.2.3 Tools
SDK (GUI) or HSI (command line) or XSCT(command line).
3.2.4 Procedure Using HSI
HSI (Hardware Software Interface) is a framework by Xilinx used to perform some proce-
dures needed for third party tools. Details about this tool is included in Xilinx UG1138.
Some help can be displayed also by typing
$ hsi -h
Or for help about speci c command you can type
$ hsi generate_app - help
For creating FSBL
$ hsi generate_app - hw $hwdsgn - os standalone - proc ps7_cortexa9_0 - app
zynq_fsbl - compile - sw fsbl - dir < dir_for_new_app >
3.2.5 Procedure Using XSCT
XSCT is a Xilinx framework that is used to perform operations done in SDK but in
command line mode. To generate an FSBL elf le the following routine can be used
setws .
createhw - name hw0 - hwspec << HW_HDF_FILE_HERE > >
createapp - name fsbl1 - app { Zynq MP FSBL } - proc psu_cortexa53_0 - hwproject
hw0 - os standalone - lang c - arch 64
projects - build
you can get help about any of the above commands by typing
$ < command name > - help
3.2.6 Procedure Using SDK
Open SDK
In the top menu, File >> New >> Project
Choose from Xilinx >> Hardware Platform Speci cation
16
Chapter 3. Firmware 3.2. First Stage Boot Loader
Figure 3.1: FSBL - Choose Hardware[1]
Figure 3.2: FSBL - Browse HDF File [1]
Browse to the generated Hardware (hdf le) then click Finish.
In the top menu, File >> New >> Application Project
Choose the shown options and make sure that Hardware Platform is what you have
built previously.
17
Chapter 3. Firmware 3.2. First Stage Boot Loader
Figure 3.3: FSBL Settings [1]
Click Next, choose to create Zynq MP FSBL
Figure 3.4: FSBL Template[1]
Click Finish to generate the FSBL
Right Click on the created project to `Build Project'
18
Chapter 3. Firmware 3.3. PMU
Figure 3.5: FSBL Board Support Package [1]
Generated FSBL elf le can be found under created FSBL project >> Debug >>
example_fsbl.elf
3.3 PMU
Platform Management Unit is a special unit in the Zynq MP used to power up the system
and power management (switching PS between dierent power modes). It also supports
Inter-Process Interrupts (IPI) for communication between the system processors (to do
some power actions).
This PMU has MicroBlaze processor which is connected to 128 kilobytes of RAM with
error-correcting code (ECC) that is used for data and rmware as well as storage of the
Xilinx provided framework code.
Figure 3.6: PMU Block Diagram
19
Chapter 3. Firmware 3.3. PMU
3.3.1 PMU ROM
Inside the ROM resides rmware that makes speci c functions like:
3.3.1.1 Functions at Power On
After power on, the PMU performs the following sequence of events before handing o to
the Con guration Setup Unit (CSU):
Provides power integrity check using the system monitor (SysMon) assuring proper
operation of the CSU and the rest of the LP domain.
Initializes the PLLs
Triggers and runs the Memory Built in Self Test (MBIST)
Captures and signals errors which can be read through JTAG
Powers down any Power Islands and other IP disabled via eFuse
Releases Reset to CSU
3.3.2 PMU RAM
Inside the RAM resides Error Correction Code (ECC) and optional user rmware that can
be tailored to manage and control power of the chip. This rmware can be generated using
Xilinx tools (e.g. SDK) as it has ready template for that rmware.
3.3.3 Input Files
hdf (or BMM) le, bit le is optional.
3.3.4 Output Files
elf le
3.3.5 Procedure Using XSCT
You can use these commands to generate the elf le
createhw - name hw0 - hwspec $HDF_Source
createapp - name generated_pmu - app { ZynqMP PMU Firmware } - proc psu_pmu_0
- hwproject hw0 - os standalone - lang c - arch 64
projects - build
closehw hw0
3.3.6 Procedure Using SDK
Same as FSBL generation except for processor type choose psu_pmu_0
20
Chapter 3. Firmware 3.4. ATF
Figure 3.7: PMU Build Setting
3.4 ATF
ATF is responsible for preserving and restoring the non-secure context when switching to
the secure context. It's also responsible for part of the power-management since the PMU,
which is responsible for power management, is a secure AXI slave and will therefore not
accept any commands issued by a hypervisor or non-secure OS running on the APU. Power-
management requests made by non-secure OSes, such as Linux, are therefore provided
through the ATF to interact with the PMU.
Xilinx software stacks running on the Zynq US+ MPSoC APU conform to the standard
ARMv8 topology where Linux running at ARM EL1/0 has hardware-limited access to
system or security-critical registers or devices. All interactions from Linux to those devices
or registers are routed through ARM Trusted Firmware which runs at EL3.
Figure 3.8: APU Software Stack
ARM Trusted Firmware provides a reference to secure software for ARMv8-A archi-
tecture and it provides implementations of various interface standards like PSCI(Power
State Coordination Interface) and Secure monitor code for interfacing to Normal world
software. Xilinx ARM trusted rmware is based on arm trusted rmware. Xilinx ARM
Trusted Firmware implements the EL3 rmware layer for Xilinx Zynq UltraScale + MP-
SoC. The platform only uses the runtime part of ATF(EL3 rmware) as ZynqMP already
has a BootROM (BL1) and FSBL (BL2). [4]
21
Chapter 3. Firmware 3.4. ATF
3.4.1 Procedure in Linux
To build ATF in Linux, the following is needed
Linux machine with the following packages are installed
$ sudo apt - get install build - essential gcc make git libssl - dev
Cross Compiler tool: this can be obtained from Xilinx tools installation directory
Xilinx>>SDK>>2017.3>>gnu>>aarch64>>nt>>aarch64-linux
Note that if you want to build the ATF for another 32bit ARM, use cross compiler for
that architecture (gnu>>aarch32>>. . . ).
Download ATF source code from:
$ git clone https :// github . com / Xilinx / arm - trusted - firmware . git
or it can be downloaded from here (for the case of windows without git)
https://github.com/Xilinx/arm-trusted- rmware/releases/
De ne path to the cross compiler tool
$ export CROSS_COMPILE = < path - to - aarch64 - gcc >/ bin / aarch64 - linux - gnu -
Build the ATF by
$ make PLAT = zynqmp RESET_TO_BL31 =1
After the build process completes the bl31.elf binary is created within the /build/zyn-
qmp/release/bl31 directory.
3.4.2 Procedure in Windows
For running it in command line, XSCT shall be used. The following script can be used
set ATF_BuildDir ./ workspace_02
set ATF_Source C :/ Xilinx / SDK /2017.3/ data / embeddedsw / lib / sw_apps / atf_sources
set MakeDir $ATF_BuildDir / atf_sources / src
set Script_Dir [ pwd ]
setws - switch $Script_Dir
after 1000
exec mkdir -p $ATF_BuildDir
file delete - force -- $ATF_BuildDir
exec mkdir -p $ATF_BuildDir
cd $ATF_BuildDir
setws - switch .
after 1000
exec cp -r $ATF_Source .
# _ ### NOTE : It is recommended to run the make step manaully
# _ ###: so take the following line copy - paste in command window
# _ ##############################
22
Chapter 3. Firmware 3.4. ATF
# exec - ignorestderr make -C $MakeDir CROSS_COMPILE = aarch64 - none - elf -
RESET_TO_BL31 =1 PLAT = zynqmp bl31
3.4.3 Procedure Using SDK (GUI)
Open SDK
File>>New>>Project
Figure 3.9: ATF Start Project [1]
Choose ARM Trusted Firmware Project then Click Next
23
Chapter 3. Firmware 3.4. ATF
Figure 3.10: ATF Project Settings [1]
Provide Project Name and Location. Choose Build Con guration eld as Release. Hit
nish.
Output le will be built as shown below in the highlighted path
Figure 3.11: ATF Project Output [1]
Note that ATF source les are downloaded by default in SDK in the following path
24
Chapter 3. Firmware 3.5. Device Tree
Figure 3.12: ATF Source Path [1]
3.5 Device Tree
In order for the Operating System to recognize what hardware or devices are built and
attached to the processing system, a description of these devices shall be provided to the
Operating System or speci cally the kernel. For that purpose, a dts le (device tree source)
is used to list all the attached devices. This dts le is compiled into dtb le (device tree
blob) which is a binary le to be loaded during booting sequence into ram and read by
the kernel (The boot loader copies that chunk of data into a known address in the RAM
before jumping to the kernel's entry point).
Assume you have built a hardware in the Xilinx Zynq with the processing system and
simple GPIO controller in the FPGA part as shown in gure 3.13
Figure 3.13: Simple Hardware in ZynqMP [1]
This GPIO controller is connected to the Zynq processor as a slave via AXI bus. To
25
Chapter 3. Firmware 3.5. Device Tree
build device tree for such a system Xilinx SDK tool can be used as discussed later. What
can be shown here is the AXI bus is considered as a hardware node that is attached to the
processor. The GPIO controller is considered as another hardware node that is attached
to the AXI bus. So in the DTS le, the description of the GPIO controller will be inside
description of the AXI bus. For the shown architecture, the DTS le should have
Figure 3.14: Device Tree Description
As you can see then, a DTS le contains tree structure of hardware nodes. Each node
has some parameters and properties. A basic format of this structure can be considered as
/ dts - v1 /;
/ {
node1 {
a - string - property = " A string " ;
a - string - list - property = " first string " , " second string ";
// hex is implied in byte arrays . no '0 x ' prefix is required
a - byte - data - property = [01 23 34 56];
child - node1 {
first - child - property ;
second - child - property = <1 >;
a - string - property = " Hello , world " ;
};
26
Chapter 3. Firmware 3.5. Device Tree
child - node2 {
};
};
node2 {
an - empty - property ;
a - cell - property = <1 2 3 4 >; /* each number ( cell ) is a uint32 */
child - node1 {
};
};
};
Source : [2]
3.5.1 Device Tree Important Parameters
Back to the generated DTS of the GPIO controller, we need to get important parameters
that a hardware node should contain.
3.5.1.1 Label and Name
In the gpio controller example, the label and name is axi_gpio_0: gpio@80000000. The la-
bel is an optional eld. The name shall be in the shown format <DeviceName>@<PhysicalAddress>.
Device name must not be unique, i.e. many devices can use the same name.
3.5.1.2 Binding
First and most important parameter is the compatible parameter. It should carry a
unique name. This unique name will be used with the device SW driver in order to
have a link between the SW driver and the HW device. When Linux kernel starts, it is
interrogating the device tree le and kick o the corresponding kernel module according
to the value speci ed in the parameter compatible. The developer is free to choose any
name or string for his device but it should be the same name also used in the SW driver.
As a convention, most vendors are de ning their devices as in this form
<manufacturer>, <model>
So in our example here it is xlnx,xps-gpio-1.00.a. This name shall be used when
building SW driver for the gpio controller. This driver will de ne it as follows in the driver
source le
static struct of_device_id xillybus_of_match [] __devinitdata = {
{ . compatible = " xlnx , xillybus -1.00. a " , } ,
{}
};
MODULE_DEVICE_TABLE ( of , xillybus_of_match ) ;
More details about building the driver is discussed in SW drivers section later.
3.5.1.3 Addressing
In the attached node `reg' parameter contain the assigned address of the hardware node.
In its simplest form it should be like
27
Chapter 3. Firmware 3.5. Device Tree
reg = <0x80001000 0x1000>
which means that the device is assigned on physical address 0x80001000 and allocated
with the size 0x1000 (4K). It can also have two addresses
reg = <0x101f3000 0x1000
0x101f4000 0x0010>;
The parent node (amba_pl@0 in our example), will contain information about format
of the `reg' parameter. This is de ned by #address-cells and #size-cells parameters. In
the simplest form it can be de ned as
#address-cells = <1>;
#size-cells = <1>;
In this case, it indicates that the child nodes will have 1 cell for the address and 1 cell
for the size. Each cell is represented by 32 bit integer. So de nition like reg = <0x80001000
0x1000> will be the right form.
In our example of GPIO controller address-cells and size cells are de ned with value 2
both. This is because this system is built for 64 bit processor (Armv8). So the addressing
of the GPIO controller was assigned as reg = <0x0 0x80000000 0x0 0x1000>; with 0x0
0x80000000 is considered a 64 bit address, 0x0 0x1000 is 64 bit size.
3.5.1.4 Interrupt
Interrupt is a signal between two devices to indicate special activity has taken place. In
the DTS le, the device that receive interrupts is marked with the statement interrupt-
controller; as shown in gure 3.15 taken from zynqmp.dtsi le
Figure 3.15: Interrupt Parameter
Four properties are used to describe interrupt connections:
Interrupt-controller: as shown in gure 3.15 this is the device that receives interrupt
signal.
Interrupt-parent: this parameter is declared at the device which sends interrupt
signal to declare to whom this signal is sent. See gure 3.15 for example.
#interrupt-cells: this is declared at the interrupt controller to specify how many
values are used to describe the interrupts parameter.
28
Chapter 3. Firmware 3.5. Device Tree
Interrupts: this is the parameter that describes when the interrupt is happening.
Figure 3.16: Interrupt Source
In gure 3.16 the interrupt is described with the numbers <0 89 4>.
Xilinx is using 3 cells for describing the interrupt. In our example here rst cell is 0
which means it is non SPI interrupt. Second cell is 89 is like ID for the interrupt. This
ID can be found in Xilinx Zynq technical reference manual (UG 1085). In our example
here the ID is mapped to IRQ number (89+32) to be at the end 121. From UG 1085 it is
interrupt signal sent from PL to PS. Third cell is 4 which represents type of interrupt, it
has three possible values
0 Leave it as it was (power-up default or what the bootloader set it to, if it did)
1 Rising edge
4 Level sensitive, active high
3.5.1.5 Custom Arbitrary Parameters
Because each device is mainly dierent in functionality than other devices, developers can
write their own custom information in the device tree. For example in the gpio controller it
has parameter to de ne width of the output pins xlnx,gpio-width = <0x8>; The xlnx,
pre x protects against name collisions and it is arbitrary string. To get more information
about convention that Xilinx is using for its DTS les, this can be found in [3].
There are some other properties that can be described in the DTS le like aliases and
chosen. Which is best described in [2].
3.5.1.6 Overwriting
To overwrite a property, the node needs to be referenced using the ampersand character
and the label. Later device tree entries overwrite earlier entries (the sequence order of
entries is what matters, hence the include order matters). Typically the higher layers (e.g.
carrier board device tree) overwrite the lower layers (e.g. SoC device tree) since the higher
layers include the lower layers at the very beginning. e.g. for USB controllers which are
29
Chapter 3. Firmware 3.5. Device Tree
capable to be device or host (dual-role), one can overwrite the default mode explicitly using
the dr_mode property:
& usbdev0 {
dr_mode = " host " ;
};
3.5.2 DTS Organization in Xilinx
Since any hardware platform has a lot of attached devices and peripherals, describing node
by node needs a lot of eort. Therefore it is better to use Xilinx tools for automating this
process. Using SDK the following DTS can be generated for the system.
/ dts - v1 /;
/ include / " zynqmp . dtsi "
/ include / " zynqmp - clk - ccf . dtsi "
/ include / " pl . dtsi "
/ include / " pcw . dtsi "
/ {
chosen {
bootargs = " earlycon clk_ignore_unused " ;
stdout - path = " serial0 :115200 n8 " ;
};
aliases {
ethernet0 = & gem3 ;
serial0 = & uart0 ;
serial1 = & uart1 ;
spi0 = & qspi ;
};
memory {
device_type = " memory " ;
reg = <0 x0 0 x0 0 x0 0 x80000000 > , <0 x00000008 0 x00000000 0 x0
0 x80000000 >;
};
};
which is organizing the hardware nodes into dierent les. Zynqmp.dtsi is a ready
template to describe the processing system of Zynqmp. Zynqmp-clk-ccf.dtsi is describing
clock con guration of each attached node. Pl.dtsi describes hardware nodes that are built
in the programmable logic part.
pcw.dtsi is the con guration of the processor (processor con guration wizard). Since
zynqmp.dtsi is a ready template, pcw.dtsi is used to con gure or modify hardware nodes
described in zynqmp.dtsi.
For example, by default all peripherals attached to the processing system are disabled
as shown in gure 3.17.
30
Chapter 3. Firmware 3.5. Device Tree
Figure 3.17: Disabled Peripherals
All shown peripherals here have status = disabled. But for a user who wants to
activate UART1 peripheral, the pcw.dtsi will contain as shown in gure 3.18
31
Chapter 3. Firmware 3.5. Device Tree
Figure 3.18: Enabling Peripheral
Status of uart1 here is okay.
32
Chapter 3. Firmware 3.5. Device Tree
3.5.3 Other User DTS Con guration
There are other values that can be provided in Device Tree description which aids in
building the system. For example the aliases values de nes which node is targeted. Also
there are three sources for the kernel boot command line in general:
Those given as CONFIG_CMDLINE in the kernel con guration.
Those passed on by the boot loader (U-boot on ARM processors).
Those included in the device tree, under chosen/bootargs (see listing above).
Which one is used, depends on kernel con guration parameters.
3.5.4 Using SDK to build DTS le
3.5.4.1 Procedure Using SDK GUI
Open GUI interface of Xilinx SDK
From top menu open Xilinx>>Repositories.. The following window shall open.
Figure 3.19: Repositories in SDK [1]
At this step we need to add repository of Xilinx Device Tree. This can be downloaded
from this link
https://github.com/Xilinx/device-tree-xlnx.git
33
Chapter 3. Firmware 3.5. Device Tree
Add the local repository by hitting on `New' button and browse to choose location of
downloaded Xilinx Device Tree Repository.
Figure 3.20: Add New Repository [1]
Click `OK'. Then in the Main SDK window, In the top menu, File >> New >> Project
Choose from Xilinx >> Hardware Platform Speci cation
Browse to add Target Hardware Speci cation is declared previously. Then click `Finish'.
Then in SDK main window choose File>>New>>Board Support Package. The follo-
wing wizard shall open.
34
Chapter 3. Firmware 3.5. Device Tree
Figure 3.21: New Device Tree BSP [1]
Choose Location of the bsp project. Important to choose device_tree in the OS eld.
The following window will open to choose further con guration/setting for the genera-
ted dts le.
Figure 3.22: Device Tree BSP Con guration [1]
For example you can change name of the generated dts le or add boot arguments.
Click `OK'. Generated dts les can be obtained from the created BSP directory.
35
Chapter 3. Firmware 3.6. UBoot
3.5.4.2 Procedure Using XSCT Command Line
First we need to have local repository of Xilinx Device Tree which can be obtained by
git clone https :// github . com / Xilinx / device - tree - xlnx . git
The following routine can be used to generate the dts les
createhw - name hw0 - hwspec $HDF_Source
repo - set $XDT_Dir
createbsp - name generated_DTS - hwproject hw0 - proc psu_cortexa53_0 - os
device_tree - arch 64
configbsp - bsp generated_DTS master_dts HW_System . dts
regenbsp - bsp generated_DTS
closehw hw0 closebsp generated_DTS
Note that in this routine, $XDT refers to downloaded Xilinx Device Tree repository.
3.5.5 Generating DTB Binary
DTS le has to be converted eventually to DTB le to be understood by the kernel. Device
Tree Compiler (DTC) can be obtained from Linux mainstream at:
$ git clone https :// git . kernel . org / pub / scm / utils / dtc / dtc . git
then navigate to the downloaded directory and build it
$ cd dtc
$ make
Note that no cross compile ag is needed to build it as this build is to build the dtc
compile itself on the host machine. So the resulted compiler is needed. So export it to the
PATH variable
$ export PATH =/ path / to / dtc : $PATH
The DTB le can be obtained then by
$ dtc -I dts -O dtb -o < devicetree name >. dtb < devicetree name >. dts
3.6 UBoot
Universal Bootloader is used for booting the kernel and rest of operating system compo-
nents. It can be downloaded directly for Xilinx FPGAs from
$ git clone https :// github . com / Xilinx /u - boot - xlnx . git
Then this can be con gured according to the target board and built to generate binary
le.
36
Chapter 3. Firmware 3.6. UBoot
3.6.1 Quick Build
To build the uboot, a DTC compiler is needed. This can be downloaded also from here
$ git clone https :// git . kernel . org / pub / scm / utils / dtc / dtc . git
This compiler should be built also. After building it add path of this compiler to the
$PATH environment variable
$ export PATH =/ home / user / work / dtc : $PATH
also to build the UBoot, a cross compiler is needed
$ export CROSS_COMPILE =/ path / to / bin / aarch64 - linux - gnu -
now open the downloaded UBoot source
$ cd path / to /u - boot - xlnx
we need to load con guration of the target architecture (which is Xilinx Zynqmp)
$ make xilinx_zynqmp_zcu102_rev1_0_defconfig
note that this con guration le exists in ./con gs directory. So make sure always of
the right name of this le. You can add further your own con gurations
$ make menuconfig
building is now ready
$ make
after make process is nished, output le u-boot.elf is needed in other steps.
3.6.2 U-Boot Con guration
Previous steps are straight forward steps to build a U-boot quickly. Occasionally, this
is not the case as we need to con gure U-boot to match our target hardware. U-boot
is con gured and built like a Linux manner. This means a .con g le is loaded into u-
boot directory in order to have nal con guration of the system. As described before,
this .con g le is loaded from the target architecture con guration le that is located in
./con gs directory. So eventually target_hw_defcon g is most important le as it contains
all needed con gurations. Among other system con guration, two important con gurations
we have to take care about: System Con guration and Device Tree Con guration, which
are highlighted in gure 3.23
37
Chapter 3. Firmware 3.6. UBoot
Figure 3.23: UBoot Con guration Sources
3.6.2.1 System Con guration
First con guration is called system con guration or as named as
CONFIG_SYS_CONFIG_NAME.
This parameter tells the compiler where to nd other extension for the con guration.
This extension of the con guration is not included in defcon g le as it is usually tailored
according to the used system. For example, the user board is designed to boot from QSPI.
So in the main con guration le (defcon g) we can enable booting from QSPI, but in the
System Con guration le we can mention which partition of the QSPI we shall boot. In
our example here the extended system con guration le is called Xilinx_zynqmp_zcu102.h
and it can be found in ./include/con gs.
3.6.2.2 Device Tree Con guration
The second highlighted con guration is the device tree con guration. As its name makes
it clear, The running hardware has to be de ned for the U-boot in order to enable U-boot
to run into it. In our example here, the le zynqmp-zcu102.dts shall be provided in that
directory: ./arch/arm/dts/
It worth mentioning here that special drivers are built in u-boot to handle then working
with the attached devices that are described in device tree le.
3.6.2.3 Board Con guration
Nevertheless, you can con gure how U-boot will detect the boot media from a board
con guration le that is located in ./board directory. Here you can nd some ready board
con guration les for some supported device. For our case, Xilinx board con guration le
is located in subdirectory of Xilinx. What is important in this le is the setting for the
booting modes as shown in gure 3.24
38
Chapter 3. Firmware 3.6. UBoot
Figure 3.24: UBoot Board Con guration
In this sample, U-boot con guration is reading speci c register in the Xilinx FPGA in
which it recognizes which medium is set for booting. Value of this register is set according
to some jumpers settings in the host board. This in turn will set some values back in
the extended system con guration le. i.e. System Con guration le knows boot medium
according to values passed from board con guration le.
3.6.3 Debugging U-boot Settings
During development phase, developer may need to explore or understand some environment
variable settings. Then he may need to stop auto booting of u-boot in order to tweak some
settings. In this case we disable auto booting by setting boot delay to -1. This setting can
be added using menucon g in the main menucon g window>> delay in seconds before
automatically booting. This can be set to -1 or in the main con guration le we can set
it using the parameters CONFIG_BOOTDELAY=-1
39
Chapter 3. Firmware 3.6. UBoot
3.6.4 Adding Customized Con gurations
In System Con guration le there is de nition for the needed setting of booting process
de ned in the macro CONFIG_EXTRA_ENV_SETTINGS. For example here, in board
con guration le, the modeboot variable is set to either sdboot, nandboot, qspiboot, etc.
In System Con guration le, there is a description of how to boot using these values.
As a common technique, you can describe booting approach in external le called
usually as uEnv.txt. This is not common in all u-boot les but mostly used. For example
in Xilinx it is de ned in the case of sdboot the following
sdboot = mmc dev $sdbootdev && mmcinfo && run uenvboot || run
sdroot$sdbootdev ;
Which means that u-boot should switch to mmc dev sdbootdev then prints informa-
tion about this sd device then runs a prede ned command called uenvboot or run another
prede ned command sdroot. In uenvboot command it is checking whether there is a le
called uEnv.txt or not, it so it should boot according to description mentioned in uEnv.txt
uEnv.txt a separate text le. For example the following can be de ned in this text le
ddr =00:0 a :35:00:01:22
kernel_image = uImage
devicetree_image = devicetree . dtb
sdboot = if mmcinfo ; then echo UENV Copying Linux from SD to RAM ... && load
mmc 0 0 x3000000 $ { kernel_image } && load mmc 0 0 x2A00000 $ {
devicetree_image } && bootm 0 x3000000 - 0 x2A00000 ; fi
what is needed then is to put this le with the content of the SD card with other
booting les.
Importance of this approach appears when during development phases. Instead of
compiling u-boot each time you modify the global environment variable, you can direct
u-boot to simply to read these values from external le.
3.6.5 Booting from Correct SD Partition
Usually SD card is partitioned into two partitions: boot (partition 1) and root (partition
2). Pointing to the right partition is clari ed in the environment variable
sdboot = mmc dev $sdbootdev && mmcinfo && run uenvboot || run
sdroot$sdbootdev ;
The last command (run sdroot$sdbootdev) is running another environment variable
after replacing $sdbootdev with its value. In our example here this $sdbootdev is
expecting to have 0 (for mmc0) or 1 (for mmc1).
Both environment variables have the same arguments to boot from SD card except for
partition number
" sdroot0 = setenv bootargs $bootargs root =/ dev / mmcblk0p2 rw rootwait \0 " \
" sdroot1 = setenv bootargs $bootargs root =/ dev / mmcblk1p2 rw rootwait \0 " \
40
Chapter 3. Firmware 3.6. UBoot
What we can see then from these variables is they are using name of the partition
(mmcblk0p2 or mmcblk1p2). One drawback can be faced from this de nition is the name
of the mmc device may change when linux kernel is loading. For example, in your device
tree you may have
Figure 3.25: MMC in Device Tree File
But when linux kernel is loaded the driver of sdhci devices will label it in reverse
Figure 3.26: MMC in Boot Sequence
In this case, sdroot0 and sdroot1 shall be reversed in device tree. Or the better
solution is to point to the target partition in u-boot using uuid. This can be achieved as
follows
In the con guration le Xilinx_zynqmp.h, the following variable is de ned for sdboot
sdboot = mmc dev $sdbootdev && mmcinfo && run uenvboot || run
sdroot$sdbootdev ;
41
Chapter 3. Firmware 3.6. UBoot
In which it runs sdroot$sdbootdev. we can replace this last command with another
command to direct u-boot to boot using uuid
sdboot = mmc dev $sdbootdev && mmcinfo && run uenvboot || run getuuid && run
uuidroot ;
In which we run two commands, rst one to get uuid of the target partition (second
partition of the SD card). Then we boot according to the obtained uuid. So these two
commands have to be de ned also in the loaded environment variable as follows
" getuuid = part uuid mmc $sdbootdev :2 myuuid \0 " \
" uuidroot = setenv bootargs $bootargs root = PARTUUID = $myuuid rw rootwait \0 " \
3.6.6 Booting from TFTP Server
In case of there is a need to boot the Linux Image from a remote machine, this can be done
in U-boot using tftpboot command. This is needed especially during development phases
of a project.
Dealing with tftpboot command is pretty simple:
tftpboot < load_addr > < target_image >
Using this command, we can then load Linux image, device tree le, compressed root
le system. For example the following command can be used in environment variables
declaration space
tftpboot 80000 Image && tftpboot $fdt_addr system . dtb && tftpboot 6000000
rootfs . cpio . ub
In which we load the pointed les into the declared RAM address of the processor.
Afterwards, all what we need is to boot from this loaded items. This can be done using
the following command
booti 80000 6000000 $fdt_addr
But note that this tftpboot depends on initial declaration of the ip address of the tftp
server. This can be easily de ned also in u-boot environment variables space using the
following sample
setenv ipaddr 192.168.1.10
setenv serverip 192.168.1.1
In which we set ip address for the target board and declare the ip address of the server.
At the server itself, a tftp server shall be running. In windows, free tool can be down-
loaded and run like tftpd64 (tftpd64.460.zip).
3.6.7 Booting From NFS
Using the same mechanism, we can use u-boot to enable loading root fs from a network
in what is called NFS in which the root le system is hosted in a remote machine in the
network without the need to transfer the whole le system to the target board. Linux
42
Chapter 3. Firmware 3.6. UBoot
kernel when loaded will point to this remote root le system. This can be done in u-boot
by passing the appropriate arguments to Linux kernel.
def_args = console = ttyPS0 ,115200 rw earlyprintk
nfs_args = setenv bootargs $ { def_args } rootwait root =/ dev / nfs nfsroot = $ {
serverip }: $ { serverpath } ip = dhcp
where serverpath is a variable that shall be de ned to point out where the location of
the NFS is. In the remote machine, an NFS server shall be installed. Then we can boot
using the following command
bootm $ { kernel_addr } - $ { devicetree_addr }
3.6.8 Scripting Boot Procedure
So far we have seen many settings and con gurations as well as dierent booting methods.
As a developer, you might need to change all these con gurations while building your
system. There is one common approach is to write an initial script that U-boot can
understand and behave according to instructions described in that le. The idea is somehow
near to uEnv.txt mentioned previously with the dierence that here in the script you can
write U-boot commands.
3.6.8.1 Boot Script Sample
The following can be a sample of how a booting script can look like
setenv kernel_img_name " Image "
setenv kernel_loadaddr 0 x6000000
setenv rootfs_img_name " rootfs . cpio . uboot "
setenv rootfs_loadaddr 0 x10000000
setenv dtb_img_name " devicetree . dtb "
setenv dtb_loadaddr 0 x6e00000
tftpboot $kernel_loadaddr $kernel_img_name ;
tftpboot $rootfs_loadaddr $rootfs_img_name ;
tftpboot $dtb_loadaddr $dtb_img_name ;
booti $kernel_loadaddr $rootfs_loadaddr $dtb_loadaddr ;
At the moment, lets assume that this script is saved in normal text le called sam-
ple_uboot_script.txt
3.6.8.2 Boot Script Format
In order to be able to run such a script within U-Boot environment, it should be prepared
in special format. To prepare this format, there is an utility produced when compiling
U-Boot. This utility is called mkimage and can be found after compiling U-Boot in the
subdirectory tools. So, you can add it to your PATH variable in Linux.
43
Chapter 3. Firmware 3.6. UBoot
$ cd tools
$ export PATH = $PWD : $PATH
Then, to create the needed script format use the such like the following command
mkimage -T script -A arm64 -C none -n ' Our U - Boot script . ' -d
sample_uboot_script . txt sample . scr
Where sample_uboot_script.txt is the text le contains your U-Boot script commands.
Sample.scr is the output of this mkimage command. In this command we mentioned also
which architecture the script will be running on using A switch. C is set to none to
mean uncompressed image, -T to de ne type of the image which is a script in our case.
Note that you can review details about any image using mkimage I <image_name>
in the host machine. Or in the target machine you can run iminfo in U-Boot prompt.
3.6.8.3 Boot Script Loading
We can run quickly this script in U-Boot prompt. First we have to load it into the FPGA
System RAM. To do that, you can load it over tftp
tftpboot 0 x12000 sample . scr
(Assuming that you have already set serverip and ipaddr variables)
Or if you would like to load it from SD card you can use
load mmc 0:1 0 x12000 sample . scr
(Assuming that your SD card is de ned at dev 0 - partition 1). 0x12000 is any temp
address.
To execute the loaded script then, simply use the following
source 0 x12000
Further enhancement can be applied by automating loading of the script le. This can
be done by assigning dynamic IP address for the chip using dhcp command. But rst we
need to de ne name of the script le by:
setenv bootfile sample . scr
saveenv
Then calling dhcp command will download the le automatically
dhcp
If you want to restore default environment values that you have already changed in last
steps, you can restore it by:
env default -a
saveenv
Then reboot the system directly.
Another simple alternative that we can use without changing environment variables is
to issue dhcp command with the le name that we need to fetch.
44
Chapter 3. Firmware 3.7. FileSystem
dhcp 0 x12000 sample . scr
where 0x12000 is RAM address to which the le will be loaded.
3.7 FileSystem
3.7.1 De nition
Every Embedded Linux system needs a root le system which includes all of the les needed
for the system to work. To boot a system, enough software and data must be present on
the root partition to mount other le systems. This includes utilities, con guration, boot
loader information, and other essential start-up data.
What is meant here by le system also is the entire hierarchy of directories that is used
to organize les on a computer system. This shouldn't make confusion with type of le
system storage on hard disks (FAT, ext2, ext3, ext4, etc).
When the bootloader loads and starts the kernel, the kernel will mount the target le
system and starts the init application.
Linux Foundation released what is called Filesystem Hierarchy Standard (FHS) which
de nes directory structure and contents in Linux distributions. It can be summarized as
in gure 3.27.
Figure 3.27: File System Structure
3.7.2 Building File System
This means to select les necessary for the system to run. There are minimum requirements
for any le system, to allow the system to function properly:
Init application shell C library Device Files proc sysfs.
45
Chapter 3. Firmware 3.7. FileSystem
Since these basic con gurations are important and may dier from a system to another,
a build tool can be used to create these basic components such as BusyBox.
3.7.2.1 Build Using Busybox
Busybox can be downloaded from
https://busybox.net/downloads/
or cloning using git by
$ git clone https :// git . busybox . net / busybox
After downloading, navigate to the downloaded directory. Before starting the build
operation, architecture of the target system and a cross compiler for it shall be de ned.
$ export ARCH = arm
$ export CROSS_COMPILE =/ path / to / your / CrossCompiler
$ make defconfig
$ make menuconfig
$ make
$ make install
This will result in a directory _install which contains the output of the build process
3.7.2.2 Build Using Buildroot
Although Busybox can help building minimal le system, however it will not result in
the needed directories that are shown in previous gure 3.27. Busybox will generate only
utilities that user chose contained in bin and sbin directories. The user still needs to add
other directories manually.
As an alternative, Buildroot can be used to prepare the needed le system as well
as needed utilities. In fact, Buildroot is using Busybox to generate needed utilities and
binaries. Not only but also Buildroot can be used to generate the entire Linux system
starting from bootloader, Linux kernel and the le system. Therefore build root is an
e cient tool that can be used to build the le system.
To use Buildroot, rst download it by
$ git clone https :// git . buildroot . net / buildroot
then browse to the downloaded directory
$ cd buildroot
If you have ready con guration le that can be used for your target, you can load it
using
$ make your_target_file_defconfig
You can add more changes to these con gurations or if you don't have ready con gu-
ration le, you can use menucon g to add your con guration
$ make menuconfig
46
Chapter 3. Firmware 3.7. FileSystem
Figure 3.28: Buildroot Menucon g
Important to make sure that you have the right Target options. Note also that for
ARM64 architecture, glibc can only be used as other C libraries is not supporting this
architecture [7].
Dierence between these libraries is in its implementation. For example malloc(0) in
glibc returns a valid pointer to something, while in uClibc calling malloc(0) returns a
NULL [8].
Figure 3.29: Buildroot Target Architecture
Then you can navigate through other options to choose other settings and utilities.
Save your con gurations then to start the build process. Cross Compiler is needed to be
de ned.
$ export CROSS_COMPILE =/ path / to / your / CrossCompiler
$ make
This building process takes about 40 minutes to nish According to your chosen pre-
ferences.
When nished, the generated image can be found in ./output/images/rootfs.tar which
is root le systems compressed as tar le. To install it, mount the root partition of the SD
card.
$ mkdir -p ./ temp_mnt
$ sudo mount / dev / sdb2 temp_mnt
then extract the compressed le in the mounted location
$ sudo tar - xpf rootfs . tar -C / path / to / mounted / location
Root File System is now ready.
47
Chapter 3. Firmware 3.7. FileSystem
Note:
During building the rootfs, downloading of linux header was corrupted as the source of the
linux (cdn.kernel.org) was not registered in locally veri ed URLs.
Con guration is set to use wget utility to download these linux headers. Luckily the
error can be demoted then by using the switch no-check-certi cate which turns o checking
if the link is secured or not. But where to add this switch then. This has to be done
in con guration le. So after loading con guration le (xilinx_zynqmp_defcon g for
instance), open the hidden le `.con g'. There is one parameter called BRE2_WGET.
Modify this parameter to be
BR2_WGET = wget passive-ftp no-check-certi cate -nd -t 3
Then you can build rootfs using make utility. Alternatively, you can use menucon g
to edit your preferences.
3.7.3 Buildroot Quick Guides
3.7.3.1 Add Overlays
User may need to add additional directory tree over the default created one. For example,
User may need to create home directory for another user. This can be done using overlays.
Simply you can create the additional needed directory tree and direct con guration of
Buildroot to add this tree by mentioning its path. This setting can be done in con guration
le as
BR2_ROOTFS_OVERLAY=/path/to/location/of/neededtree
Or using menucon g in section System Con guration>Root lesystem overlay direc-
tories.
3.7.3.2 Modify Using Post Script
Other modi cations in the generated le system may be needed that cannot be done before
building the system. For example assigning IP address for a network interface. This needs
then to add some con guration in interfaces le. Such modi cations can be scripted in an
external le to be ready for execution before root le system is assembled.
For example, assume that we need to con gure a network interface to acquire IP address
dynamically. A le called `interfaces' shall contain then the following lines
# interface file auto - generated by buildroot
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
In which we set interface eth0 to dynamically get IP address. Lets assume that this
le is stored in some place like external_mod/interfaces.
We need then to create the script that will run to replace this ready interfaces le with
the default one. Such a script could be like the following
48
Chapter 3. Firmware 3.7. FileSystem
# !/ bin / sh -e
FS_DIR = $1
cp / path / to / external_mod / interfaces $FS_DIR / etc / network / interfaces
In this script and according to Buildroot manual, "The path to the target lesystem
is passed as the rst argument to each script". That is why we use FS_DIR=$1 as the
rst command. Note that /path/to/external_mod can be relative to Buildroot main
directory.
In case you want to pass other arguments to these post scripts, write down these argu-
ments in a con g option called BR2_ROOTFS_POST_SCRIPT_ARGS. Note then that
rst argument by default is the path to target le system (i.e the image source directory that
will be created). So any other argument de ned in BR2_ROOTFS_POST_SCRIPT_ARGS
will have the second order (i.e when referring to it the post scripts, use $2, $3,..etc).
Remaining now to direct Buildroot to use this script before creating the le system
image. This can be done in con guration le using the following setting
BR2_ROOTFS_POST_BUILD_SCRIPT="../NetworkSettings.sh"
In which `NetworkSettings' is the name of the script that contains copying commands.
Alternatively, we can set it using menucon g window in section System Con guration >
Custom scripts to run before creating lesystem images.
If you want to use more than one post script, simply enlist them with space separated
in this eld.
3.7.3.3 Modify Using Patches
More sophisticated modi cations may be needed. For example, you may need to modify
a package that going to be installed in the root le system. So waiting until the package
is installed to change it is meaningless as you have to tweak it before it is installed. Such
a situation can be handled by preparing a patch le that contains what you are going to
change in the package settings les.
First you have to create a patch le with your changes. For example we will discuss
here how to enable ssh connection for our target system (as ssh server) before deploying
the root le system.
In `sshd_con g' le that is located in /etc/ssh, the following parameter should be set
to yes to order to allow access over ssh port
PermitRootLogin yes
By default when building root le system it will be disabled
# PermitRootLogin prohibit - password
The following patch le was then created to make this change in `sshd_con g' le
--- openssh / orig_sshd_config 2018 -07 -13 07:16:48.154494887 -0400
+++ openssh / sshd_config 2018 -07 -13 06:40:58.000000000 -0400
49
Chapter 3. Firmware 3.7. FileSystem
@@ -29 ,7 +29 ,7 @@
# Authentication :
# LoginGraceTime 2 m
-# PermitRootLogin prohibit - password
+ PermitRootLogin yes
# StrictModes yes
# MaxAuthTries 6
# MaxSessions 10
This le was created using `di ' command to get the patch le.
$ diff -u orig_sshd_config sshd_config > sshd . patch
Where orig_sshd_con g was obtained actually during early development phases of the
project.
Important to point out here is:
The patch le should be name as lename.patch, as Buildroot will use this extension
to apply the patch.
Also to direct Buildroot to apply this patch le to our target package, we need to
store this le in a directory with the same name of our package. So it should be
maintained at openssh/sshd.patch.
First two lines de nes where exactly to nd the target patched le in the package
source directory.
Lets assume now that this directory is located in a directory called external_mod. Re-
maining now to direct Buildroot to apply external patch le. In Buildroot con guration
le choose to enable ssh package
BR2_PACKAGE_OPENSSH=y
Or in menucon g Target packages > Networking applications > openssh.
We need to set the following parameter to indicate where to nd patch les
BR2_GLOBAL_PATCH_DIR=/path/to/external_mod
Alternatively, we can use menucon g in section Build options > global patch directories.
The patch should be applied then. If we have more than one patch to be applied to the
same package, we have to rename the patch les then to be in alphabetic order. For
example 001_sshd.patch then 002_sshd.patch.
3.7.3.4 Rebuild Packages
For quick modi cations in installed packages, developer may not need to rebuild the whole
le system for these quick modi cations. Instead, the target package binary can be only
rebuilt in Buildroot. This can be done using the following command
$ make package_name - rebuild
Where package_name is the binary that needed to be changed. In this case only the
resulted binary can replace the existing binary without the need to deploy the whole root
le system again.
50
Chapter 3. Firmware 3.7. FileSystem
3.7.3.5 Get Package from User Speci c Location
Normal operation of Buildroot is to download a package whenever it is speci ed to be
included in the build. Some Developers may prefer to use their version of the package. So
downloading the package is not entirely needed. In this case, we can use
<pkg_name>_OVERRIDE_SRCDIR
to direct Buildroot to use our package source. This con guration can be added in
main con guration le of Buildroot and we have to assign path to the package source to
it. Importance of this mechanism appears when we run make clean. The source will be
untouched and can be integrated any time we rebuild the root le system.
3.7.3.6 User Control During Build Process
Building the root le system is based mainly on building target packages. Buildroot while
building any package; is going through the following phases:
Download Extract Patch Con gure Build Install.
There are other phases that you can check in Buildroot user manual, but for simplicity
not all of them are mentioned here. Fortunately, developers can add some control in
between these phases. It is called hooks. In Buildroot there are two hooks for each phase,
Pre & Post. Using these hooks developers can de ne some actions to be executed before or
after the phase. To de ne at which package the hook shall be applied, Buildroot is using
the following format for any hook de nition
<PACKAGENAME>_<PREorPOST>_<PHASE>_HOOKS
The hook variable can be de ned in the package mk le (for each package de ned, it
has packagename.mk le in which we declare some information about con gurations and
build options for the package). Prior to de ning the hook variable, we have to de ne rst
(in mk le also) actions that shall be executed by at the hook point.
Define PACKAGENAME_DEVELOPER_ACTION_SET
echo " User specific configurations "
cp file1 file2
# ... other developer ' s actions
Endef
Then we assign these actions to the hook variable, for example:
OURPACKAGE_PRE_CONFIGURE_HOOKS += PACKAGENAME_DEVELOPER_ACTION_SET
Buildroot allows hooks variables for the following phases
PACKAGENAME_PRE_DOWNLOAD_HOOKS
PACKAGENAME_POST_DOWNLOAD_HOOKS
PACKAGENAME_PRE_EXTRACT_HOOKS
PACKAGENAME_POST_EXTRACT_HOOKS
PACKAGENAME_PRE_RSYNC_HOOKS
PACKAGENAME_POST_RSYNC_HOOKS
PACKAGENAME_PRE_PATCH_HOOKS
PACKAGENAME_POST_PATCH_HOOKS
51
Chapter 3. Firmware 3.7. FileSystem
PACKAGENAME_PRE_CONFIGURE_HOOKS
PACKAGENAME_POST_CONFIGURE_HOOKS
PACKAGENAME_PRE_BUILD_HOOKS
PACKAGENAME_POST_BUILD_HOOKS
PACKAGENAME_PRE_INSTALL_HOOKS (for host packages only)
PACKAGENAME_POST_INSTALL_HOOKS (for host packages only)
PACKAGENAME_PRE_INSTALL_STAGING_HOOKS (for target packages only)
PACKAGENAME_POST_INSTALL_STAGING_HOOKS (for target packages only)
PACKAGENAME_PRE_INSTALL_TARGET_HOOKS (for target packages only)
PACKAGENAME_POST_INSTALL_TARGET_HOOKS (for target packages only)
PACKAGENAME_PRE_INSTALL_IMAGES_HOOKS
PACKAGENAME_POST_INSTALL_IMAGES_HOOKS
PACKAGENAME_PRE_LEGAL_INFO_HOOKS
PACKAGENAME_POST_LEGAL_INFO_HOOKS
3.7.3.7 Format of Zipped Output
When using the result output to be loaded into system RAM directly, a cpio format is nee-
ded. i.e. a tar output can't be extracted into the system RAM. More details about the rea-
son is mentioned in this link. https://www.kernel.org/doc/Documentation/ lesystems/ramfs-
rootfs-initramfs.txt.
3.7.4 File System Location
Many O/S distributions use a small RAM disk as the initial root lesystem and the init
program will enumerate the devices and typically mount other lesystems.
Removable media: SD Card, USB, HDD.
On-board storage: Flash, RAM.
Network (NFS).
Prior to getting more details about these dierent locations, we have to understand rst
that natively a Linux system (or an operating system) can (and indeed) run on the system
RAM. In other words, Filesystems images that we can get from Buildroot or Busybox are
loaded into the system RAM. This is possible because Buildroot or Busybox are generating
minimal le system with the minimum needed binaries so that it can t into the system
RAM. This minimal Filesystem is called then Initial RAM Disk (initrd) or another type
called tmpfs.
This note was important to mention to give the idea that a Linux system can success-
fully run based on this minimized Filesystem (initrd or tmpfs). What is done next is Linux
is recognizing other attached devices and starts to mount it; the whole Filesystem will be
extended then.
Mounting a Filesystem means to attach this Filesystem to the original Filesystem. It
is simply can be thought like a tree; the original Filesystem (Root Filesystem) is already
52
Chapter 3. Firmware 3.8. Linux Kernel
started in system RAM then it will be connected to another Filesystem tree. The attached
Filesystem shall be organized also in the Root Filesystem; therefore we shall de ne a
location in the Root Filesystem tree. This location is called Mount Point through which
the additional Filesystem will be attached. For example when you attach a CDRom to the
system, one directory will be created in the Root Filesystem (usually /mnt/cdrom). This
created directory will be the root of the new attached CDRom and in the same time it acts
as part of the Root Filesystem. Mounting this CDRom doesn't mean that is loaded into the
system RAM also, it is only connected through the created Mount Point (/mnt/cdrom).
In Linux to review all attached Filesystems, this can be done using command df. While
in order to see how much space is occupied be the Root Filesystem in the RAM; this can
be checked using free command.
One more point to mention here also is; since initrd or tmpfs is running or located
in system RAM, it is lost after system is powered down. Whenever a Linux system is
starting, it needs to know location of the Root Filesystem Image. User can provide Root
Filesystem Image manually (using tftp methods as declared in U-Boot section). For stable
or After-production systems, Location of the Root Filesystem is given to the kernel by
de ning the argument root=. . . .
Based on these notes, we can easily understand that Linux system can start while the
nal Filesystem is located in another media (remote or attached).
3.8 Linux Kernel
Preparing the Linux kernel is quite simple. Xilinx has ready con guration le that can
be used to compile Linux kernel for Zynq devices. As quick declaration, the following
commands can be used to get a Linux kernel for ZynqMP. Only a cross compiler is needed
before running these commands.
$ git clone https :// github . com / Xilinx / linux - xlnx .
$ git cd linux - xlnx
$ make ARCH = arm64 xilinx_zynqmp_defconfig
$ make ARCH = arm64 - j4
The output will reside in arch/arm64/boot/
3.8.1 Kernel Image Forms
The resulting image from last step is uncompressed Linux Kernel Image. This is what is
supported by default for ZynqMP, other development areas refer to the resulting uncom-
pressed image as vmlinux. It is simply an elf le. Linux Kernel can be produced also as
compressed image called zImage. In this case we have to generate using
$ make zImage
But note that this is not supported for ZynqMP.
53
Chapter 3. Firmware 3.8. Linux Kernel
It can be also produced as uImage which is the compressed version of zImage prepended
by a U-boot header which is information for U-boot to recognize this uImage when booting.
To get uImage, we must have mkimage utility (obtained from U-Boot in its tools
directory). We have to add path to mkimage to PATH env. Variable then we can run the
following while compiling Linux image
$ make uImage LOADADDR =0 x80008000
The other way is to use mkimage separately to convert any linux image to uImage
$ mkimage -A arm64 -O linux -T kernel -C none -a 0 x80008000 -e 0 x80008000
-n " Linux kernel " -d arch / arm64 / boot / zImage uImage
It is important to note also that each form of these images is booted by dedicated boot
command in U-Boot. Uncompressed Image is booted using booti, zImage is booted using
zboot, uImage is booted using bootm.
3.8.2 Flattened Image Tree
Starting from last point where a Kernel image has been prepended with load address
information (uImage), this image looks as shown in gure3.30.
Figure 3.30: Kernel Image Structure [9]
In the same way, Device Tree le can be represented as an image, FileSystem can be
compressed into an image, FPGA bit le, U-Boot scripts, etc. It is useful then if there is a
way to include all the needed images in one image so that transferring and loading of the
image can be faster.
Flattened Image Tree can be used to build such an image. Its approach is similar Device
Tree le structure in which we describe each hardware as a node that contains other sub-
hardware nodes. In FIT image we describe each image as node and provide information
54
Chapter 3. Firmware 3.8. Linux Kernel
needed for each node. As a sample, the following FIT le is provided in U-Boot as a sample
of FIT image that includes a kernel an device tree
/*
* Simple U - Boot uImage source file containing a single kernel and FDT blob
*/
/ dts - v1 /;
/ {
description = " Simple image with single Linux kernel and FDT blob " ;
# address - cells = <1 >;
images {
kernel@1 {
description = " Vanilla Linux kernel " ;
data = / incbin /( " ./ vmlinux . bin . gz " ) ;
type = " kernel " ;
arch = " ppc " ;
os = " linux " ;
compression = " gzip " ;
load = <00000000 >;
entry = <00000000 >;
hash@1 {
algo = " crc32 " ;
};
hash@2 {
algo = " sha1 " ;
};
};
fdt@1 {
description = " Flattened Device Tree blob " ;
data = / incbin /( " ./ target . dtb " ) ;
type = " flat_dt " ;
arch = " ppc " ;
compression = " none " ;
hash@1 {
algo = " crc32 " ;
};
hash@2 {
algo = " sha1 " ;
};
};
};
configurations {
default = " conf@1 " ;
conf@1 {
description = " Boot Linux kernel with FDT blob " ;
kernel = " kernel@1 ";
fdt = " fdt@1 " ;
};
};
55
Chapter 3. Firmware 3.8. Linux Kernel
};
So we can prepare images that we need in such a description, save it as .its le, create
the t image using mkimage utility
$ mkimage -f userImages . its all_images . itb
Then this .itb le can be transferred into system RAM to be loaded simply using
bootm command. Recall from last section that bootm is used to boot images with U-
Boot header. Note here that Linux kernel used to create this FIT image shall be uImage.
More details about working with FIT image can be found in U-Boot directory under
doc>>uImage.FIT. What can be interesting to mention here is we can prepare two or
more FIT images and transfer it to the system RAM, then we can pick a combination of
rst FIT kernel with second FIT device tree to boot. We can do that when calling bootm
bootm 20000: kernel@1 25000: filesystem@2 30000: fdt@3
Where 20000, 25000, 30000 are addresses of the FIT in the system RAM. We can also
choose to boot using kernel and device tree (for example) as follows
bootm 20000: kernel@1 - 30000: fdt@3
Where the space for the le system has been speci ed - to tell U-Boot to discard it.
Important to note then when loading the all_images.itb, bootargs environment va-
riable shall be correctly de ned. Otherwise kernel will fail to load as no arguments have
been passed to him. To set bootargs simply using the following
setenv bootargs << user_args > >
Where user_args can be for example
console=ttyPS0,115200 rw earlyprintk rootwait root=/dev/mmcblk1p2
Another important point is to choose load and entry address of the kernel not to
overwrite other loaded images. For resolving some issues that may face you when starting
working with FIT image, you may need to load it, extract it manually to debug behavior.
To extract it manually
imxtract 0 x10000000 kernel@1 0 x06000000
Where 0x10000000 is address where FIT image has been loaded, 0x06000000 is the
address to which you want to load the kernel image. Same can be executed for fdt
imxtract 0 x10000000 fdt@1 0 x06e00000
then if successful, you can try to load the extracted images
bootm 0 x06000000 - 0 x06e00000
56
Chapter 3. Firmware 3.9. Boot Image
3.9 Boot Image
3.9.1 Input Files
All previously generated les (FSBL, ATF, PMU, Bitstream, Linux Image, UBoot, FileSy-
stem)
3.9.2 Output Files
Boot.bin
3.9.3 Tools
SDK (GUI) or Bootgen (command line).
3.9.4 Procedure Using Command Line
3.9.4.1 Create BIF le
You need to create con guration le in Boot Image Format (*.BIF). The BIF le lists the
input les to the boot image, along with optional attributes for addressing and optional
encryption, authentication or checksums.
To write this le manually, you can add like the following lines
Figure 3.31: BIF File, Windows Path
Note that here in this Figure 3.31, paths to elf les are speci ed according to windows
format (with backslash). In case of Linux Operation Systems, these path shall be modi ed
with slash (/).
For more information about available attributes that can be used within BIF le you
can type
exec bootgen - bif_help
to get detailed view
57
Chapter 3. Firmware 3.9. Boot Image
Figure 3.32: BIF File Options
After completing the BIF le, you can generate boot image using bootgen command
bootgen - image sd_boot . bif - arch zynqmp -w -o C :\ BOOT . bin
3.9.5 Procedure Using SDK
Open SDK
Choose Workspace
58
Chapter 3. Firmware 3.9. Boot Image
Figure 3.33: SDK Workspace [1]
Figure 3.34: SDK Start Window [1]
Open Xilinx >> Create Boot Image
In Architecture, choose Zynq MP
59
Chapter 3. Firmware 3.10. Boot Media
Figure 3.35: Create Boot Image [1]
In Output BIF File path browse to choose location of output les. Output path eld
will be updated accordingly. Then in Boot image partitions space click Add button to add
your input les.
Click on Create Image button. BOOT.bin le shall be generated successfully in your
output directory.
3.10 Boot Media
In order for the system to boot, created images (Kernel, File System, Device tree) shall be
loaded into processing system RAM to start operation. To pass (or to load) these images
into the RAM, the following approaches can be used.
60
Chapter 3. Firmware 3.10. Boot Media
3.10.1 Boot Through TFTP Server
This kind of connection allows transferring les between remote machine (tftp server) to
a client machine. This method is then useful to have a centric booting les that can be
deployed into cluster of FPGAs that need same booting les. Each FPGA will need to
have its own rst booting le stored internally, then this rst booting le direct the boot
sequence to get other booting les (Linux Kernel, Device tree, File System image) from
the tftp server. Typical sequence can be like that
- Uboot is installed internally in the FPGA to start up after powering up the
FPGA.
- Uboot is con gured to read external boot script to follow instructions mention
in that boot script.
- Booting script itself can be self-updated from the tftp server.
- Kernel, Device Tree, File System are described in the booting script how to be
fetched as described in the following script example
setenv kernel_img_name " Image "
setenv kernel_loadaddr 0 x6000000
setenv rootfs_img_name " rootfs . cpio . uboot "
setenv rootfs_loadaddr 0 x10000000
setenv dtb_img_name " devicetree . dtb "
setenv dtb_loadaddr 0 x6e00000
tftpboot $kernel_loadaddr $kernel_img_name ;
tftpboot $rootfs_loadaddr $rootfs_img_name ;
tftpboot $dtb_loadaddr $dtb_img_name ;
booti $kernel_loadaddr $rootfs_loadaddr $dtb_loadaddr ;
3.10.2 Boot Through SD Card
SD card can be used to contain the necessary booting les, these les are loaded eventually
to processing system RAM. When booting from SD card is chosen, Boot.bin le is rst
loaded then it starts to search for other boot les (Kernel Image, Devicetree, Filesystem)
in SD card in order to load it into system RAM.
3.10.2.1 SD Card Partitioning
If the SD card is going to be used as the boot medium, it has to be prepared to contain
booting les and root le system. Booting les are les used to boot the system like
boot.bin, Linux Image. Root le system is the directory structure of your linux system.
Best way to do that is to make partitioning for the SD card so that it is formatted to have
one partition for boot les and another partition for root le system.
61
Chapter 3. Firmware 3.10. Boot Media
In linux, partitioning the SD card can be performed using fdisk utility. The following
script can be used for partitioning
# ! / bin / sh -e
dd if =/ dev / zero of =/ dev / sdb bs =1024 count =1
(
echo x
echo h
echo 255
echo s
echo 63
echo c
echo
echo r
echo n
echo p
echo 1
echo 2048
echo +400 M
echo n
echo p
echo 2
echo
echo
echo a
echo 1
echo t
echo 1
echo c
echo t
echo 2
echo 83
echo p
echo " w "
) | fdisk / dev / sdb
sudo mkfs . vfat -F 32 -n boot / dev / sdb1
sudo mkfs . ext4 -L root / dev / sdb2
echo " please reboot ............................. "
3.10.3 Booting Through QSPI
As a ash based storage system, this kind of memory can be used to store booting les.
QSPI will be connected to the FPGA and con guration of the platform board will be set
to load boot le from this QSPI.
Best practice to use QSPI, is to partition it to several partitions ( ve or six) allowing
to store each boot le in a dedicated partition.
62
Chapter 3. Firmware 3.10. Boot Media
3.10.3.1 QSPI Partitioning
Partitions of the QSPI are set through the device tree le. U-Boot is referring to the device
tree le when writing to the QSPI. For example, the following is de ned in default device
tree of Xilinx ZynqMP.
Figure 3.36: QSPI Partitions in Device Tree
Which depicts four partitions at addresses (0x0, 0x100000, 0x600000, 0x620000) and
they are named (planned) for Uboot, Kernel, Devicetree and Filesystem respectively. The
other value in reg parameter denotes the size of the partition.
Now in order to partition the QSPI, First step is specify the system RAM address where
DTB le is stored (this means we need to load our device tree into the RAM rst our
device tree means not the default U-Boot device tree). In U-boot to specify the address
of DTB le use the following command
fdt addr < DTB_addr >
If you want to change the partitions, you can use the following command
fdt set / amba / spi@ff0f0000 / flash@0 / partition@qspi - linux reg <0 x00000000 $ {
bootimage_size } >
The general form of fdt set is
fdt set < path > < prop > [ < val >]
[10]
So what we have done is, we have change the property reg of the linux partition
de ned as the shown path to a new value.
63
Chapter 3. Firmware 3.10. Boot Media
3.10.3.2 Writing on QSPI
For writing to the QSPI for the rst time, you need external aid to boot from so that you
can load rst boot le into QSPI. Usually SD card is used for that and through U-boot
prompt. To write into QSPI, when U-boot prompt is up type the following command to
scan for the connected QSPI
sf probe
Boot les that are needed to be stored in the QSPI, shall be transferred from the
system RAM. This is actually the available way in U-boot to write into the QSPI as it
is not possible to write from the SD card. SD card is used only to bring up a working
U-boot. This means that boot les have to be written rst into the RAM, then write each
boot le in its planned partition of the QSPI.
For loading boot les into system RAM, the usual way then is tftp. The following
commands can be then issued in U-boot prompt to write to the QSPI
setenv autoload no
dhcp
setenv boot_img BOOT . BIN
setenv boot_img_addr 0 x140000
setenv kernel_img_name " Image "
setenv kernel_loadaddr 0 x6000000
setenv dtb_img_name " devicetree . dtb "
setenv dtb_loadaddr 0 x6e00000
# mw is used to initialize the memory with '1 '
# 0 x2faf080 is estimation for the boot file size (50 MB )
# 0 xe4e1c0 is estimation for the kernel file size (15 MB )
# 0 xc350 is estimation for the device tree file size (50 KB )
mw . b $boot_img_addr 0 xff 0 x2faf080
mw . b $kernel_loadaddr 0 xff 0 xe4e1c0
mw . b $dtb_loadaddr 0 xff 0 xc350
tftpboot $boot_img_addr $boot_img
tftpboot $kernel_loadaddr $kernel_img_name
tftpboot $dtb_loadaddr $dtb_img_name
As just mentioned, next is to write each of the loaded le into its dedicated partition.
Assume now the following partitions are initialized in the QSPI.
64
Chapter 3. Firmware 3.10. Boot Media
Figure 3.37: QSPI Memory Partitions
Start address of each partition is denoted in U-boot as oset. So for writing into the
right partition we have to mention its oset in the command. The following commands
can be used then
sf update $boot_img_addr 0 x040000 0 x2faf080
sf update $kernel_loadaddr 0 x1e0000 0 xe4e1c0
sf update $dtb_loadaddr 0 x140000 0 xc350
Previous commands were written in the shown order for declaration purposes. In fact,
we should use it like the following
tftpboot $boot_img_addr $boot_img
sf update $boot_img_addr 0 x040000 $filesize
tftpboot $kernel_loadaddr $kernel_img_name
sf update $kernel_loadaddr 0 x1e0000 $filesize
tftpboot $dtb_loadaddr $dtb_img_name
sf update $dtb_loadaddr 0 x140000 $filesize
The dierence is in lesize variable which gets automatically the size of the loaded
le, so that we can use it to write the exact size into the QSPI memory.
Booting from the QSPI then in subsequent operations (i.e. after QSPI has been written
with boot les) can be using sf read command, for example
sf read $fdt_addr $fdt_offset $fdt_size
sf read $kernel_addr $kernel_offset $kernel_size
in which we read de ned size from the de ned oset of the QSPI into the de ned
address of the RAM.
65
Chapter 3. Firmware 3.10. Boot Media
3.10.4 Booting During Development Phases
As the system is not going to work from the rst time, or at least many modi cations may
be applied, removing and inserting SD card to update booting les may not be practical ap-
proach. The more convenient approach is to have FPGA under development in connection
with the development machine then transfer new updated les to replace old ones.
At this point, we have to distinguish between development les. For the case of appli-
cations running on the operating system, replacing the les while the system is running
will be an easy task as the compiled binaries of the application will be only replaced (to
some extended this is true).
3.10.4.1 Replacing Kernel, DTB, Filesystem Images
Other development les like Kernel Image, File System Image and Device tree still can be
replaced but with the need of rebooting the system to let it boot with these new modi ed
les. What is intended here is to keep system under connection with the development
machine and nd a way to update any of the booting les (like Kernel Image or File
System Image or Device tree). This can be done by rebooting the system normally but
halting it at u-boot stage. At this stage we can load modi ed les directly to the RAM
using tftp.
To make this approach easier to use, it is recommended to con gure u-boot to get
loading instructions from external le. This external le is just a script written for U-Boot
environment which is discussed previously in U-Boot section.
3.10.4.2 Replacing Boot File
U-boot and FSBL will be also modi ed frequently during development phases. Replacing
the old les can't be performed directly. Instead, modi ed boot le will be stored tempo-
rarily in the system RAM, then we can replace and overwrite the old boot le from the
temporarily location.
3.10.5 Loading Bitstream File
For designs that are using PL part of ZynqMP, a bitstream le is needed to be downloaded
into the processor RAM which will program the PL part accordingly.
Normal or traditional way is to built-in the bitstream le into the boot le while creating
it. Boot le is created using Xilinx tools (bootgen utility for instance) as described in
previous section (Boot Image Generation) in which we list the bitstream le in BIF le to
be included while creating boot.bin le. The bitstream le is then loaded into the FPGA
when FSBL is loaded.
Another way is to load the bitstream le is through Linux operating system which is
running already on the Processing System of ZynqMP. Xilinx provides one driver that can
handle programming the PL part. This driver can be accessed through sysfs of Linux.
Initial setting shall be performed rst which is to represent the bitstream le (which is .bit
le) into binary le (.bin le). Again Xilinx bootgen tool can be used for that as follows
66
Chapter 3. Firmware 3.10. Boot Media
bootgen - image bitstream . bif - arch zynqmp - process_bitstream bin
Where bitstream.bif is a BIF le which shall contain the following
all : {
[ destination_device = pl ] bitstream . bit
}
Executing bootgen will result then in bistream.bit.bin le. After this setting, The
generated bin le shall be stored exactly in a path like the following
/lib/ rmware/bitstream.bit.bin
This Xilinx driver is using this path to identify the target bitstream les. Last step is
to execute the following commands
$ echo 0 > / sys / class / fpga_manager / fpga0 / flags
$ echo bitstream . bit . bin > / sys / class / fpga_manager / fpga0 / firmware
[11]
Another possible way of loading the bitstream le is to use U-boot for that. U-Boot has
fpga command that can be used to program the attached PL. In this case the bitstream
le has to be represented into binary le also as described previously. The command to
use then in U-boot is as follows
fpga load 0 $fpga_loadaddr $filesize
where 0 is number of FPGA device.
67
Chapter 4
Software
Controlling processing system and its attached devices can be achieved mainly through
Operating Systems or Bare-Metal applications. In both cases, the developer has to de ne
some rmware that directs running software for how to work with and control the attached
hardware device. This rmware is what we call a driver for the device and it is what we
need to build in the path between hardware interface and end user interface.
4.1 Linux Drivers
In case of Linux system, the path between user and the hardware starts at the user side in
which we need to have simple and easy to use program or application to work with. This
application is communicating with device drivers that reside in the kernel space. Then the
kernel layer comes afterward to provide mechanisms and rmware drivers of the hardware.
End of this path is at the hardware interface which is seen by the kernel using the device
tree le.
Since the hardware devices dier in functionality, properties and attributes, the driver
shall be tailored to deal with this device. Device properties shall be communicated correctly
between hardware developers and drivers developers. For the case of FPGA development,
it can happen that hardware developer needs to build the hardware logic and its driver.
The following guide may help then to clarify how to build driver in Linux kernel.
We can start by simple `hello world' example to have an idea how a kernel module or
driver can be built. This example is based on Xilinx ZynqMP chip.
4.1.1 Build and Run Linux Kernel
First, Linux kernel is needed in order to compile the module. Linux kernel for Xilinx can
be downloaded by
$ git clone https :// github . com / Xilinx / linux - xlnx . git
After downloading this kernel and building it, make sure that it can successfully run
on your Xilinx Zynq.
68
Chapter 4. Software 4.1. Linux Drivers
4.1.2 Create Module
Simple `Hello World' module can be built using the following C code
# include < linux / init .h >
# include < linux / module .h >
static int hello_init ( void ) {
printk ( " Hello , ZynqMP world !\ n " ) ;
return 0;
}
static void hello_exit ( void ) {
printk ( " Goodbye , ZynqMP world !\ n " ) ;
}
module_init ( hello_init ) ;
module_exit ( hello_exit ) ;
MODULE_LICENSE ( " GPL " ) ;
MODULE_AUTHOR ( " FPGA Developer " );
MODULE_DESCRIPTION ( " \" Hello , Zynq world !\" minimal module " ) ;
MODULE_VERSION ( " printk ") ;
This module is based on basic entry and exit functions (hello_init & hello_exit) which
are called by module_init & module_exit respectively. module_init & module_exit are
invoked automatically when the module is installed in Linux kernel and they are de ned
in module.h header.
4.1.3 Build Module
To compile and build the module, a Make le will be used for that. First you have to take
into account that this module is built for the Linux running on Xilinx Zynq chip. So kernel
source of this Linux has to be pointed to. The following Make le can be used to build the
kernel
obj - m := hello_printk . o
PWD := $ ( shell pwd )
all :
$ ( MAKE ) -C $ ( KERNEL ) M = $ ( PWD ) modules
clean :
$ ( MAKE ) -C $ ( KERNEL ) M = $ ( PWD ) clean
When running this Make le it should be executed as
$ make ARCH = arm64 KERNEL =/ path / to / built / kernel CROSS_COMPILE =/ path / to /
CrossCompiler
The following shell script can be easily used for doing everything
# ! / bin / sh -e
export Current_Dir = $PWD
export CROSS_COMPILE =/ path / to / CRS_COMP / aarch64 - linux / bin / aarch64 - linux - gnu -
69
Chapter 4. Software 4.2. Linux Drivers Chain
export KERNEL =/ path / to / Linux / build
export Mod_Dir =/ path / to / module / hello_example /
cd $Mod_Dir
make ARCH = arm64
cd $Current_Dir
4.1.4 Running Module
Build process will result in hello_printk.ko le. Copy this le into the SD card containing
booting les and start the system.
To install the module use insmod command. To remove it use rmmod. To see list of
available modules use lsmod command.
Figure 4.1: Installing Linux Module
If printk output is not displayed, try to use dmesg | grep world command.
4.2 Linux Drivers Chain
Previous steps are basic steps followed for having a kernel module. Because previous
example has printed simple message for the user, it is not connected to any hardware
device yet. Still we need to clarify the case of a module interacting with attached hardware
devices. In this case, there is a chain of libraries and functions that are used to create the
module. In order to organize and represent these libraries and functions, we will represent
the kernel module in form of chain of devices and drivers as shown in gure 4.2 then we
will elaborate more about each part.
70
Chapter 4. Software 4.2. Linux Drivers Chain
Figure 4.2: Linux Driver Chain
This gure is a trial for simplifying basic steps needed to build a Linux driver. In fact
there are no references or resources mentioning a `Kernel Device' and a `User Device' for
instance. But there is what is called `Platform Device'. So the author used this illustration
to organize many drivers declarations.
What can be indicated in this gure is that there are User Space and Kernel Space in
Linux system. As its name re ects, User Space is the place where is user can access his
own functions. User is not allowed to access functions de ned in Kernel Space. There are
some speci c functions that can be used to handle interactions between both spaces that
will be declared later.
Figure 4.2 indicates also that a Linux driver is built as a chain of entities. Each entity
is bound with the other with a keyword or attribute so user application can access the
hardware device through this chain using speci ed keyword between each entity.
4.2.1 Platform Hardware Link
Device tree is the le describing attached hardware in the running system. Linux kernel is
using this le to get some information about these attached hardware devices like registered
address, width of input bus and some other parameters. One of these parameters is the
compatible parameter. It is developer de ned string to mark the hardware. Kernel
developer is using this string also to de ne a Platform Device. Linux kernel provides
of_device_id structure which can be used to store data about the hardware device. It is
71
Chapter 4. Software 4.2. Linux Drivers Chain
de ned in /include/linux/mod_devicetable.h as follows
/*
* Struct used for matching a device
*/
struct of_device_id {
char name [32];
char type [32];
char compatible [128];
# ifdef __KERNEL__
void * data ;
# else
kernel_ulong_t data ;
# endif
};
What is shown in this structure that it is designed to contain strings and data about the
device. Usually, most of developers are using only compatible parameter to match it with
the compatible parameter de ned in the device tree le. Both compatible parameters
shall have the same value, otherwise kernel will fail to match them. As a sample of how
this of_device_id is de ned, see the following example
Static const struct of_device_id User_IO_HW [] = {
{. compatible = " xlnx , user_IO " } ,
{}
};
MODULE_DEVICE_TABLE ( of , User_IO_HW ) ;
The platform is de ned here as array of type of_device_id without de ning the size
of the array. This is usual approach for de ning platform device to allow developer to link
as much hardware devices as he wants to this platform device. Eventually, this structure
shall be terminated with a null member {}. One important function shall be used in
the driver is MODULE_DEVICE_TABLE which is performing the matching between
de ned platform device and available hardware devices.
Once platform device is de ned, it needs platform driver to drive it. Using linux/plat-
form_device.h we can build this driver using structure platform_driver in which we can
de ne what functions shall be executed when the device is detected (probe function), what
shall be executed when device is removed (remove function) and some other details about
the driver. The following is an example of the platform driver.
static struct platform_driver User_plfrm_drv = {
. probe = gpio_probe ,
. remove = gpio_remove ,
. driver = {
. name = " userA_driver " ,
. owner = THIS_MODULE , // this macro is defined in module .h
. of_match_table = id User_IO_HW ,
},
};
72
Chapter 4. Software 4.2. Linux Drivers Chain
Name of the platform driver in this example is userA_driver, when linux runs this name
can be found in /sys/bus/platform/drivers. It is optional to de ne the owner property
but it is important to set value of of_match_table to the name of the platform device as
this is how the platform driver is bound with the platform device. Platform drivers need to
be registered after it have been de ned. This can be done using platform_driver_register.
4.2.2 Kernel Platform Link
Upon detection of the hardware device and de ning its corresponding platform device, this
device needs to be registered in the kernel. It is like make an existence for the device
in the kernel. This registration can be done using several functions or at dierent steps.
For instance the device registration can be called immediately when the device is detected
(de ne it in probe function), or it can be de ned upon module installation (de ne it in
init function). This is because this registration step is independent actually on the device.
You can even register a device that doesn't actually exist. This is possible as long as
you perform valid operations on the registered device. In Linux, devices are classi ed as
Block devices or Character devices. Block devices simply are devices built for storage
purposes. Character devices are devices handling IO streaming. Therefore, there are many
functions to register the device according to its type. For instance there are alloc_chrdev,
alloc_netdev, register_blkdev, register_chrdev, etc. For example here we use function
register_chrdev for illustration.
regdev_ret = register_chrdev (89 , " Dev_Name " , & gpio_fops ) ;
This function takes three arguments; rst one is called Major Number which will be
discussed soon. In this example it is chosen 89. Second argument is a name for the device.
Developer is free to choose any name since it is not bound to other objects in the module.
Third argument is a name of a structure used for building the kernel driver. Upon success,
this function will return 0.
Kernel Driver means here a set of functions used to perform necessary operations on
the device. This set of functions is de ned using structure le_operations type which is
de ned in linux/fs.h. For example the following structure de nes basic operations that can
be done on the device.
struct file_operations fops = {
read : device_read ,
write : device_write ,
open : device_open ,
release : device_release
};
Which are open, read, write and close. This is because everything in Linux is de ned
as les, so using this structure we can tell the kernel what to do when he opens, reads,
writes or closes the device. Developer has to de ne these functions and describe what shall
be executed when these functions are called.
Needed setting and con guration in kernel space will be ready if previous entities were
de ned correctly. Remaining now to make some preparations in user space. The device has
73
Chapter 4. Software 4.2. Linux Drivers Chain
to be instantiated also in user space. This is important as the nal user space application
should be in contact with a device. Devices in /dev directory are built for that purpose.
We can instantiate our device then in user space using mknod command if the device has
not been instantiated automatically by Linux.
So if the device has not been instantiated, display the le /proc/devices then nd the
Major Number that you have used while registering the kernel device. Beside this number
you can nd the name of the device as de ned in the kernel device (lets assume it is
Dev_Name). Use the following command to instantiate the device.
mknod / dev / Dev_Name -c 89 0
This mknod command will instantiate the device at /dev directory with the name
Dev_Name. The switch c directs the command to instantiate it as a character device. 89
is the Major Number assigned to the device in the kernel space. 0 is the Minor Number of
the device.
4.2.3 Major Number
It is a number used by driver developer to identify which device is associated with the
driver as shown in previous declaration. If the driver is managing dierent devices, there is
what is called Minor Number which is used to dierentiate between those dierent devices
that are driven with one driver. It is not commonly used.
Now it comes the point, how to pick a Major Number to assign it to the registered
device. There is one possibility when registering the device that we can register it dyna-
mically. This means that we can let the kernel allocates this number based on available
numbers. In this way we can avoid having con ict with another used Major Number. The
dynamic allocation is performed when registering the device with Major Number 0. For
example to be as follows
regdev_ret = register_chrdev (0 , " Dev_Name " , & gpio_fops ) ;
The return value of this dynamic allocation will be the assigned Major Number. If you
want to unregister the device in the driver code you can use the generate number.
unregister_chrdev ( regdev_ret , " Dev_Name " ) ;
If you used dynamic allocation, you can't search for the registered device then in le
/proc/devices with the Major Number as you don't know which number the kernel has
generated. In this case you can search for it using the de ned name (Dev_Name for
instance). You can use a script like the following to get this number
# !/ bin / sh -e
ModuleName = " UserMod "
MajorNum = $ ( awk ' $2 ~ / '" $ModuleName " '/ { print $1 } ' / proc / devices )
mknod / dev / $ModuleName c $MajorNum 0
74
Chapter 4. Software 4.2. Linux Drivers Chain
4.2.4 User Driver
So far, device has been recognized, registered and instantiated. Remaining now to build a
User Driver that can handle user commands and transfer it through kernel driver to kernel
space which will be executed then through platform driver in the platform device. User
has no access to kernel space and functions, therefore there are special functions that can
receive user commands and transfer it to kernel space. To use these functions, we have to
be aware rst that user can handle the instantiated device in Linux as a le. There is a
direct mapping in Linux between le operations in user space and struct le_operations
de ned in the Kernel Driver. This means using if user opened the device le in user space,
the open function of the struct le_operations will be called. Closing the le, the release
function will be called. Writing to the le, the write function will be called. Reading from
the le, the read function will be called.
In user space, to build the driver then we use standard fopen, fwrite, fread, fclose
functions. The struct le_operations is de ned as follows in Linux
struct file_operations {
struct module * owner ;
loff_t (* llseek ) ( struct file * , loff_t , int ) ;
ssize_t (* read ) ( struct file * , char * , size_t , loff_t *) ;
ssize_t (* write ) ( struct file * , const char * , size_t , loff_t *) ;
int (* readdir ) ( struct file * , void *, filldir_t ) ;
unsigned int (* poll ) ( struct file * , struct poll_table_struct *) ;
int (* ioctl ) ( struct inode * , struct file * , unsigned int , unsigned
long ) ;
int (* mmap ) ( struct file * , struct vm_area_struct *) ;
int (* open ) ( struct inode * , struct file *) ;
int (* flush ) ( struct file *) ;
int (* release ) ( struct inode * , struct file *) ;
int (* fsync ) ( struct file * , struct dentry * , int datasync ) ;
int (* fasync ) ( int , struct file * , int ) ;
int (* lock ) ( struct file * , int , struct file_lock *) ;
ssize_t (* readv ) ( struct file * , const struct iovec * , unsigned long
, loff_t *) ;
ssize_t (* writev ) ( struct file * , const struct iovec * , unsigned
long , loff_t *) ;
};
As shown, the write function for example shall be de ned in this form
ssize_t (* write ) ( struct file * , const char * , size_t , loff_t *) ;
where rst argument is pointer to user le that is opened and written to. Second
argument is pointer to the string has be written in the le. Third argument is how many
bytes shall be taken from the written string. Fourth argument is the oset to start take
the bytes. The user in kernel driver has to de ne a write function that tells the kernel
what to do when user space writes to the le. To clarify it more assume the following write
function de ned in Kernel Driver
ssize_t gpio_set
75
Chapter 4. Software 4.2. Linux Drivers Chain
( struct file * filep , const char * buf , size_t count , loff_t * f_pos )
{
printk ( " GPIO Kernel Driver : User has written some value \ n "
);
}
In the Kernel Driver also the struct le_operations shall be de ned in something like
the following
struct file_operations gpio_fops = {
read : gpio_get ,
write : gpio_set ,
open : gpio_open ,
release : gpio_close
};
As mentioned before, User has no access to kernel space. We have seen the mapping
between le operations in user space and kernel space. Remaining now to understand how
to get the value that user has written or send to user value recorded by the device. There
are special functions that transfer needed values between user space and kernel space.
These functions are de ned in the library asm/uaccess.h. In this library you nd some
functions like copy_from_user, copy_to_user, put_user, strncpy_from_user, etc. Using
these functions, we can transfer the content of the device le to/from user space. Assume
the following example for the write function in Kernel Driver.
ssize_t gpio_set
( struct file * filep , const char * buf , size_t count , loff_t * f_pos )
{
int user_value ;
printk ( " GPIO Kernel Driver : User has written some value \ n "
);
copy_from_user (& user_value , buf , count ) ;
printk ( " GPIO Kernel Driver : user has written % c \ n " ,
user_value ) ;
}
If the user has de ned the following User Driver
FILE * wr_d ;
char Letter = 'A ';
wr_d = fopen ( " / dev / Dev_Name " , " w " ) ;
fwrite (& Letter , 1 , 1 , wr_d ) ;
fclose ( wr_d ) ;
The result of the Kernel Driver then shall be:
GPIO Kernel Driver : User has written some value
GPIO Kernel Driver : user has written A
Figure 4.3 depicts the mapping between User Driver and Kernel Driver to clarify it
more.
76
Chapter 4. Software 4.3. Driver Integration
Figure 4.3: Kernel Driver Mapping
4.3 Driver Integration
Now that we have the driver is ready and has been tested manually (using insmod). Kno-
wing how to include this driver in the nal system is next step that we have to learn. To
integrate your driver with the running Linux, there are two approaches; either integrating
it with Linux Kernel source les or integrate it with Filesystem as Buildroot package.
4.3.1 Integration with Kernel Image
Linux Kernel source le has one directory for including drivers; it is drivers. All what
we need is to prepare our driver along with its Make le and Kcon g le, then indicate in
the Make le and Kcon g les of drivers directory to include our driver during Kernel
compilation process. Make le of the driver shall contain the following line
obj - $ ( CONFIG_OUR_GPIO ) += < driver_file_name >. o
Kcon g of the driver shall contain the following
config OUR_GPIO
tristate " Our driver for GPIO peripheral "
help
77
Chapter 4. Software 4.4. GPIO Driver
my driver module .
Tristate means that the con guration eld can be marked as y yes, n no, m mo-
dularize. Choosing no means driver will not be compiled, y means it will be compiled, m
means it will be compiled but as a separate module. i.e. not included in the nal kernel
Image. As alternative, we can de ne the con guration eld as Boolean which take only
two values y or n
bool " enable our GPIO driver "
default y
We can then de ne default value for the con guration as declared. These three les shall
be included then in one directory for instance our_driver <Linux_Source_dir>/drivers/<our_driver>.
Next, in drivers directory we need to mention that there is new driver shall be ready
for compilation. Open <Linux_Source_dir>/drivers/Make le then add the following line
at end of le
obj - $ ( CONFIG_OUR_GPIO ) += our_driver /
Then open <Linux_Source_dir>/drivers/Kcon g and add the following line before
endmenu
source " drivers / our_ driver / Kconfig "
The driver is now ready for compilation. Before starting main kernel compilation, you
can choose to include this driver with the kernel or not. This can be performed using
menucon g interface or insert CONFIG_OUR_DRIVER=y in the loaded con guration
le (***_defcon g ). Note that if the driver con guration le is de ned as tristate, here
you can set CONFIG_OUR_DRIVER to y or n or m.
4.4 GPIO Driver
There are many techniques to deal with the GPIO devices in Linux. Three of them are
discussed here.
4.4.1 Using sysfs
Since everything in Linux is handled as a le, sysfs is a mechanism that is representing
attached hardware devices as les for the user in order to control it. Sysfs can be considered
as a le system that is mounted automatically (in most linux systems) by the kernel. This
sysfs represents attached devices in form of les which means, it exports these devices
from the binary representation in the kernel into the user interface in order to view and
manipulate it. Figure 4.4 shows mainly the directory structure of sysfs. At the top level of
the sysfs mount point are a number of directories. These directories represent the major
subsystems that are registered with sysfs. These directories are created at system startup
when the subsystems register themselves with the kobject core.
78
Chapter 4. Software 4.4. GPIO Driver
Figure 4.4: Sysfs Structure [12]
The block directory contains subdirectories for each block device that has been dis-
covered in the system. The bus directory contains subdirectories for each physical bus
type that has support registered in the kernel (either statically compiled or loaded via a
module).
The class directory contains representations of every device class that is registered with
the kernel. A device class describes a functional type of device. For example gure 4.5
shows content of class directory, you can nd then that all registered devices are gathered
here according to its functions (block, gpio, graphics, power_supply, tty, etc). Contents of
this directory are symbolic link to its location in the devices directory.
Figure 4.5: Sysfs Class Directory
The Devices directory contains the global device hierarchy. This contains every physical
device that has been discovered by the bus types registered with the kernel. There are two
types of devices that are exceptions to this representation: platform devices and system
devices. Platform devices are peripheral devices that are inherent to a particular platform.
They usually have some I/O ports, or MMIO, that exists at a known, xed location.
Examples of platform devices are GPIO controllers, Serial controllers. System devices are
non-peripheral devices that are integral components of the system. In many ways, they are
nothing like any other device. Examples of system devices are CPUs, APICs, and timers.
To use sysfs for dealing with GPIO, the gpio device shall be exported i.e. represented
to the user interface in form of le. In the /sys/class/gpio directory you can nd hardware
nodes of the registered devices in the device tree source le as shown in gure 4.6.
Figure 4.6: Sysfs GPIO Nodes
79
Chapter 4. Software 4.4. GPIO Driver
Using the `export' le we can export the hardware in form of le system using the
following First we have to know assigned base address in the kernel for our target GPIO
$ cat gpiochip499 / base
In our example the result will be 499. Then we need to export this device
$ echo 499 > / sys / class / gpio / export
You can nd then that the gpio device has been exported as le system.
Figure 4.7: Exported GPIO Device
Note that you can use unexport le to revert back importing this device. Finally what
we need then is to set direction of the pin either out or in (pin 499) in direction le. Then
write which value we need to write in value le as shown in gure 4.8.
Figure 4.8: Sysfs Writing to GPIO
Note that in previous steps we had imported pin no. 499 of the device gpiochip499. In
order to know how many pins this device has, we can check that by the following
Figure 4.9: Sysfs GPIO Pins
In our case here, the device has 8 pins. First pin has no. 499. If you need to control
fourth pin for instance, then you have to export this pin and use the same sequence as
shown in gure 4.10.
Figure 4.10: Sysfs Writing to Pin
To read a value from the pin same sequence can be done but with direction in
Figure 4.11: Sysfs Reading GPIO
80
Chapter 4. Software 4.4. GPIO Driver
4.4.2 Using GPIOLIB
In Linux, there is one library that can be used as c-based library to get and set values of
the GPIO pins. To use these libraries, we have to know rst that this library is designed to
be used in kernel space. That is because it needs some information about the GPIO device
that is it is going to communicate with. This information will be caught from de nition
of the GPIO node in the device tree le. So to work with this library, device tree le shall
be con gured to provide needed information for the GPIOLIB. This library has su cient
information in its documentation [13].
What we can discuss here is showing usage of this library in basic steps.
4.4.2.1 Prepare Device Tree le
In the device tree le. De ne the gpio pins as follows
gpio_node {
compatible = " xlnx , org - gpio -1.00. a " ;
status = " okay " ;
org - gpios = <& axi_gpio_1 0 0 > ,
<& axi_gpio_1 1 0 > ,
<& axi_gpio_1 2 0 > ,
<& axi_gpio_1 3 0 > ,
<& axi_gpio_1 4 0 > ,
<& axi_gpio_1 5 0 > ,
<& axi_gpio_1 6 0 > ,
<& axi_gpio_1 7 0 >;
};
In this way, the GPIOLIB will consider group of pins (8 pins) that are attached to the
device node axi_gpio_1. This means that the main device axi_gpio_1 shall be de ned
also in the device tree le. This group of gpio pins will be named as org. So we have to
stick to this format when de ning name of the gpio pins: gpio_name-gpios.
4.4.2.2 Recognize GPIO Pins in the Platform Driver
When de ning the probe function of the platform driver, we can de ne our gpio pins using
gpiod_get functions. In case of group of pins we can use as in the following function
static struct gpio_descs * our_gpio ;
static int gpio_probe ( struct platform_device * pdev ) {
int gpio_width ;
struct device * dev = & pdev - > dev ;
printk ( KERN_ALERT " GPIO : Starting Module \ n " ) ;
our_gpio = gpiod_get_array ( dev , " org " , GPIOD_OUT_LOW ) ;
if ( IS_ERR ( our _gpio ) ) {
printk ( " GPIO : failed to acquire device \ n " ) ;
} else {
gpio_width = our_gpio - > ndescs ;
printk ( " GPIO : found % d elements \ n " , gpio_width ) ;
81
Chapter 4. Software 4.4. GPIO Driver
}
return 0;
}
4.4.2.3 Writing to the GPIO
The following function can be used to write for the GPIO
gpiod_set_array_value ( our_gpio - > ndescs , moi_gpio - > desc , value_arr ) ;
4.4.3 Using Generic UIO
This is a general driver that can be used for many peripherals. Its idea is based on writing to
the assigned memory address of the peripheral. According to data written to the peripheral
registers, the peripheral shall react. The advantage is end user doesn't have to know the
address of the peripheral to write into it, instead, he can write to a dedicated le to pass
data to the peripheral. The generic UIO is importing for each peripheral using this driver a
le to the user space so that he can use this le for passing the needed data. The following
lines discuss how to use this generic User IO driver with the hardware peripheral.
4.4.3.1 De ne Driver in Hardware Node
As any other driver, the driver ID shall be de ned in the 'compatible' property of the
peripheral in the device tree le. As a convention, the string generic-uio shall be used as
the name of the driver.
gpio_node {
compatible = " generic - uio " ;
status = " okay " ;
};
4.4.3.2 Enable UIO Driver in Kernel Con guration
The driver shall be built with the kernel so that it can be used as part of the system. In
kernel con guration le de ne the following attributes
CONFIG_UIO = y
CONFIG_UIO_PDRV_GENIRQ = y
CONFIG_UIO_DMEM_GENIRQ = y
Alternatively, you can choose these option through menucon g before building the
kernel
" Device Drivers " --->
| - " Userspace I / O drivers " --->
| - <* > Userspace I / O platform driver with generic IRQ handling
| - <* > Userspace I / O OF driver with generic IRQ handling
82
Chapter 4. Software 4.4. GPIO Driver
4.4.3.3 Set Driver Identi cation in Kernel
Although we have de ned the driver while building the kernel, the string that we used in
property compatible in device tree is not yet identi ed in the kernel driver. So we need
to con gure the UIO driver to use this string generic-uio. This step has to be done before
booting the kernel. So we can pass it to the kernel as part of the bootargs. To do that,
the following bootargs has to be used
bootargs = " earlycon clk_ignore_unused uio_pdrv_genirq . of_id = generic - uio " ;
in which we added uio_pdrv_genirq.of_id=generic-uio. This string will change the
id of the driver to match the string that we de ned in compatible property.
When the system boots, the UIO device is represented in the lesystem as "/dev/uioN"
where N is an incrementing integer value for each separate UIO device. To know which
uioN corresponds to which device , we can use
$cat / sys / class / uio / uio$N / name
note that $N shall be replaced with the right assigned number.
Alternatively, we can use 'lsuio' utility to list all the devices that are binded to generic
UIO driver.
$lsuio
4.4.3.4 Writing to UIO
In order to write les imported for each device in /dev directory, we can use one utility
called 'memtool'.
# # To read
memtool md -s / dev / uio$N < offsetAddress >
# # To write
memtool mw -d / dev / uio$N < offsetAddress > < data >
Note again that $N represents the uio number assigned to the device.
Also another tool can be used like 'devmem' which also has similar syntax.
83
Bibliography
[1] Xilinx Vivado and SDK Programm User Interface
[2] https://elinux.org/Device_Tree_Usage
[3] https://www.kernel.org/doc/Documentation/devicetree/bindings/xilinx.txt
[4] http://www.wiki.xilinx.com/Arm+Trusted+Firmware
[5] https://emreboy.wordpress.com/2012/12/20/building-a-root- le-system-using-
busybox/
[6] http://xilinx.wikidot.com/zynq-rootfs
[7] http://www.etalabs.net/compare_libcs.html
[8] https://mirrors.edge.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Dierences.txt
[9] https://elinux.org/images/f/f4/Elc2013_Fernandes.pdf
[10] http://www.wiki.xilinx.com/U-Boot+Flattened+Device+Tree
[11] http://www.wiki.xilinx.com/Solution+ZynqMP+PL+Programming
[12] https://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-
2005/mochel.pdf
[13] https://www.kernel.org/doc/Documentation/gpio/
84
You might also like
- Universal Chiplet Interconnect Express (UCIe) Specification Revision 1.1No ratings yetUniversal Chiplet Interconnect Express (UCIe) Specification Revision 1.1338 pages
- Cyclic Redundancy Check: Mathematical and Hardware Overview100% (3)Cyclic Redundancy Check: Mathematical and Hardware Overview26 pages
- Book Constraining Designs For Synthesis and Timing Analysis PDFNo ratings yetBook Constraining Designs For Synthesis and Timing Analysis PDF2 pages
- Synopsys Designware Digital Ip QuickrefNo ratings yetSynopsys Designware Digital Ip Quickref185 pages
- ATA 32-40 Landing Gear System Wheels and Brakes A 320 Family75% (4)ATA 32-40 Landing Gear System Wheels and Brakes A 320 Family44 pages
- Macos: Macos Catalina Macos Mojave Macos High Sierra Macos Sierra Os X El CapitanNo ratings yetMacos: Macos Catalina Macos Mojave Macos High Sierra Macos Sierra Os X El Capitan3 pages
- Verilog Code For Floating Point 32-Bit MultiplicationNo ratings yetVerilog Code For Floating Point 32-Bit Multiplication5 pages
- Lec05 Introduction To Macros and SRAM LintNo ratings yetLec05 Introduction To Macros and SRAM Lint48 pages
- Accident Detection and Alert System Based On ARM7 MicrocontrollerNo ratings yetAccident Detection and Alert System Based On ARM7 Microcontroller4 pages
- Systemverilog For RTL Design Workshop: Lab GuideNo ratings yetSystemverilog For RTL Design Workshop: Lab Guide36 pages
- Unveil The Mystery of Code Coverage in Low-Power Designs: Achieving Power AwareNo ratings yetUnveil The Mystery of Code Coverage in Low-Power Designs: Achieving Power Aware13 pages
- ROUTER 1x3 RTL Design and UVM VerificationNo ratings yetROUTER 1x3 RTL Design and UVM Verification74 pages
- 4.6 - LSI - Power Aware Design VerificationNo ratings yet4.6 - LSI - Power Aware Design Verification25 pages
- Verilog Chapter3 Module+and+Hierarchical+StructureNo ratings yetVerilog Chapter3 Module+and+Hierarchical+Structure24 pages
- Certify Partition Driven Synthesis: User GuideNo ratings yetCertify Partition Driven Synthesis: User Guide866 pages
- Ibex Documentation: Release 0.1.dev50+g36ce999.d20191026No ratings yetIbex Documentation: Release 0.1.dev50+g36ce999.d2019102653 pages
- Cyclone V Avalon-Mm Interface For Pcie Solutions: User GuideNo ratings yetCyclone V Avalon-Mm Interface For Pcie Solutions: User Guide173 pages
- Vlsi Project Report Arithmetic Logical Unit Using Verilog AluNo ratings yetVlsi Project Report Arithmetic Logical Unit Using Verilog Alu7 pages
- Verifying A Low Power Design: Asif JafriNo ratings yetVerifying A Low Power Design: Asif Jafri10 pages
- Understanding DDR - DDR Protocol - Truechip VIPsNo ratings yetUnderstanding DDR - DDR Protocol - Truechip VIPs9 pages
- Smart Card Applications: Design models for using and programming smart cardsFrom EverandSmart Card Applications: Design models for using and programming smart cardsNo ratings yet
- Mars Zx3 Soc Module: Reference Design For Mars Pm3 Base Board User ManualNo ratings yetMars Zx3 Soc Module: Reference Design For Mars Pm3 Base Board User Manual42 pages
- Stm32cubeprogrammer Software Description StmicroelectronicsNo ratings yetStm32cubeprogrammer Software Description Stmicroelectronics84 pages
- Cadence Virtuoso: Introductory TutorialNo ratings yetCadence Virtuoso: Introductory Tutorial20 pages
- Wrapping TCL Scripts: Tclpot User GuideNo ratings yetWrapping TCL Scripts: Tclpot User Guide23 pages
- Wrapping TCL Scripts: Tclpot User GuideNo ratings yetWrapping TCL Scripts: Tclpot User Guide23 pages
- Verification Plan in Mentor Graphics Questa100% (1)Verification Plan in Mentor Graphics Questa10 pages
- Human Auditory System: Audio Processing GuideNo ratings yetHuman Auditory System: Audio Processing Guide11 pages
- Draw The Block Diagram of Simple Microprocessor-Based System and Explain The Function of Each Block (You Can Use MS Word or Google Docs)No ratings yetDraw The Block Diagram of Simple Microprocessor-Based System and Explain The Function of Each Block (You Can Use MS Word or Google Docs)8 pages
- Category ID Product Quantity Unit Price TotalNo ratings yetCategory ID Product Quantity Unit Price Total1 page
- Datasheet HP 200 G4 22 All-In-One PC (9US61EA)No ratings yetDatasheet HP 200 G4 22 All-In-One PC (9US61EA)4 pages
- MS For The Access Control System Installation and TerminationNo ratings yetMS For The Access Control System Installation and Termination21 pages
- Chapter 4.2 Programming Timers - A - SiemensNo ratings yetChapter 4.2 Programming Timers - A - Siemens71 pages
- EDC-DTS-MV011 - Pole Mounted Load Break Switches and Sectionalizers100% (1)EDC-DTS-MV011 - Pole Mounted Load Break Switches and Sectionalizers37 pages
- Software Suite To Support STM32 DevelopmentNo ratings yetSoftware Suite To Support STM32 Development12 pages
- 225D SMARTCELL Weight Indicator 8200 0753 0MNo ratings yet225D SMARTCELL Weight Indicator 8200 0753 0M42 pages
- 19ECE349-RISC Processor Design Using HDLNo ratings yet19ECE349-RISC Processor Design Using HDL325 pages
