Yocto has a steep learning curve, it can take months to get a handle on the ins and outs. Knowing a few simple techniques that can be used to cut down on wasted time and streamline a Yocto workflow can be extremely helpful.
When a developer faces a challenge or error that hasn’t been seen before, their instinct is often to Google the problem, hoping for a Stack Overflow post similar to the situation they are facing. Under normal circumstances this is often a quick way to find a solution, or at least find a post from a person with a similar problem.
However, when dealing with Yocto this problem-solving technique can cause more difficulties than solutions.
There are significant differences between Yocto versions that will render anecdotal solutions ineffective. Furthermore, many forum post solutions are not robust and will introduce bugs or uncertainty into a meta-layer. The best way to solve a new Yocto problem is to read the Yocto Mega-Manual that corresponds to the specific version of Yocto you are building with. The Yocto development team has done an excellent job of documenting their work, including examples that may elucidate the solution.
Understanding Yocto as a system can guide you in avoiding minor errors that pop up due to misunderstanding the Yocto workspace and its requirements. Again, reading the Mega-Manual is a solid recommendation for gaining that deeper understanding.
Devshell is an underutilized tool that can be very helpful while debugging packages or recipes. Often, error messages produced by Yocto are difficult to decipher, especially when dealing with hairy packages like u-boot. Devshell allows you to run commands like make menuconfig in an environment set up specifically for the package that is being tested.
It makes it much easier to debug when you don’t have to read through bitbake error logs. For example, if debugging u-boot, executing bitbake u-boot -c devshell will deposit all the u-boot source code into a directory, apply all patches included in the recipe, and then open a terminal in that directory.
Shell scripts are extremely helpful and make life simpler in many ways. Some complex tasks that are easily executed on a running Linux OS require utilities that can be difficult to utilize during the many stages of a Yocto build. Including a package post install script in your recipe can allow execution of shell scripts during the image packaging, before the system boots for the first time.
Package post install scripts are easy to add to any recipe:
The Yocto build process builds all packages in a distribution from source, including the Linux kernel. If you wish to update the source code for the Linux kernel, or any other package, before it is built, a patch must be created and applied via a recipe or bbappend. The process of creating a patch and recipe can be time-consuming, and if you are in the process of actively developing the package in question, many iterations of patches leads to a great deal of wasted time. This can be remedied by adding a local source to local.conf.
Adding the following lines to your build/conf/local.conf will allow you to use a local source directory to build your package. Any updates you make will be included immediately without the need to create or apply a patch. When you are satisfied with your work, a final patch set can be created and applied to the recipe.
Yocto is a deep, confusing system that is easy to get lost in. There are many resources available to a developer that will help navigate the Yocto universe.
Often, the best resource is someone who has already dealt with the intricacies of Yocto. DornerWorks engineers are experienced in Yocto wrangling, we love making using Yocto straightforward and easy for our customers. If you’re looking to use Yocto to build a custom embedded Linux distribution for your next product and are looking for some guidance getting started, let us know.