This page collects various tips & tricks for getting the most out of the Certified Ubuntu on Xilinx Devices release.

Table of Contents

Installing a Graphical Package Manager

The core of the Ubuntu ecosystem is 3rd-party packages. Ubuntu 20.04 LTS provides some packages as tradition Debian .deb packages in apt repositories. Sandboxed modern applications are provided as Snaps (such as xlnx-config). By default, the Certified Ubuntu on Xilinx Devices image does not provide a graphical package manager. If you would like to add one, there are several available in the existing Ubuntu package repository ecosystem.

...

$ sudo snap install snap-store

Stopping the Ubuntu Graphical Desktop Environment

If you wish to stop the Ubuntu graphical desktop environment and return to a strictly command line environment, you can do so by using the systemd interfaces. The systemd “multi-user” target is equivalent to runlevels 3, 4, or 5 in traditional systems based on SysVInit. This can be used to save system memory which would otherwise be used for running the rich desktop experience.

...

$ sudo systemctl enable multi-user.target
$ sudo systemctl set-default multi-user.target

Switching Desktop Environments

The default graphical environment in Ubuntu 20.04 LTS and 22.04 LTS is based on GNOME3. Other desktop environments are available and can be installed to suit personal preference.

...

For a list of desktop environment packages, see the table below.

Understanding CMA Usage

Many of the Xilinx designs, particularly those that leverage the Xilinx Video Codec Unit (VCU), make extensive use of Contiguous Memory Allocator (CMA) in the Linux kernel.

There are many resources that explain how CMA works:

• Linux kernel documentation

• Michał Nazarewicz presentation (Google 2012)

• Michał Nazarewicz Blog Entery

• SeongJae Park presentation (Linux Plumbers 2018)

The Xilinx VCU User Guide (PG252) has details on how the VCU device drivers leverage CMA and contains references on CMA sizes for various applications.

The default Certified Ubuntu on Xilinx Devices image specifies a CMA size that is best suited for the official out-of-the-box demonstrations. Depending on your workloads and usage, you may find that you need to adjust the default CMA size to meet your needs.

The following Bash line can be used to monitor the current CMA usage:

 $ while :; do cat /proc/meminfo | grep Cma; echo '---'; sleep 1; done;

If you would like to alter CMA value to free up memory for other applications, please see the Getting Started with Certified Ubuntu on Xilinx Devices page in the Changing the Kernel bootargs Used By U-Boot section.

Updating the Board-Level Metadata EEPROM

Xilinx evaluation boards have metadata about the board stored in an I2C EEPROM soldered to the board. Among this data is the serial number of the board, name of the board (eg, ZCU102), board revision, and Ethernet MAC address.
Xilinx declares how & where this information is stored in the device tree DTS file for the ZCU102 here: https://raw.githubusercontent.com/Xilinx/u-boot-xlnx/master/arch/arm/dts/zynqmp-zcu102-rev1.0.dts

&eeprom {
	#address-cells = <1>;
	#size-cells = <1>;

	board_sn: board-sn@0 {
		reg = <0x0 0x14>;
	};

	eth_mac: eth-mac@20 {
		reg = <0x20 0x6>;
	};

	board_name: board-name@d0 {
		reg = <0xd0 0x6>;
	};

	board_revision: board-revision@e0 {
		reg = <0xe0 0x3>;
	};
};

For some boards (especially boards early in the production run), this data may be incomplete. To check this data on your board, stop the boot process during the U-Boot startup phase by pressing CTRL-C when you see the following messages on the USB UART terminal:

U-Boot 2020.01 (Jun 15 2021 - 14:24:32 +0000)

Model: ZynqMP ZCU102 Rev1.0
Board: Xilinx ZynqMP

This will stop the boot process at the U-Boot terminal. U-Boot provides an I2C interface which can read and write data from the meta-data EEPROM. Xilinx has populated the ZCU10x evaluation boards with multiple I2C devices, each attached to the output of an I2C mux. To get the topology of the I2C chain use the following command:

Screen Sharing and VNC

You can share the desktop by enabling Screen Sharing in the GNOME desktop settings. You first need to install the Vino package. More details can be found at the following page:

https://linuxhint.com/enable-screen-sharing-ubuntu/

If you’d rather run a more traditional VNC server with support for multiple virtual desktops instead of sharing the primary desktop, you can refer to the following guide:

https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-on-ubuntu-20-04

Understanding CMA Usage

Many of the Xilinx designs, particularly those that leverage the Xilinx Video Codec Unit (VCU), make extensive use of Contiguous Memory Allocator (CMA) in the Linux kernel.

There are many resources that explain how CMA works:

• Linux kernel documentation

• Michał Nazarewicz presentation (Google 2012)

• Michał Nazarewicz Blog Entery

• SeongJae Park presentation (Linux Plumbers 2018)

The Xilinx VCU User Guide (PG252) has details on how the VCU device drivers leverage CMA and contains references on CMA sizes for various applications.

The default Certified Ubuntu on Xilinx Devices image specifies a CMA size that is best suited for the official out-of-the-box demonstrations. Depending on your workloads and usage, you may find that you need to adjust the default CMA size to meet your needs.

The following Bash line can be used to monitor the current CMA usage:

 $ while :; do cat /proc/meminfo | grep Cma; echo '---'; sleep 1; done;

If you would like to alter CMA value to free up memory for other applications, please see the Getting Started with Certified Ubuntu on Xilinx Devices page in the Changing the Kernel bootargs Used By U-Boot section.

Updating the Board-Level Metadata EEPROM

Xilinx evaluation boards have metadata about the board stored in an I²C EEPROM soldered to the board. Among this data is the serial number of the board, name of the board (eg, ZCU102), board revision, and Ethernet MAC address.
Xilinx declares how & where this information is stored in the device tree DTS file for the ZCU102 here: https://raw.githubusercontent.com/Xilinx/u-boot-xlnx/master/arch/arm/dts/zynqmp-zcu102-rev1.0.dts

&eeprom {
	#address-cells = <1>;
	#size-cells = <1>;

	board_sn: board-sn@0 {
		reg = <0x0 0x14>;
	};

	eth_mac: eth-mac@20 {
		reg = <0x20 0x6>;
	};

	board_name: board-name@d0 {
		reg = <0xd0 0x6>;
	};

	board_revision: board-revision@e0 {
		reg = <0xe0 0x3>;
	};
};

For some boards (especially boards early in the production run), this data may be incomplete. To check this data on your board, stop the boot process during the U-Boot startup phase by pressing CTRL-C when you see the following messages on the USB UART terminal:

U-Boot 2020.01 (Jun 15 2021 - 14:24:32 +0000)

Model: ZynqMP ZCU102 Rev1.0
Board: Xilinx ZynqMP

This will stop the boot process at the U-Boot terminal. U-Boot provides an I2C interface which can read and write data from the meta-data EEPROM. Xilinx has populated the ZCU10x evaluation boards with multiple I2C devices, each attached to the output of an I²C mux. To get the topology of the I²C chain use the following command:

ZynqMP> i2c bus
Bus 0:  i2c@ff020000
   20: gpio@20, offset len 1, flags 0
   21: gpio@21, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 52:  i2c@ff030000i2c@ff020000->i2c-mux@74mux@75->i2c@0
Bus (active3: 5)
   54: eeprom@54, offset len 1, flags 0
Bus 6:  i2c@ff030000->i2c-mux@74->i2c@1
Bus 7 i2c@ff020000->i2c-mux@75->i2c@1
Bus 4:  i2c@ff020000->i2c-mux@75->i2c@2
Bus 1:  i2c@ff030000  (active 1)
   74: i2c-mux@74, offset len 1, flags 0
   75: i2c-mux@75, offset len 1, flags 0
Bus 5:  i2c@ff030000->i2c-mux@74->i2c@2>i2c@0 Bus 8 (active 5)
   54: eeprom@54, offset len 1, flags 0
Bus 6:  i2c@ff030000->i2c-mux@74->i2c@1
Bus 7:  i2c@ff030000->i2c-mux@74->i2c@2
Bus 8:  i2c@ff030000->i2c-mux@74->i2c@3
Bus 9:  i2c@ff030000->i2c-mux@74->i2c@4
Bus 10: i2c@ff030000->i2c-mux@75->i2c@0
Bus 11: i2c@ff030000->i2c-mux@75->i2c@1
Bus 12: i2c@ff030000->i2c-mux@75->i2c@2
Bus 13: i2c@ff030000->i2c-mux@75->i2c@3
Bus 14: i2c@ff030000->i2c-mux@75->i2c@4
Bus 15: i2c@ff030000->i2c-mux@75->i2c@5
Bus 16: i2c@ff030000->i2c-mux@75->i2c@6
Bus 17: i2c@ff030000->i2c-mux@75->i2c@7

...

Most of the data is informational only, but two pieces are critical:

1. Board Name (address 0xd0)

2. MAC address (address 0x20)

If the board name field is not correct, the Certified Ubuntu on Xilinx Devices image will not boot properly. The Certified Ubuntu release uses this data during its initial boot phase (the ImgSel tool) documented by Xilinx here: Booting Certified Ubuntu 20.04 LTS for Xilinx for Xilinx Devices . The ImgSel tool reads the board name and then uses this information to boot the correct BOOT.BIN file.

...

ubuntu@zynqmp:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff

You should see the MAC address value set in U-Boot. In the data shown above, the actual MAC address is [REDACTED].

The same basic process can be used to update the Board Name, Board Serial Number, or Board Version fields. Keep in mind that when writing the values for the Board Name, Board Version Number, and Board Serial Number to use the ASCII values in hexadecimal. The MAC address is written in native hexadecimal values.

Ubuntu Internal Error Messages

From time to time, the Ubuntu desktop may display error messages similar to Sorry, Ubuntu 20.04 has experienced an internal error.

...

These messages are generated by the Ubuntu error checking tool called Apport. You can learn more about Apport here. If this is the first time you’ve seen the message, you can learn more details by clicking the Show Details button to learn more.

...

Many types of scenarios can generate Apport errors and not all of them indicate an actual problem in the system. If you wish, you can click the boxes Remember this in future and Ignore future problems of this type to prevent these general types of warnings from being generated. Please be sure to check the details of the error messages before suppressing them.

Apport runs as a background service. If you are confident that the errors you see are not representative of larger errors in your system, you can disable the Apport service by issuing the command:

$ sudo systemctl disable apport.service mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether [REDACTED] brd ff:ff:ff:ff:ff:ff

You should see the MAC address value set in U-Boot. In the data shown above, the actual MAC address is [REDACTED].

The same basic process can be used to update the Board Name, Board Serial Number, or Board Version fields. Keep in mind that when writing the values for the Board Name, Board Version Number, and Board Serial Number to use the ASCII values in hexadecimal. The MAC address is written in native hexadecimal values.

Ubuntu Internal Error Messages

From time to time, the Ubuntu desktop may display error messages similar to Sorry, Ubuntu 20.04 has experienced an internal error.

...

These messages are generated by the Ubuntu error checking tool called Apport. You can learn more about Apport here. If this is the first time you’ve seen the message, you can learn more details by clicking the Show Details button to learn more.

...

Many types of scenarios can generate Apport errors and not all of them indicate an actual problem in the system. If you wish, you can click the boxes Remember this in future and Ignore future problems of this type to prevent these general types of warnings from being generated. Please be sure to check the details of the error messages before suppressing them.

Apport runs as a background service. If you are confident that the errors you see are not representative of larger errors in your system, you can disable the Apport service by issuing the command:

$ sudo systemctl disable apport.service

Rebuilding the Image Selector Utility

The core of the Certified Ubuntu for Xilinx Devices boot process on ZCU10x boards is the Image Selector tool. This utility performs the initial boot of the board, reads board-identifying information from the attached EEPROM, and then reboots into a customized set of boot collateral for the specific board it is running on. For more detail on this process, see the Booting Certified Ubuntu for Xilinx Devices page.This is what allows the same Certified Ubuntu for Xilinx Devices SD card image to boot on multiple boards. Typically, there is no need to modify this code. If a user determines that they would like to modify the way that Image Selector operates, it can be rebuilt inside the Vitis environment. The source code of Image Selector is part of the Xilinx embeddedsw repository on the Xilinx GitHub.

The Tcl code below automates the building of the Image Selector tool inside of Vitis. Be sure to pass the symbol XIS_UART_ENABLE to see the STDOUT info (as seen below).

imgsel

proc generate_imgsel {} {
    set xsa [glob -nocomplain -directory [pwd] -type f *.xsa]
    puts "Using XSA: $xsa"
    setws vitis_workspace
    platform create -name [file tail [file rootname $xsa]]_platform_0 -hw $xsa
    domain create -name "app_domain" -os standalone -proc psu_cortexa53_0
    configbsp -bsp "app_domain" stdin psu_uart_1
    configbsp -bsp "app_domain" stdout psu_uart_1
    regenbsp -bsp "app_domain"
    platform generate
    app create -name imgsel -domain app_domain -template "Image Selector"
    configapp -app imgsel define-compiler-symbols XIS_UART_ENABLE
    app build -name imgsel
    elf2bin vitis_workspace/imgsel/Debug/imgsel.elf
}
 
proc elf2bin {elf} {
    set fileId [open bootgen.bif "w"]
    puts $fileId "the_ROM_image:"
    puts $fileId "\{"
    puts $fileId "\t\[fsbl_config\] a53_x64"
    puts $fileId "\t\[bootloader, destination_cpu=a53-0\] $elf"
    puts $fileId "\}"
    close $fileId
}

When building Image Selector manually, be sure to include at least the minimal hardware definition found below:

Minimum Processing System (PS) configuration:

https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/imgsel/src/psu_init.c#L1045

Minimum Board Support configuration:

https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/imgsel/src/xis_singleimage.c#L50

Using a Custom Device Tree

To temporarily override the DTB without modifying the FIT image (Kria) or bootxxxx.bin (ZCU10x), you can create a new dtb named user-override.dtb.  Copy user-override.dtb to the FAT partition and reboot. If user-override.dtb is found on the FAT partition by U-boot, it will use this DTB instead of the board-specific DTB found in the FIT image when Linux is started.

Understanding the Configuring flash-kernel Prompts When Updating the Linux Kernel

When updating the Linux kernel via packages available in the Ubuntu package feed, the following prompt may appear:

...

In general, it is safe to choose either the local version or the maintainer’s version. This message is an artifact how the Linux kernel packages are configured for the Certified Ubuntu image. Typically, the Ubuntu version of the Linux kernel includes both the splash and quietcommand line arguments. The splash argument is typically used in desktop Linux distributions and instructs the kernel to display a splash screen (eg, a screen displaying the distribution's logo) if one is available. The quiet argument puts the kernel into non-verbose mode. Omitting this option will produce much more output on the terminal during Linux kernel boot. In most Linux distributions (including Ubuntu), the quiet argument is used to produce a more aesthetically pleasing boot experience. The AMD-Xilinx Certified Ubuntu image omits the quiet argument in order to produce more debug messages that are useful when prototyping. This change in the default boot arguments is applied using a meta-package overlay. This overlay causes a mis-match in the kernel package configuration when updating it via normal package management methods.

When updating the kernel, the options presented correspond to:

1. install the package maintainer's version -- This option will add the default "quiet splash" options back to the Linux kernel command line

2. keep the local version currently installed -- This option will keep the AMD-Xilinx configuration which omits the quiet option.