Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
$ sudo systemctl isolate multi-user.target

To return to the graphical desktop environment:

Code Block
systemctl isolate graphical.target

To make this change permanent (eg, the graphical desktop environment will no longer start automatically):

...

Info

NOTE: The default Ubuntu display manager is gdm. Some desktop environments require the lightdm display manager. You may need to switch the default display manager when switching desktop environments

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:

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:

Code Block
 $ 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.

Note

For general usage, Xilinx does not recommend lowering the CMA below 256MB

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

...

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:

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:

Code Block
 $ 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.

Note

For general usage, Xilinx does not recommend lowering the CMA below 256MB

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

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

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

	boardeth_revisionmac: boardeth-revision@e0mac@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:

...

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:

...

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:

Code Block
$ 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 20.04 LTS 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

Code Block
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