# meta-tegra: a Yocto BSP layer for the NVIDIA Jetson modules > meta-tegra is the OpenEmbedded and Yocto board support package layer for NVIDIA Jetson modules, tracking a specific Jetson Linux and JetPack release pair, with recipes split by area from kernel and graphics to security and devtools. It is an OE4T project, MIT licensed, and it is where you look when you want to build your own Linux distribution for a Jetson rather than install the vendor image. **OE4T/meta-tegra** — BSP layer for NVIDIA Jetson platforms, based on L4T - Repository: https://github.com/OE4T/meta-tegra - Website: https://oe4t.github.io - Stars: 582 · Forks: 322 - Language: BitBake - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/oe4t-meta-tegra ## One layer, one L4T release, one JetPack release meta-tegra is an OpenEmbedded and Yocto BSP layer for NVIDIA Jetson modules, and the readme is explicit about the versions it tracks. Jetson Linux release: R39.2.1. JetPack release: 7.2.1. That pairing at the top of the readme is the most important thing in it, because a BSP layer is not a floating library. It encodes the firmware, the kernel, the device tree and the userspace for one specific combination of the vendor's release train, and a layer that claims a different L4T or JetPack is a layer that will not boot. The readme points at a release notes page for the JetPack 7.2.1 and L4T R39.2.1 pair, which is where the changes in that release are described. The layer also declares what it depends on. The URI is the OpenEmbedded core layer at git.openembedded.org, the branch is master, and LAYERSERIES_COMPAT is blacksail, which is the compatibility string that Yocto uses to check that a set of layers is coherent with each other. The primary language of the repository is recorded as BitBake, which is the metadata language Yocto uses to describe recipes. A layer is a directory of .bb and .bbappend files plus configuration, and the layer here is large, with the top level holding recipes-bsp, recipes-core, recipes-devtools, recipes-graphics, recipes-kernel, recipes-multimedia, recipes-security and recipes-support, along with conf for the build configuration, lib and external for shared and third party content, classes and classes-recipe for reusable recipe logic, and a postinst-intercepts directory for the post installation hooks that a device image needs. The documentation is published in two forms, a documentation site at oe4t.github.io and Markdown in the docs directory of the repository, and the repository also carries a book.toml, which is the configuration for a mdBook. ## The supported board list is the part to check first Not every Jetson module and carrier combination is supported, and the list in the readme is short enough to read in full and specific enough to act on. The supported boards are the Jetson AGX Thor development kit, the Jetson AGX Orin development kit, the Jetson Orin NX 16GB with the part number p3767-0000 in the Xavier NX p3509 carrier, the same Orin NX 16GB in the Orin Nano p3768 carrier, the Jetson Orin Nano development kit, and the Jetson AGX Orin Industrial 64GB, part number P3701-0008, in the Orin AGX P3737 carrier. Two things are visible in that list. The first is that the entries are module and carrier pairs, not modules. A Jetson Orin NX module in a different carrier is not the same configuration, and the readme does not list it. The second is that the part numbers appear, which tells you the layer is tested against specific hardware revisions rather than against a product name. That distinction is what makes a BSP layer a support commitment. A board that is not listed is not one the maintainers build and test against, so a failure on it is a failure on unsupported hardware with no upstream fix likely to arrive. The developer kits and the Industrial 64GB module are the entries a commercial deployment would care about, and the two Orin NX 16GB entries are the ones a developer with the common module would look for. The AGX Thor entry indicates that the newest module generation is covered by this release of the layer, which is a reasonable signal that the layer is tracking current hardware rather than a frozen configuration. ## Recipes split by area, which tells you where to look The directory layout is the fastest way to understand what the layer actually contains, and the split is by functional area rather than by package. recipes-kernel holds the kernel side, recipes-graphics the graphics stack, recipes-multimedia the media and codec pieces, recipes-security the security related packages, recipes-devtools the developer tooling, recipes-support the general support packages, and recipes-core and recipes-bsp the core and board specific content. There are also a classes-recipe directory and a classes directory, which hold the reusable recipe logic, and an external directory for content fetched from outside the layer, plus a lib directory for shared assets. The separate postinst-intercepts directory is worth noting because it is a mechanism specific to these images. Post installation intercepts are scripts that run at a controlled point during the first boot of a device image, which is where a Jetson device image needs things like expanding the filesystem, setting up the correct device permissions and configuring the bootloader, and the fact that the layer ships those as a distinct directory rather than burying them in individual recipes means the boot-time behaviour is auditable in one place. There is a docs/ directory with the release notes and the documentation, a build/ and deploy/ style separation is not present here, but there are .github/ directories for the workflows, an AGENTS.md, a CONTRIBUTING.md, a SECURITY.md and a LICENSE file, so the repository has the same governance files a modern project would carry. The Image recipe, if there is one, would sit in one of the recipes directories and is what the build actually starts from, and a machine configuration in conf/ is what tells the build which packages and which board to produce. Those two files are the entry points for anyone who wants to build an image rather than just read the layer. ## What to read before you build, and where the answers are The readme points at a release notes page for the exact L4T and JetPack pair the layer tracks, and it is the right first stop for anyone about to build. The reason is specific to this kind of project. A BSP layer is a set of instructions for constructing a distribution, and the layer itself is not the distribution. When a build fails, the cause is usually one of three things: a layer version mismatch, a machine configuration that does not match the board, or a change in the vendor release that the layer has not yet caught up with. The release notes tell you which of the three you are looking at, because they describe what changed in that release. The documentation is available in two places, the documentation site and a Markdown directory in the repository, and the repository also has a book.toml, which suggests the site is built from a book format source. The release notes live in a docs/release-notes directory with a file named for the version. The build configuration lives in the conf directory, and the recipes that make up the image live under the recipes directories. A build is driven by pointing a build directory at the layer and the layers it depends on, and the LAYERSERIES_COMPAT value in the readme is the check that the set is coherent. If the compatibility string does not match what your build environment expects, the build stops before it starts, which is the cheapest possible failure. For general questions the Discussions tab is the place, and the Q and A category in particular is where a build setup question belongs. The readme asks people to include branch and version information when reporting problems, which is consistent with a project where the layer version and the L4T version are the two facts that determine whether an answer is useful. ## Where to ask, and how the project wants issues reported The readme is unusually specific about the support channels, and the detail is worth reading because it saves a wasted email. For general build issues or questions about getting started with a build setup, the readme points at the Discussions tab of the meta-tegra repository, and it then splits that into four categories. The Ideas category is for anything you would like to see included in the layer or in the wiki content. The Q and A category is for questions about the layer and the recipes. The Show and Tell category is for projects you would like to share that relate to the layer. And the General channel is for anything that does not fit the categories above and does not relate to a build or runtime issue with Yocto or OpenEmbedded builds. That last distinction is doing real work. A category for questions and a separate category for things that are not questions or build issues means the signal from a user report is not diluted by everything else, and the four way split tells you where a given question actually belongs. For bugs, the readme points at the Issues tab of the meta-tegra repository and asks for as much environment information as you can, for example the target hardware you are building for and branch or version information, and it asks you to fill in the provided bug template. There is also a note about e-mail that is worth reading. The project says it is required to provide an e-mail address, but asks that you use GitHub as described above instead of sending e-mail to the address. That is a deliberate funneling of support into a searchable place, and it is a reasonable ask, though it does mean that a question asked and answered by e-mail is a question the next person cannot find. Contributions go through CONTRIBUTING.md, which the readme points to for information on submitting patches to the maintainers, and it closes with a simple note that contributions are welcome. ## Conclusion meta-tegra suits a team that needs to build a custom Linux distribution for a Jetson module and therefore needs the BSP layer rather than the vendor image, and it suits anyone who wants a Yocto build they can reproduce and modify. It does not suit someone who only wants to run the prebuilt JetPack image, and it does not suit a team unwilling to keep up with the release cadence, because the layer tracks a specific L4T and JetPack pair and moves with it. Before building, read the release notes for the version in the readme, confirm your carrier and module combination is on the supported board list, and use the GitHub Discussions tab for build questions rather than the discussion forum the readme mentions as deprecated. ## FAQ ### What is meta-tegra? It is the OpenEmbedded and Yocto board support package layer for NVIDIA Jetson modules, an OE4T project with a homepage at oe4t.github.io. The layer tracks a specific pairing of Jetson Linux release R39.2.1 and JetPack release 7.2.1, and depends on the OpenEmbedded core layer with the blacksail layer series compatibility string. ### Which Jetson boards does meta-tegra support? The Jetson AGX Thor development kit, the Jetson AGX Orin development kit, the Jetson Orin NX 16GB, part p3767-0000, in the Xavier NX p3509 carrier and in the Orin Nano p3768 carrier, the Jetson Orin Nano development kit, and the Jetson AGX Orin Industrial 64GB, part P3701-0008, in the Orin AGX P3737 carrier. ### Where do I ask a question about building meta-tegra? Use the Discussions tab of the meta-tegra repository. The Ideas category is for features you want in the layer, Q and A is for questions about the layer and recipes, Show and Tell is for related projects you want to share, and General is for anything that is not a build or runtime issue. ### How do I report a build or runtime bug in meta-tegra? Open an issue on the meta-tegra repository, include as much environment information as you can, such as the target hardware and branch or version information, and fill in the provided bug template. The project asks that you use GitHub rather than sending e-mail to the questions address. ## Sources - [Issues](https://github.com/OE4T/meta-tegra/issues) - [License: MIT](https://github.com/OE4T/meta-tegra/blob/master/LICENSE) - [OE4T/meta-tegra on GitHub](https://github.com/OE4T/meta-tegra) - [Project website](https://oe4t.github.io) - [README](https://github.com/OE4T/meta-tegra/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oe4t-meta-tegra