Xilinx tools have stringent installation requirements regarding supported Linux Distributions, especially after 2023.1, where support for RedHat EL and CentOS was removed. We will use Toolbox to create containers with supported distributions to install the tools on.
Overview
Toolbox is a tool for Linux that facilitates the creation of interactive command-line environments within containers for development and troubleshooting purposes. It leverages Podman, a daemonless container engine, to manage these containers. When you create a Toolbox environment, it utilizes Podman to set up a container that is tightly integrated with your host system. This integration allows the container to access your home directory, system configurations, and other resources, providing a seamless development experience. In this setup, the host Linux operating system runs Podman, which in turn manages the Toolbox container. The Toolbox container operates as an isolated environment for development and debugging, while still maintaining access to necessary host resources.
Podman and Toolbox
Podman is an open-source, daemonless container engine designed to manage containers and container images. Podman adheres to the OCI (Open Container Initiative) standards, ensuring compatibility with container images and runtimes.
In this diagram, we see how podman accesses already-made images from various image registries, generates container images and then runs them as container instances.
In this image creation process, the container images are immutable - they can’t be changed after generated. It would be useful if these images could be modified after creation, for instance to install tools on them. This is where Toolbox comes in. Toolbox provides a fully mutable container within which one can install their favorite development tools, editors and SDKs, all without affecting the base operating system.
Base flow
This process could be summarize in a few steps.
- Pull image for the supported distribution using Toolbox.
- Enter the Toolbox container.
- Install any required packages by the development tools.
- Install the tools.
- Test tools functionality.
- Optionally create a new image based on this mutable container.
Installation
Toolbox and podman are supported by a few Linux distributions, but together amass probably most of the market share of available distributions: Arch Linux, Fedora, RHEL >=8.5 and Ubuntu. Installing them would require the use of their particular package management tools. For instance, on Fedora it would be:
$ sudo dnf install podman toolbox
In this exercise, we will install a Toolbox image based on Ubuntu 22.04.
$ toolbox create --distro ubuntu --release 22.04
Image required to create toolbox container.
Download quay.io/toolbx/ubuntu-toolbox:22.04 (189.9MB)? [y/N]: y
Created container: ubuntu-toolbox-22.04
Enter with: toolbox enter ubuntu-toolbox-22.04
If this is the first time creating that image, it will be automatically downloaded from one of the image registries; in this case from quay.io. The image is 190MB in size. Within a few seconds, the toolbox image is ready to be used.
$ toolbox enter ubuntu-toolbox-22.04
⬢[pcarr@toolbox ~]$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy
We notice the terminal prompt has changed; it now includes a leading hexagon and the hostname is now “toolbox” to indicate we are within the instantiated container. However, as we navigate the local filesystem, the $HOME directory, Wayland & X11 sockets, networking, removable devices, SSH agent, D-Bus, etc. have all been preserved from the host OS. It’s mainly the system-related pieces have been “replaced” when the container is in use. This is all it requires to have a mutable container where to install our tools. In the next section, we will install Petalinux 2023.1 inside the container. In the same fashion, we could also install Vitis/Vivado or any other development tool.
Adding development tools
Petalinux has a number of required packages in Ubuntu 22.04 that we will need to install before proceeding with its installation.
⬢[pcarr@toolbox ~]$ sudo dpkg --add-architecture i386
⬢[pcarr@toolbox ~]$ sudo apt update -y
⬢[pcarr@toolbox ~]$ sudo apt clean all
⬢[pcarr@toolbox ~]$ sudo apt install -y -qq rsync x11-utils
⬢[pcarr@toolbox ~]$ sudo apt install -y -qq --no-install-recommends \
gcc wget \
build-essential \
tofrodos gawk xvfb \
tftpd git make python3 update-inetd \
net-tools libncurses5-dev zlib1g-dev libssl-dev flex bison \
libselinux1 gnupg diffstat chrpath socat xterm autoconf libtool \
tar unzip texinfo gcc-multilib libsdl1.2-dev libglib2.0-dev \
screen pax gzip language-pack-en libtool-bin cpio lib32z1 \
lsb-release zlib1g:i386 vim-common libgtk2.0-dev libstdc++6:i386 \
expect less bc libtinfo5 libncurses5
We need to change the default shell from dash to bash:
⬢[pcarr@toolbox ~]$ sudo ln -fs /bin/bash /bin/sh
When we install the tools, we have the option of whether to install them inside the container, or somewhere in the host’s filesystem. Obviously, installing them within the container will make their size bigger, and only available to the running container. If we plan on using these tools among more than one container, then it would make sense to make them available from the host filesystem. Not all the host filesystems are transparently available to the containers, for instance the host’s /opt
directory is available to the container as /run/host/opt
. In this case, we choose to install them within.
The installation directory for Petalinux needs to be accessible by the running user, so we change its permissions accordingly:
⬢[pcarr@toolbox ~]$ sudo chmod 777 /opt
Make the installer executable
⬢[pcarr@toolbox ~]$ chmod u+x petalinux-v2023.1-final-installer.run
Let’s run the installation
⬢[pcarr@toolbox ~]$ ./petalinux-v2023.1-final-installer.run --skip_license --dir /opt/petalinux/
INFO: Checking installation environment requirements...
INFO: Checking free disk space
INFO: Checking installed tools
INFO: Checking installed development libraries
INFO: Checking network and other services
INFO: Checking installer checksum...
INFO: Extracting PetaLinux installer...
INFO: Installing PetaLinux...
INFO: Checking PetaLinux installer integrity...
INFO: Installing PetaLinux SDK to "/opt/petalinux/."
INFO: Installing buildtools in /opt/petalinux/./components/yocto/buildtools
INFO: Installing buildtools-extended in /opt/petalinux/./components/yocto/buildtools_extended
INFO: PetaLinux SDK has been installed to /opt/petalinux/.
That’s Petalinux 2023.1 installed inside the toolbox container. In order to use it, the settings script must be sourced beforehand:
⬢[pcarr@toolbox ~]$ source /opt/petalinux/settings.sh
PetaLinux environment set to '/opt/petalinux'
WARNING: This is not a supported OS
INFO: Checking free disk space
INFO: Checking installed tools
INFO: Checking installed development libraries
INFO: Checking network and other services
A sharp-eyed reader may notice the warning message above “not a supported OS”. Petalinux probably uses some criteria to decide what is a supported OS that toolbox does not handle. For instance, the running kernel is still Fedora’s (i.e. the host’s) as seen below noted as “fc38”:
⬢[pcarr@toolbox RTX16-2023.1-toolbox]$ uname -a
Linux toolbox 6.8.9-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 2 18:50:49 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Test run
We will clone our favorite project and run the Petalinux build on it.
⬢[pcarr@toolbox Petalinux]$ git clone <Gitlab-URL> RTX16-2023.1-toolbox
Cloning into 'RTX16-2023.1-toolbox'...
done.
⬢[pcarr@toolbox RTX16-2023.1-toolbox]$ cd RTX16-2023.1-toolbox
⬢[pcarr@toolbox RTX16-2023.1-toolbox]$ petalinux-config --silentconfig
[INFO] Sourcing buildtools
[INFO] Silentconfig project
[INFO] Silentconfig rootfs
[INFO] Generating workspace directory
[INFO] Successfully configured project
⬢[pcarr@toolbox RTX16-2023.1-toolbox]$ petalinux-build
INFO: bitbake petalinux-image-minimal
NOTE: Started PRServer with DBfile: /home/pcarr/Petalinux/RTX16-2023.1-toolbox/build/cache/prserv.sqlite3, Address: 127.0.0.1:44695, PID: 14212
Loading cache: 100% |############################################| Time: 0:00:00
Loaded 6266 entries from dependency cache.
Parsing recipes: 100% |##########################################| Time: 0:00:01
Parsing of 4353 .bb files complete (4334 cached, 19 parsed). 6285 targets, 296 skipped, 1 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
<Large Snip>
NOTE: Tasks Summary: Attempted 4435 tasks of which 3444 didn't need to be rerun and all succeeded.
Summary: There was 1 WARNING message.
INFO: Failed to copy built images to tftp dir: /tftpboot
[INFO] Successfully built project
Creating a new container image
Now that we’re confident that our container instance is fully configured and working as intended, we can optionally generate an immutable image from the mutable container. We do this to be able to share this image, back it up, or push it to an image registry.
Conclusion
In this post, we showed a possible way to install Xilinx tools without disrupting the host OS system. This could be used as we showed, to install tools on an unsupported distribution, but it would also be useful to test development flows in other distributions, or newer versions of the same host distribution. In this latter case, while I’m running Fedora 38 and plan to upgrade to Fedora 40, I can simply create a Toolbox container with Fedora 40 and test how the tools would perform in it, before going through a system-wide upgrade cycle.