I recently had the opportunity to use Yocto. I already practiced quite a lot with OpenEmbedded before. You can see Yocto as a project derived from OpenEmbedded even it is a bit more than that.
In fact, Yocto is made of Poky (a build system based on OpenEmbedded), a few added build tools (swabber, pseudo, etc.), as well as a set of meta data allowing to create embedded distributions for a number of targets.
The strength but also the weakness of OpenEmbedded is that it a very flexible build system. It can make production root filesystems, but also a complete distribution with its ready to use package repository, and this for multiple hardware platforms. It makes it a difficult system to get started and get efficient with. Even two years ago, the OpenEmbedded documentation contributed to making it difficult to get started. Indeed, OpenEmbedded did supply some documentation, but which only started to make sense once you start mastering it. This is quite a paradox for a piece of documentation. It lacked the elements allowing developers to understand its operation well.
With Yocto, I was pleased to realize that substantial progress had been made on this side. The project comes with documentation that is much more exhaustive and above all much more accessible for beginners. Getting started with it is still not completely straightforward, but this time, this is rather because of the complexity and the rich features of the tool.
In a few hours, I managed to develop a minimalistic BSP (Board Support Package) for a given board (in this case a AT91SAM9G20-EK). The concept of layer allows to have a configuration layer specific to a given piece of hardware. You can even support multiple hardware platforms at once and add specific packages. A layer is indeed just a set of packages and configurations (or configuration overrides). The BSP is just a layer specific to one or several pieces of hardware.
As you can see, even to support a simple embedded board, there is already a number of concepts to deal with. There are also multiple ways of achieving the same result but which will be easier or more difficult to maintain. The concept of “BSP” for Yocto is therefore a kind of guideline to allow the Yocto community to have a common point of reference. I will try to illustrate the use of a BSP on the AT91SAMG20-EK board here and/or on my Google+ page.
Another significant progress is optimizing build time for a “minimalistic” target, which went down from more than three hours to just over one hour now. It remains a long time for a very simple target.
To build a filesystem image with only a few components, Buildroot remains much more appropriate. For systems that require a great number of components, more advanced functionality is then often needed, such as managing a package repository and supporting multiple hardware platforms at once for example. In this case, Yocto remains the best (the only?) option, all the more as this project addresses the traditional weaknesses of OpenEmbedded.
Give OpenWRT a try. You aren’t limited to building routers with it. It is loosely based on BuildRoot and also supports repositories. It is way simpler to work with.
Play with one of the platforms that is already defined. If you like it, it is not hard to add a new platform by copying in stuff from other systems.
I’ve worked for a long time with Angstrom. Angstrom is based on Openembedded like Poky, Poky mainly targets Intel’s hardware where Angstrom mainly targets ARM platforms.
Like Poky, Angstrom is now using the concept of layers and BSP. This new organization of package build recipes are more structured than a few years ago, but in my opinion it is much more difficult to see what packages are available than with the old flat organization of recipes. At that time all packages recipes where in the same directory, so it was easy to look at what was available, and so to use it in a rich distribution.
Another point regarding Poky and current Angstrom vs older Angstrom, it seems that with the layers restructuration, there are much less recipes that before. I think that it was a choice to only select very well validated packages, but it is quite frustrating to loose packages that were available sooner.
Hi,
I would like to look into doing something similar for the AT91SAM9G35-EK with yocto.
1) Do you have more detailed instructions on how you did the BSP for the AT91SAM9G20-EK?
2) What kernel/boot loader did you use? Is the anything out there mainline which runs on the sam9?
Regards,
Robert
I am also trying to develop a BSP for a Sam9 board.
If Gregory could make the BSP code available I would find that tremendously helpful.
If you got any further Robert, that would help too
Thanks
Hello,
I would like to know if someone have more details of BSP for the AT91SAM9G20-EK.
Thanks
I’ve worked with Buildroot and Yocto and frankly, would go with Buildroot in a heartbeat over Yocto. In the two times I needed to build Linux from scratch I used Buildroot and managed to have something running in a few hours (Yocto takes about twice as long – which is fine I guess if you are billing by the hour).
New packages are easier to add under Buildroot as well. Total of 14 lines under Buildroot vs. over 100 for Yocto for wxWidgets.
We are currently looking at moving AWAY from Yocto precisely because of the cost issue.
As you’ve probably seen from our contributions, we also like Buildroot very much. Feel free to submit some patches! We for example don’t have a wxwidgets package at the moment.
I prefer builroot as well. I am now reasonably proficient in both. For simple embedded projects buildroot is WAY easier. The recent improvement in buildroot make it easier still. New developers are seeming to get sucked into yocto especially when using digi boards.