Differences between using Yocto Project and Jetpack?

Hello everyone,

I’m currently exploring different software development platforms for our embedded system project, and I’m specifically interested in understanding the differences between the Yocto Project and JetPack. I’d appreciate any insights or experiences you can share on this topic.

From my understanding so far:

  • Yocto Project is a versatile build system for creating Linux distributions for embedded systems and IoT devices. It supports various hardware architectures and allows for customization and selection of software components based on specific use cases. It offers flexibility in terms of hardware support and can be used for a wide range of applications.

However, as far as I know, the current Yocto supports is driven by a third party “driven by community”. Also, I found that for instance NVIDIA DriveWorks SDK as Yocto component is not supported.

For me, this is the kind of things that I can expect if the Yocto is not officially supported by NVIDIA.

  • JetPack, on the other hand, appears to be a software development platform developed by NVIDIA specifically for their Jetson family of embedded systems. It focuses on AI and machine learning applications and provides optimized software components, libraries, and drivers for NVIDIA Jetson devices. It seems to offer a streamlined development workflow and integration with NVIDIA’s GPU capabilities for accelerated AI workloads.

I would like to hear from those who have experience with either or both of these platforms. What are the key differences you’ve observed? When would you recommend using Yocto Project over JetPack, or vice versa? Are there any specific advantages or limitations of each platform that I should consider?

We can expect what we can do with Yocto. However, we are not able to fully understand what we cannot do using Jetpack. Or choosing Yocto over Jetpack what we will not be able to do it (Like DriveWorks SDK). Are there any plans for supporting Yocto officially?

I found this experience: Device Tree Differences between OE4T and JetPack?

Thank you in advance for your insights and help!

Best regards,

We don’t have plan to support Yocto currently, however our partner does, please visit Yocto Support for NVIDIA Jetson Platforms - Yocto Support for NVIDIA Jetson Platforms - Setting up Yocto - RidgeRun Developer Connection

Hello @kayccc

Thanks for you answer. I cheked that out. However, I would like to know if there is any limitation on using that approach like I said with DriveWorks SDK. The idea is trying to understand what we got if we chose Jetpack over Yocto or viceversa.

Thanks in advance.

FYI, “Linux for Tegra” (“L4T”) is purely Ubuntu, but then has NVIDIA drivers added on top of it. The “sample root filesystem” download (which JetPack/SDK Manager installs to “Linux_for_Tegra/rootfs/”) is purely Ubuntu. The “sudo ./apply_binaries.sh” step is what adds the NVIDIA driver content, and it is then that it becomes L4T (and L4T is what gets flashed).

Anything “Drive” is for different hardware.

In the most recent releases for Orin, L4T is Ubuntu 20.04 LTS. All of the boot content is tailored for that. In theory, any o/s you put in “Linux_for_Tegra/rootfs/” could be flashed. The question is whether non-NVIDIA content would actually function. Any such content would need to accept the inherited boot environment and probably have some of the NVIDIA drivers. Certainly you’d need the correct GPU driver if you are to use CUDA or AI. Yocto is sort of a modular method of creating such an installation.

Thanks for your detailed explanation. I think that it is now more clear to me.

In the end, we would like to keep consistency with the drivers/libraries that are provided by NVIDIA. We were afraid that as Yocto is not officially supported by NVIDIA there could be a problem with certain packages. Also, another “issue” could be related with features that are provided by the official image like A/B OTA. So, it seems to us like that this image could be use in production. So, why trying to re-implement again the same mechanisms that the official image has and we want to get.

As far as I see there are use of case where it seems more modular to use Yocto, like if we need to make changes in bring up a custom carrier board (I know that this is also possible using L4T). However, if there are few functionality at carrier level it seems to me that it seems better to use the custom image.

What we would like is to utilize as much as possible the mechanism used in the official image without losing the capabilities provide by NVIDIA like libraries CUDA/AI and tools. It is the initial reason of my post. Trying to understand as much as possible the differences between these approaches.

Regarding the DriveWorks SDK sorry for my misunderstanding. You are right, this is NVIDIA DRIVE AGX Orin oriented.

For Drive, see:
https://forums.developer.nvidia.com/c/autonomous-vehicles/517

More specifically, for Drive AGX Orin:
https://forums.developer.nvidia.com/c/autonomous-vehicles/drive-agx-orin/636

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.