Objective: This article presents the system requirements for Yocto development. A physical computer set-up is presented that the author has found highly productive. An initial Yocto build process is presented step-by-step that results in a QEMU capable image.
Recommended prerequisite articles to read:
Its public secret that the Yocto development approach is computationally demanding, at least for initial builds. Nevertheless, this is barely a showstopper for any reasonable laptop or PC. I hereby briefly describe the general options for somebody coming from a Windows PC environment.
The first option is to install a virtual machine (e.g. VMware) into which you install the Linux OS (e.g. Ubuntu). You can then perform Yocto development in the Ubuntu environment. This option will work. However, since you are dividing your computer resources between Windows and Ubuntu, you will get sub-optimal performance of both worlds. While Yocto is running in your Ubuntu side (which can take hours), you may be using your Windows side for other tasks. This is where your frustrations may begin. Even with relatively powerful PCs, things may begin to hang around and freeze; generally making your work anything but smooth.
The second option is to dual boot your machine. So you are either in Linux or Windows; never in both simultaneously. This will work too. The downside is very clear: you are doomed if you need access to both simultaneously.
The third option is how to get optimal performance from both systems simultaneously. I am pretty sure there are many other options out there, which I have no clue about (looking at you Docker and Kubernetes). Nevetheless, I chose to actually physically decouple the two systems; a fancy way of saying I got a second machine (laptop). Whilst this may sound expensive, its not. I ordered a $140 second-hand laptop from Amazon on which I installed Ubuntu and this proved an excellent deal-maker. For comparison purpose, these are the specs of the two machines:
- Asus Laptop
- CPU: Intel Core i5-8300H @ 2.3GHz [4 cores]
- RAM: 8 GB
- OS: Windows 10, 64-bit [VMware Virtual Machine -> Ubuntu]
Ubuntu Machine (used):
- Fujitsu A573/G Laptop
- CPU: Intel Core i3-3230M @ 2.6GHz [2 cores]
- RAM: 4 GB
- OS: Ubuntu 18.04.3 LTS
To gauge the two machines’ performance, I built the default Yocto/Poky image (details later), core-image-sato. With the Windows machine, having installed VMware and allocated it 2 cores; I installed Ubuntu and built this first Yocto image [core-image-sato]. This initial build took 4 hours and 30 minutes.
On the used machine, running Ubuntu only, the same initial build image took 4 hours and 54 minutes.
This initial default image build helps to gauge your system performance. For the flexibility and convenience that the addition of a cheap used laptop offers me, I gladly accept the minuscule decline in performance. This performance is also definitely affected by the internet speeds since the whole Yocto development concept is built on downloading sources from various repositories and building them locally on your machine.
Eventually I added the following elements to achieve a smooth working environment:
- Wireless keyboard and mouse sets. This is simply good.
- HDMI Monitor. I purchased a second-hand HDMI-capable monitor locally. This is actually a TV and also has two HDMI ports. Hence, both laptops are hooked to the same monitor and one can effortlessly switch between the two computers (Windows and Ubuntu) using the accompanying remote. Needless to say, TV is a remote button away. This monitor helped kill three birds with probably no stone (the white cable is the TV aerial cable).
Thus finally, the physical development environment is as shown below.
Combining the physical configuration with cloud services such as Google Drive makes working simultaneously in both systems quite smooth. This has greatly improved on my productivity and ergonomic matters. It’s a relatively cheap set-up with huge returns in my experience.
The above has been a personal set up. The bottom line is: if you have a laptop with a Linux OS (read Ubuntu) and stable internet connection, you are set for Yocto development.
It should be clear to the reader that up to now we haven’t mentioned any need for a physical board such as raspberry pi, dragonboard, zynq etc. This is because the Yocto environment allows you to essentially build and customize not only the OS but also applications for the boards remotely. These will then be bundled into a bootable image which you can load into your target board. Hence you can start off with Yocto project with no physical target board.
In the Yocto Project, there is the “small” issue of which branch to use. Is it jethro, thud, warrior, zeus, ..? The concept of branch is definitely from version control i.e. git, just to clarify. At this point (initial build), this decision is of little consequence. However, its necessary to point out that for real hardware development, the latest stable branch is not usually the optimal choice. Sometimes, for example, the board for which you are developing the custom image may have its Basic Support Package (BSP) not yet supported/tested in the latest Yocto stable branch. This may or may not present huddles in the image development. A rule of thumb is to pick the latest stable branch supported by your board’s BSP. These BSPs and other layers are documented in the OpenEmbedded Layer Index.
It’s important at this point to organize the directories for Yocto Development. This is my recommended structure:
In the root directory, make a directory in which to clone the Yocto/poky branch. You can have sub-directories here to house different branches as your project grows.
Leave the root directory and go to your home directory. Create a directory to house your yocto projects. Here you can have sub-directories to reflect different hardware boards.
This is the structure of my Yocto Environment. These directories are manually created.
Since we will be building images for a variety of boards, the warrior Yocto branch is chosen. This “supports” more boards than the latest which is Zeus at the time of writing. With no further ado, let’s begin.
Go to the warrior directory you created above in the root path and clone the warrior branch:
/yocto /poky /warrior$ git clone -b warrior git://git.yoctoproject.org/poky.git
At this point, you will likely get an error indicating git is not installed (for a new Ubuntu installation). Just run the git installation command and repeat the above command. Otherwise the Yocto/poky will be cloned in this directory as shown below:
At this point, we have no physical board and we just want to build an image that can run on QEMU. Everything we need has been catered for by the cloning in the above step. We want to go with all the default settings and thus we change our directory to poky_defaults.
/yocto/poky/warrior$ cd /home/user/yocto_projects/hardware_platforms/poky_defaults
Here we will create and initialize the build directory. This is where the real magic happens. Its where the Yocto build process takes place. It’s where the final bootable image will be stored as well. This is achieved by calling the Yocto environment script, oe-init-build-env, which is visible in the above image.
/home/user/ … / poky_defaults$ source /yocto/poky/warrior/oe-init-build-env
This sets up the build environment and we can build our first image.
To start the build process, you issue the following command:
/home/user/ … / poky_defaults$ bitbake core-image-sato
If this is the initial build in a new Ubuntu installation, you are likely to get the following errors:
Just install the packages indicated and rerun the bitbake command. The makeinfo is substituted with the texinfo whilst the last package is not critical.
~/$ sudo apt-get install chrpath g++ gawk gcc make texinfo
If bitbake finds all the necessary packages, the build will be begin successfully as shown below:
This is where the strength of your computer and internet connectivity will determine your fate. The above process can take an uncanny length of time if it’s the initial build. In my case, as mentioned in the introduction, it took 4 hours 30 minutes in one computer configuration (Virtual machine) and 4 hours and 54 minutes in another computer configuration (Ubuntu second-hand laptop).
Once the image has been successfully built, we can run the QEMU command. This allows us to emulate the image built as if it is running on real hardware.
/home/user/ … / poky_defaults$ runqemu qemux86
These opens a new window running the sato image we have just built.
You can navigate and play around this emulator platform which offers a phone-like experience, coupled with a terminal console.
If you have reached this point, congratulations. You have verified that your set-up is ready for Yocto development and in the next writeups, we will dive into more substantive builds.