Zynq MPSoC ported to use Xilinx Certified Ubuntu on a custom hardware platform (taking ZCU102 as an example)

Subsequent updates and resources for this article are on the personal homepage, please click here to view

foreword

Porting Linux in Zynq has always been a long-standing problem for beginners like us. This problem has been alleviated after the official launch of Petalinux. However, the operation simplicity of Petalinux OS is not as good as that of the already mature desktop system Ubuntu. At present, most of the tutorials on the Internet focus on using Petalinux to generate the device tree and kernel to replace Ubuntu's rootfs. In fact, after Vitis AI was born, Xilinx gave an Ubuntu that had been transplanted for Zynq MPSoc, and named it Xilinx Certified Ubuntu. This version is a Golden image that can drive most hardware interfaces. But if you want to make changes on the PL side and drive it in Linux, you need to reconstruct the device tree and Bitstream yourself. Other benefits of utilizing Xilinx Certified Ubuntu include:

• Provide snap images of xlnx-config, fpga-manager-xlnx, bootgen-xlnx and other tools to manage PL resources on the linux side.
• Use xlnx-config to realize the switching of various configured platform resources (PAC), and automatically generate a Boot image, which will take effect directly after restarting.
  For an image that cannot be booted due to a programming error, it will be rolled back to the Golden image after restarting and failing to boot.
• More

This article will implement Xilinx Certified Ubuntu installation, custom hardware platform design, construction of custom platform assets (PAC), and switching of hardware assets on Linux step by step from the bare board. As a learning record, I hope it will be helpful to everyone.

Step1: Install and start Xilinx Certified Ubuntu

Visit Ubuntu official website to download firmware: https://ubuntu.com/download/amd-xilinx

At the time of writing, the latest firmware is 20.04LTS. The following will take 20.04LTS as an example.

Insert the SD card into the card reader, decompress the downloaded .xz compressed package into img, and use the image burning tool to burn the downloaded image to the SD card. (balenaEtcher is recommended, common to all operating systems).

Plug in the power supply, USB-UART cable, SD card, monitor and keyboard. Adjust the SW6 switch on the ZCU102 as shown in the figure below (from the UG1182 official document, especially note that the Pins serial number of the official document is [4:1] not [1:4]... At that time, I was stuck and adjusted for a long time)

Directions from the official manual

Actual location

Connect the UART to the computer (provided that the driver of the CP210X serial port chip is installed), you can see that there are 4 more ports, open Interface 0 (baud rate 115200, 8-bit data, 1-bit stop, no parity), open Power on, see if there is any serial port information printed out.

If everything is normal, you can see that the Ubuntu system has been booted successfully. The username and password are both ubuntu.

Let's analyze the startup process carefully so that we can replace it with our own hardware platform in the future.

The files in the SD card during startup are as follows:

• boot.bin (board identification and image selection ImgSel)
• boot 10(2,4,6)1.bin (ZCU102/104/106 dedicated image)
• boot.scr.uimg （Uboot）
• image.fit
• meta-data, network-config, user-data (data required by linux)

When Xilinx is started, BootROM will first detect the state of the device mode pin. When the SD card is started, it will search whether there is a boot.bin in the first partition of the SD card. If not, add a number after it, search for boot1.bin, boot2.bin... Until boot8191.bin, this mode is called MultiBoot. In Certified Ubuntu, boot.bin is a minimal application (ImgSel) that is used to determine which board it is running on, and then hand over the boot process to the more powerful FSBL for execution. In this example, ImgSel detects the 102 board, writes 1020 into the MultiBoot register, BootROM starts from boot1020.bin, and finally finds boot1021.bin (Golden image designed for ZCU102) to start. The above-mentioned use of xlnx-config for image management is essentially to package boot1020.bin and write it to the SD card. After boot1020.bin fails, it will automatically roll back to Golden image boot1021.bin.

Refer to the figure on the right for specific startup (from reference [2])

Step2 Create your own hardware platform with Vivado

Open Vivado, select the ZCU102 board, Create Block Design.

Add a Zynq core, run Block Automation first, and select Apply Board Preset in the pop-up window, so that you can save a lot of things later.
Add an AXI GPIO for testing read and write development board pins, and an AXI BRAM Controller for BRAM testing.
Generate Block Design -> Right-click bd -> Create HDL Wrapper
Write Constraint
Generate Bitstream
File -> Export Hardware Export xsa
Open Vitis, create a new Platform Project, and select the xsa just exported.

Build the Platform Project

Build
After the build is successful, take out the following two files

/zynqmp_fsbl/fsbl_a53.elf
/zynqmp_pmufw/pmufw.elf

Next, export the device tree.

If you perform this operation for the first time, you need to pull Xilinx's Device Tree Generator at any location, otherwise an error will be reported.

git clone https://github.com/Xilinx/device-tree-xlnx
cd device-tree-xlnx
git checkout <你的套件版本，如xlnx_rel_v2021.2>

In Vitis, select Xilinx->Software Repositories, add the local folder address of the warehouse just pulled

Next, select Xilinx->Generate Device Tree, select xsa, and configure the export folder.

The generated file is shown in the figure, because the XSA file only contains user-defined IP and Zynq, so to activate the Ethernet network, you need to write the device tree yourself, modify the system-top.dts in it to add the PHY of Ethernet (step on the pit*n) and It is also necessary to add the model and compatible fields to allow Uboot/Ubuntu to correctly identify the hardware development board information and load the driver (stepping on the pit again). (Reference: https://github.com/Xilinx/u-boot-xlnx/blob/3113b53d8cb1913ef8162cadf45f44ebf2ed9eea/arch/arm/dts/zynqmp-zcu102-revA.dts)

/dts-v1/;
#include "zynqmp.dtsi"
#include "zynqmp-clk-ccf.dtsi"
#include "pl.dtsi"
#include "pcw.dtsi"

/ {
    
    
	model = "ZynqMP ZCU102 Rev1.1";
	compatible = "xlnx,zynqmp-zcu102-rev1.1", "xlnx,zynqmp-zcu102", "xlnx,zynqmp";
	chosen {
    
    
		bootargs = "earlycon";
		stdout-path = "serial0:115200n8";
	};
	aliases {
    
    
		ethernet0 = &gem3;
		i2c0 = &i2c0;
		i2c1 = &i2c1;
		serial0 = &uart0;
		serial1 = &uart1;
		spi0 = &qspi;
	};
	memory {
    
    
		device_type = "memory";
		reg = <0x0 0x0 0x0 0x7ff00000>, <0x00000008 0x00000000 0x0 0x80000000>;
	};
};

&gem3 {
    
    
	status = "okay";
	phy-handle = <&phy0>;
	phy-mode = "rgmii-id";
	pinctrl-names = "default";
	phy0: ethernet-phy@c {
    
    
		reg = <0xc>;
		ti,rx-internal-delay = <0x8>;
		ti,tx-internal-delay = <0xa>;
		ti,fifo-depth = <0x1>;
		ti,dp83867-rxctrl-strap-quirk;
		/* reset-gpios = <&tca6416_u97 6 GPIO_ACTIVE_LOW>; */
	};
};

Next, compile the device tree blob file (DTB) and enter the generated device tree directory. This step needs to be performed under the Linux system.

gcc -I my_dts -E -nostdinc -undef -D__DTS__ -x assembler-with-cpp -o system-top.dts.tmp system-top.dts

dtc -I dts -O dtb -o system-top.dtb system-top.dts.tmp

So far, the device tree file system-top.dtb appears in the folder, save it

Next, compile the ARM Trusted Firmware (ATF)

git clone https://github.com/Xilinx/arm-trusted-firmware.git
cd arm-trusted-firmware

There is a soft link to the linux library in this repository. If you encounter an error, you have to delete the soft link and rebuild it yourself. I forgot which one it is. . after processing

make CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp RESET_TO_BL31=1

To perform cross-compilation, after compiling, bl31.elf will be generated and saved.

Now we have these files:

)
Save the PL Bitstream generated by Vivado here and name it system.bit. Next, we create a new file named bootgen.bif with the following content:

the_ROM_image:
{
    
    
        [bootloader, destination_cpu=a53-0] fsbl_a53.elf
        [pmufw_image] pmufw.elf
        [destination_device=pl] system.bit
        [destination_cpu=a53-0, exception_level=el-3, trustzone] bl31.elf
        [destination_cpu=a53-0, load=0x00100000] system-top.dtb
        [destination_cpu=a53-0, exception_level=el-2] /usr/lib/u-boot/xilinx_zynqmp_virt/u-boot.elf
}

The meaning of these files, Xilinx Wiki has a corresponding introduction.

bootgen.bif	Description file for generating boot.bin
fsbl_a53.elf	First Stage Bootloader
system.bit	Bitstream file of PL
bl31.elf	ARM Trusted Firmware
system-top.dtb	The device tree file needs to correspond to system.bit
uboot.elf	u-boot file, for ZCU102, you can directly use /usr/lib/u-boot/xilinx_zynqmp_virt/u-boot.elf in the Certified Ubuntu system
dpu.xclbin	(Optional) DPU configuration of system.bit
pmufw.elf	Platform Management Unit (PMU) firmware

So much has been said before, when we replace the new hardware platform, we only need to consider system.bit, system-top.dtb, dpu.xclbin, and other builds are done once and for all.

Or you don’t want to build. For fsbl and bl31, you can use the golden image in Certified Ubuntu. The storage path is:

/usr/share/xlnx-firmware/zcu10[x]

Next, we store the above files as follows according to the requirements of the xlnx-config tool (the test_pac folder is stored in /boot/firmware/xlnx-config. Because /boot/firmware is the mount point of the SD card, so also Can operate directly on SD card)

test_pac/
└── hwconfig
    ├── test_pac
    │   ├── manifest.yaml
    │   ├── zcu102
    │   │   ├── bl31.elf
    │   │   ├── bootgen.bif
    │   │   ├── fsbl_a53.elf
    │   │   ├── pmufw.elf
    │   │   ├── system.bit
    │   │   └── system-top.dtb

The manifest.yaml is as follows:

name: test_platform
desscription: Boot assets for the 2021.2 test design
revision: 1
assets:
        zcu102: zcu102

Step 3 Activate the custom hardware platform (PAC)

First, you need to install Xilinx official tool xlnx-config (the failure rate of snap pull is quite high..)

sudo snap install xlnx-config --classic --channel=1.x
xlnx-config.sysinit

If there is no snap, install snap first, and then perform the above operations

sudo snap install snap-store

After the installation is complete, enter xlnx-config -q to see the custom hardware platform we just set up

Use sudo xlnx-config -a test_pac to activate the platform we just set up, the tool will be automatically packaged into boot.bin and put into the SD card named boot1020.bin. It will take effect after reboot.

After restarting, you can view the activated assets through xlnx-config -q

reference

[1] Getting Started with Certified Ubuntu 20.04 LTS for Xilinx Devices

[2] Booting Certified Ubuntu 20.04 LTS for Xilinx Devices

[3] Build ARM Trusted Firmware (ATF)

[4] Snaps – xlnx-config Snap for Certified Ubuntu on Xilinx Devices

[5] Xilinx/embeddedsw

[6] Xilinx/linux-xlnx

[7] Device Trees

[8] Solution ZynqMP PL Programming

[9] Creating Devicetree from Devicetree Generator for Zynq Ultrascale and Zynq 7000

[10] Xilinx/u-boot-xlnx