Should I go the Yocto route?

Technical Support
, ,
1

Hi,

We bought an iMX8MP module and the Verdin Development Board to be able to develop an embedded system for our project. When succeeding we will create our own carrier hardware for the SOM.

But I’m stuck. And I do not know anymore what to do.

For weeks I tried the container route. But without success. And I do not like the added complexity. A development environment should be as simple as possible with short iteration times. Containers are (for us) not the way to go. I do not want to spend my time on getting the development environment to work and keep it working. I want to develop a new embedded system.

So we probably need to go the Yocto route. But I’m not an experienced Linux user. Will that be doable? And can we do with a Yocto based Linux what we need to do?

There are many questions:

1: I assume Yocto is Debian based? Does it come with a package handler?
2: Does it come with a graphical user interface? Or is it terminal only?
3: Is it wise to go the Yocto route when not having much experience with Linux?
4: Can we install and run Visual Studio Code on the target?
5: When using OpenCV, does the imshow() function work?
6: Are USB cameras supported?
7: I would consider cross compilation. Can that be done with short iteration times?

Maybe some questions do not make sense, but remember that I do not have much experience with Linux based systems.

2

Just one opinion:

1: Yocto is mostly a bunch of recipes and application which parses this recipes. Recipes are a some kind of definition how to build packages and full image which you can flash to a board. Yocto runs on every distribution (Debian, Ubuntu, …).
2: AFAIK terminal only.
3: IMHO no, it takes some time to understand the involved tools, and then too understand the specific parts you have to modify. Most companies I worked for, they often hire people with the specific Yocto knowledge they need.
4: The details depends on which version you are going to use. But in general the answer is yes.
5: If you have a display server running yes. If you use e.g. weston as display server, you can configure it to work without a display and just connect via RDP.
6: Depends on the camera and if a driver is available for arm64 (iMX8MP is arm64), but nowadays the answer is often yes.
7: If you write your application Python or .NET then you don’t have to cross compile. If it’s C/C++ its a bit more involved, but nowadays documented very well. IMHO I would develop the application fully on your host, ideally a Linux, which gives you much faster edit-compile-run cycles, and then as a first step just compile in on the target (with containers, you just spin up a Ubuntu container on your target, install build-essential and your fine to go).

Related to the container solution. IMHO it was an amazing idea to use container from Toradex (I don’t work for Toradex). This simplifies everything enormously. You can mix and match even different Linux distributions if there would be a neccesitty. E.g. .NET from Microsoft for arm64 is not provided as Debian package just a raw tar.gz or as a container. I understand that you may have some issues, but the more you understand about containers, the better, it will help you solve many many other problems. Especially they give you a much more predictable development environment. Now, it’s not that I am docker/podman fanboy, they have downsides, issues, problems. But IMHO I would reconsider your approach especially as a beginner. Compared to Yocto, containers are trivial IMHO.

1 Like
3

I was affraid for that.
So Yocto is not the way to go.

I whish Toradex had a ready to go Ubuntu or Debian. After weeks trying to get this container stuff to work I’m at the edge of giving this whole thing up and go back to Jetson or so. I want to program my application! This is so frustrating.

4

But AFAIK this should be easily possible (I never tried their image, due to some requirements from the company I work for). You take the Toradex image and as a first step you just execute

docker run -it debian:bookworm

And you can do whatever you want inside this container.

5

The container is not persistent isn’t it?
So I have to reinstall all tools and load development data each time I run this.

6

It is persistent, just does not have a easy to remember name, add the --name parameter to give it name, you later than can start/stop it with docker container start/stop and go into it again with docker exec. You can also map a directory from outside your container into the container and e.g. leave the source code outside and just compile inside. In this case the persistent stuff is always outside the container.

Just for information: Some people believe containers are some magic and by definition add a lot of overhead. This is not true. There exist a few papers also about this. It would be even quite simple to implement your own super simple docker in C, which can even use the existing docker/podman containers.

IMHO it is really worth to play with it on your Ubuntu/Debian computer first. Spin up a Ubuntu container, inside your Ubuntu, play with it, install, remove things inside the container, stop the container, start it again. This knowledge is invaluable for other things to come which has nothing to do with Toradex e.g. setting up a continuous integration pipeline.

1 Like
7

Hello @simmania

I do work for Toradex but the comments are my own opinions.

I agree with the comments about Yocto being complicated and definitely more complicated than the container approach. Just to clarify though, Yocto is a distribution builder and can build a custom distro based on your needs; it just has a steep learning curve to do so. It is not a direct comparison to any of the desktop-style distros and is essentially a fully cross-compile environment.

I would be interested to hear the issues you had with containers so we can improve in areas where we may be falling short. As @thomasstauffer said, there is for the most part no runtime overhead simply do to the fact of containers; container processes are standard Linux processes scheduled up by the normal kernel scheduler. They just have some extra bits set in the task control block to limit their visibility into OS-provided resources. There is some initialization overhead and likely some storage overhead but once the processes inside the containers are running, they are just standard processes. That said, you can write good or bad code inside them just like you can natively.

It’s largely true that the containers are not persistent. They will stick around but can be removed and you will lose your date. But there are better solutions than just making changes inside running containers. The basic idea is to make a custom container image containing your application, libraries, etc, and then you use a docker volume to store your user/persistent data. The advantage of this is that the custom image can be run on multiple devices and will already have your bits; no need to mess around installing using apt-get from within the container.

As for running straight-up Debian or Ubuntu, I’m sure that can be done but we don’t provide an out-of-the-box solution for it. For connected/embedded device fleets, it does not scale well and it is difficult to create and maintain your starting images and do things like OTA updates and the like. We think our Torizon system brings the best of both worlds and does a good job mitigating the issues with each approach.

Hope that helps.

Drew

3 Likes
8

I have been working with the Yocto Project for over 13 years pretty much since the beginning. I have also developed the Linux Foundation’s first course on the Yocto Project and taught the class may times. What I have learned from the classes I eventually distilled into a book on the subject. Fair enough, I might be a little biased.

Building a Linux distribution from scratch is not a trivial undertaking. It is very much the “secret” sauce of the distribution builders such as RedHat, Ubuntu, SuSe, etc. The difficult and time-consuming part of maintaining a Linux distribution is the dependency handling and keeping up with CVEs and other improvements.

When building a custom Linux distribution for an embedded device, you essentially have two choices:

  • top-down
  • bottom-up

Top-down means you are taking a distribution and the packages the distribution builder creates and modify it to your requirements. That to some extend alleviates you from the tedious maintenance tasks. But you have to come up with a way to modify the distribution to your requirements: install additional packages, remove packages that you don’t need (without breaking dependencies), build and install packages that are not available from upstream, etc. You are also faced with the problem of creating the distribution for your target architecture: most distributions are built and optimized for x86(_64). Yes, some distros now also provide ARM and aarch64 package feeds but because of the diversity of ARM SoCs you will still need to build the kernel and bootloader for your target.

With bottom-up you are in full control but you are the distribution builder and the burden of maintenance is on you (together with the burden of dependency management, cross-building, etc).

I have done both in the past with different tooling. Now I am using exclusively the Yocto Project as it offers me the best of both worlds: a maintained set of software packages, toolchains for various architectures, and blueprints for various systems (which I don’t use anymore since I have created my own catalog).

In response to @simmania 's questions:

1: I assume Yocto is Debian based? Does it come with a package handler?
No, the Yocto Project is not Debian-based. It is building all software packages from source code. You have a choice of package management systems: rpm, dpkg, and opkg.

2: Does it come with a graphical user interface? Or is it terminal only?
Yes, there is a web-based UI called toaster which allows you to configure and execute builds.

3: Is it wise to go the Yocto route when not having much experience with Linux?
The Yocto Project is only the build system that creates a custom Linux OS stack. The more fundamental question is if it is wise to use Linux for an embedded system project without having much experience with Linux? There are a gazillion reasons why Linux is great for embedded systems which is why it has become the leading OS for embedded applications that require full OS stack capabilities. However, you need to be willing to go through the learning curve regardless on how you build the OS stack for your system. Companies and independent consultants can help you flatten the learning curve and keep you on track with your project. Shameless plug: that is what my company and I do for our customers.

4: Can we install and run Visual Studio Code on the target?
That mostly depends on your target. While the Yocto Project will most likely provide all the dependencies required for VS Code, there is no recipe that can build VS Code. However, downloading VS Code and installing it on a target built with YP can probably be made working. I have not tried it myself.
On-target development is traditionally not common for embedded systems as they often lack the resources to do so. Hence, the YP can build an SDK that allows cross-development on an x86_64 Linux system. That SDK can be integrated with VS Code and others such as Qt Creator. I am doing all my YP development with either one of them (or both dependent on the project).

5: When using OpenCV, does the imshow() function work?
OpenCV is fully supported by YP. It is part of the meta-oe layer.

6: Are USB cameras supported?
Yes, no different from any Linux distro.

7: I would consider cross compilation. Can that be done with short iteration times?
YP always does cross compliation. It creates the toolchain it builds with itself. That is also true when the target is an x86_64 system. How long builds take depends on the size of the target system and the build system you have available. A full initial build may take 30 minutes or more. For subsequent builds only packages that need to be rebuilt (for various reasons) are being built. The Yocto Project (or more precisely the bitbake engine behind it) does a very good job at dependency handling and reusing pre-built artifacts. There is also something that is called a shared state cache (I won’t go into details, there is a lot to it). Using the SDK with the Yocto Project devtool allows you to build the software you are working on on your build system and deploy it to a YP remote target via network, run it as well as debug it.

A quick word on containers: We are using containers on top of YP systems for different reasons. But to run a container you still need a base system. That we build with the YP and include the container tools we need. There are many reasons why doing this. One is that developers can work in a container environment for development on their dev system. The container is then used on the target system (often with a different architecture). Developers can use container tools rather then YP tools. It depends on what you are looking for.

5 Likes