In a previous blog post (https://mab-labs.com/index.php/2021/09/16/nvidia-bsp-based-on-openembedded-the-yocto-project/), we identified a board support package (BSP), which is based on the OpenEmbedded/The Yocto Project and available on Github at https://github.com/OE4T/tegra-demo-distro. This BSP can be used to run Linux on a board that uses a SoM running a Nvidia processor. In the blog post that is linked above, we built and loaded the BSP on the Jetson Nano Development Kit (https://developer.nvidia.com/embedded/jetson-nano-developer-kit).
In this blog post, we are going to discuss how to lay the foundation to support customizing the BSP referenced above. Since the reference BSP uses multiple git repositories, we’re going to have to decide to use either “git submodules” or “repo” to manage these repositories, based on the advantages and disadvantages outlined in a future blog post. Although git submodules would be the obvious choice since that is what the reference BSP uses to manage multiple git repositories, we’re actually going to use the “repo” tool.
First, we’ll need to create the manifest file that “repo” will use to clone the relevant repositories. We will need to create a repository to track the changes to the manifest file. MAB Labs has created a repository for reference purposes on Github at https://github.com/mbilloo/repo-tegra. The manifest file itself is called “default.xml”.
We can use the reference BSP to determine which repositories we will need to include in the manifest file, by looking at the repository on Github (make sure to select the “dunfell-l4t-r32.5.0” branch)::
The above figure shows the different repositories along with the hash of the commit of where they are checked out in the top-level repository. We don’t need all of these repositories, since some of them are responsible for ancillary functionality. The repositories that we will focus on are:
However, these are abbreviated hashes and cannot be used in the repo manifest file. Instead, we will need the complete commit hash of each repository. For the “meta-tegra” repository, which is on Github, this process is straightforward. We can simply click on the referenced repository, which will open the repository in the browser at the referenced commit. We can then click on the shortened commit hash, which will open a complete list of changes for that commit along with the complete commit hash. The following image shows this process.
Thus, we will have the following entries in the manifest file for the “meta-tegra” repository:
<remote fetch="https://github.com/OE4T/" name="meta-tegra"/> . . . <project name="meta-tegra" path="sources/meta-tegra" remote="meta-tegra" revision="620e1b5479fd2fbb64676d801b4043f956fe8e71"/>
For the repositories that are not on Github, such as “poky”, we need to first clone the repository locally and determine the complete hash by searching through the local copy of the repository. We can determine the URL of the repository by searching the “.gitmodules” file. For the poky repository, we can see that the URL is “git.yoctoproject.org/poky”:
Since we are not going to push any changes to the upstream poky repository, we can use the HTTPS URL instead of the SSH URL. We can determine the HTTPS URL, by first navigating to git.yoctoproject.org in a browser, clicking on the “poky” project, and taking note of the HTTPS URL under the “Clone” section at the bottom of the page:
We can clone the repository locally and use the “gitk” tool to determine the complete hash of the referenced commit:
In turn, the manifest file will have the following entries for the poky repository:
<remote fetch="https://git.yoctoproject.org/" name="yocto"/> . . . <project name="git/poky" path="sources/poky" remote="yocto" revision="74b22db6879b388d700f61e08cb3f239cf940d18"/>
We will make sure to exclude the layers that comprise the crux of the “tegrademo” repository. Instead, we will create two separate repositories. One repository will consist of the necessary BSP configuration and initialization files, and the set of recipes that will comprise the custom BSP. The other repository will be a clone of the “meta-tegra-support” layer in the reference repository.
MAB Labs has created the core repository on Github at https://github.com/mbilloo/mab-tegra. There repository consists of the following directories:
. ├── conf │ └── distro ├── recipes-core │ ├── images │ └── packagegroups └── scripts
The “conf” directory has the following files:
├── bblayers.conf.sample ├── distro │ └── tegrademo.conf ├── layer.conf └── local.conf.sample
“layer.conf” describes the properties of the meta-mab-tegra layer. “bblayers.conf.sample” outlines the layers that bitbake will search to find any necessary recipes. “local.conf.sample” was simply copied over from the build directory from the reference BSP.
Since the final image uses a custom “tegrademo” distro, we will need to copy over the “tegrademo.conf” file from the reference BSP to our custom layer. This will allow us to freely modify the distro parameters as needed.
The “scripts” directory has a single script called “setup.sh”. The purpose of this script is to appropriately configure the build environment. We will later see how we can add the appropriate entries in the repo manifest file to place this script in an appropriate location.
The “images” directory contains the “demo-image-base.bb” recipe and “demo-image-comon.inc” files. The “demo-image-common.inc” file will need to be modified to exclude the “packagegroup-demo-basetests” package. This is because the packagegroup-demo-basetests package contains test applications that are not necessary. If we wish to add this package at a later time, we can copy over the recipe that builds this package and reference this package in “demo-image-common.inc”. The “packagegroups” directory contains the recipes to build the packagegroups referenced in the image recipe.
We will also need to create a repository that mirrors the contents of the “meta-tegra-support” layer, since certain classes and recipes are needed from this layer. However, since we can’t separate the layer from the “tegra-demo-distro” repository, we will have to create our own repository to track this layer. A Github repository at https://github.com/mbilloo/mab-tegra-support has been created for reference purposes.
To wrap up, we need to add these two repositories to our repo manifest file. We will have a single “remote” entry for the base repo URL, and separate “project” entries to reference the individual repositories in this base Github URL. Finally, the entry for the “mab-tegra” project will contain entries to create a symbolic link of the “setup.sh” file, which we mentioned earlier. The final manifest file will resemble the following:
<?xml version="1.0" encoding="UTF-8"?> <manifest> <default sync-j="2"/> <remote fetch="https://git.yoctoproject.org/" name="yocto"/> <remote fetch="https://git.openembedded.org/" name="oe"/> <remote fetch="https://github.com/OE4T/" name="meta-tegra"/> <remote fetch="ssh://email@example.com/mbilloo" name="mab-tegra"/> <project name="git/poky" path="sources/poky" remote="yocto" revision="74b22db6879b388d700f61e08cb3f239cf940d18"/> <project name="meta-openembedded" path="sources/meta-openembedded" remote="oe" revision="2e7e98cd0cb82db214b13224c71134b9335a719b"/> <project name="meta-tegra" path="sources/meta-tegra" remote="meta-tegra" revision="620e1b5479fd2fbb64676d801b4043f956fe8e71"/> <project name="meta-tegra-community" path="sources/meta-tegra-community" remote="meta-tegra" revision="75949fa5c5c11b7c9eebe2c374ba9b517a073604"/> <project name="git/meta-virtualization" path="sources/meta-virtualization" remote="yocto" revision="9e9868ef3d6e5da7f0ecd0680fcd69324593842b"/> <project name="mab-tegra-support" path="sources/meta-mab-tegra-support" remote="mab-tegra" revision="main"/> <project name="mab-tegra" path="sources/meta-mab-tegra" remote="mab-tegra" revision="main"> <linkfile src="scripts/setup.sh" dest="setup.sh"/> </project> </manifest>
In summary, we described a process that MAB Labs has used to customize a Nvidia board support package (BSP). This process has allowed us to use a baseline BSP and add our own modifications, allowing us to create and build an image with our own packages and customizations.