Yocto Embedded Linux build for QEMU x86 and its first application

This article is a quick start with pictures for those who need to build Embedded Linux using Yocto.
If you are going to build Embedded Linux for specific hardware, for example, for SoC on FPGA, then, probably, I will come across the Yocto project.

Yocto - a project bringing together
  • developer tools
  • assembly system;
  • set of software interfaces;
  • a collection of meta-packages that expand the capabilities of the platform;
  • plugins for Eclipse and Anjuta.

I tried to describe the process so that you can spend less time on problems with setting up and preparing and get started as soon as possible.

Linux image assembly


The basis for the assembly is the article
“Yocto Project Quick Start” .
I will collect in the folder
~/My_Designs/Poky

A small digression:
After starting the terminal, execute all commands in it, because during the work environment variables are created and used. If you have closed the terminal and opened a new one, then go to
~.../poky

and you have to repeat some commands. For instance,
source oe-init-build-env

create a git repository
$ git clone git://git.yoctoproject.org/poky
$ cd poky
$ git checkout -b dizzy origin/dizzy

now current directory
~/My_Designs/Poky/poky

now, according to Yocto's terms, it turned out the
Source Directory - "poky"
local working area (local branch) - dizzy
The first thing is done
$ source oe-init-build-env

This command sets up the shell environment, creates an initial mutable set of configuration files, and interacts with the BitBake system execution environment by using a script file that allows Poky to establish whether the minimum system requirements are met. The result of the command will report either problems, for example, missing packages, or the possibility to continue editing the conf / local.conf file.

Edit conf / local.conf:
$ nano conf/local.conf

BB_NUMBER_THREADS ?= "3"
PARALLEL_MAKE ?= "-j 3"
EXTRA_IMAGE_FEATURES = "debug-tweaks eclipse-debug tools-debug debug-tweaks"

Here you should specify the number of threads that the bitbake build tool will run. To maximize the computing power, the number of threads should correspond to the number of processor cores. I pointed out 1 less to make it more convenient to use the computer during assembly.
I also added additional features useful for development.
Since we are assembling for standard QEMU x86, the rest can be left unchanged.

Then you can choose a “recipe” - an assembly option with its own set of libraries, utilities, created files, images, etc.
A list of recipes with their brief descriptions can be found here:
openembedded-core recipes Scroll down
to recipes starting with core- ...
I do not advise collecting core-image-minimal for review. There are no ssh and other convenient debugging tools.
I chose core-image-sato. This is the assembly with the SATO GUI.

Actually, the assembly:
$ bitbake core-image-sato

Be prepared to wait for the completion of the assembly, perhaps from 3 hours to 3 or more days. Fortunately, the process can be paused and resumed.
To pause, press + one (!) Time and wait until all started operations are completed. Otherwise, errors may appear and have to be redone. To resume, repeat
$ bitbake core-image-sato 

If the terminal is closed, then in the new terminal, before assembly, you will have to repeat the installation of environment variables:
$ source oe-init-build-env

Upon completion of the assembly, you can check what happened by running the QEMU emulator
$ runqemu qemux86

The xterm terminal window will appear, there you will need to enter the root password of the host to create the tap interface. There you can also see the IP host machines on the tap interface and the IP of the emulated machine. I have 192.168.7.1 and 192.168.7.2 respectively.
Then, if SATO is assembled, a GUI window should appear:

GUI SATO in QEMU

If the running emulator interferes, it can still be closed. Scroll with the arrows at the top of the GUI until the corresponding shutdown icon appears or enter poweroff through the SATO terminal or via ssh. About ssh will be later.
Do not cross the QEMU with the cross on the main window of the emulator. Cover with regular means of the emulated machine. Otherwise, you will have ethX, tapX, virbrX interfaces in your system from QEMU, which will be ifconfig ... ifdown, or how it is done on your OS. Or each time QEMU starts, there will be a new host IP and QEMU, which is inconvenient.

Development tools


Used by the Eclipse IDE for C / C ++ Developers, version of Luna. This assembly contains plugins CDT, GNU ARM and some other plugins useful for cross-compiling and developing firmware.
You can download from here:
Eclipse Luna SR2 .

We will collect applications Hello, world!

Eclipse Cross GCC


First, a simple way, let's collect the usual Eclipse tools: CDT + GNU ARM
If these plugins are not already in your Eclipse, then add the CDT plugin from the standard Eclipse repository and from here the GNU ARM Plugin for Eclipse GNU ARM C / C ++ Cross Compiler and what else you want.

Create a new C ++ project:
Menu Eclipse File-> New-> Project ... -> C / C ++ -> C ++ Project
You need to select
Project type: Executable-> Hello World C ++ Project
Toolchains: Cross GCC
New C ++ Cross GCC Project
fill in the Author field
Now the most important thing about the system builds:
Cross compiller prefix: i586-poky-linux-
Cross compiler path: /home/.../My_Designs/Poky/poky/build/tmp/sysroots/x86_64-linux/usr/bin/i586-poky-linux
Compiling the project
Project-> Build Project
An executable file should appear.
Since it was compiled for QEMU x86 Linux, it should also start on your host machine, unless, of course, you are working on x86 Linux or compatible with it. I started on IA64 Ubuntu.
Now, if you managed to close QEMU, then run again
$ runqemu qemux86

The xterm terminal window will appear, you will need to enter the root password to create the tap interface.

QEMU bash

As you can see, I have an IP host machine 192.168.7.1, IP qemu 192.168.7.2
Then a QEMU window with a graphical interface will appear.
You can connect to QEMU via ssh and sftp. The first is useful for launching a program, the second for sending this program to an emulated machine.
I sent the file using the Krusader file manager. On Windows, you can use FileZilla or others.
In Krusader, I selected Tools-> New Net Connection ..., in the dialog box, select sftp: //, enter IP and Username: root

Krusader New Network Connection

In the QEMU home folder, I copied the hello_cross_gcc_02 executable file from the Debug folder of the project
Next, you can open the terminal in the QEMU graphical interface and run the program for execution from there. It seemed to me more convenient to connect via ssh. In the terminal window of the host machine, run ssh
$ ssh root@192.168.7.2

and run the recently copied executable file:
$ ./hello_cross_gcc_02

It should be
Hello World!

Build in ADT


Yocto provides an Application Development Toolkit (ADT) that contains:
  • architecture-oriented and sysroot cross-toolchain compiled by the OpenEmbedded system that uses Poky
  • Yocto plugin for Eclipse IDE
  • QEMU for emulating target equipment
  • various development tools working in user-space

Preparing Eclipse

Based on this: Yocto - Configuring Eclipse
Eclipse needs plug-ins from the standard package:
Linux Tools
  • LTTng - Linux Tracing Toolkit

Mobile and Device Development
  • C / C ++ Remote Launch
  • Remote System Explorer End-user Runtime
  • Remote System Explorer User Actions
  • Target management terminal
  • TCF Remote System Explorer add-in
  • TCF Target Explorer

Programming languages
  • Autotools Support for CDT
  • C / C ++ Development Tools

And you need to add a plugin from Yocto. You can download from here: Yocto Plugin for Eclipse

Assembly preparation


To organize interaction with the IDE and development tools, scripts are provided:
$ bitbake adt-installer
$ bitbake meta-ide-support

Yocto plugin needs rpcbind to run QEMU
$ sudo apt-get install rpcbind

need to edit the file / etc / default / rpcbind
$ sudo nano /etc/default/rpcbind
> OPTIONS="-i -w"


you need to unzip the root filesystem to the folder in sysroots where the file system of the emulated machine lies. In our case, qemux86:
$ runqemu-extract-sdk ./tmp/deploy/images/qemux86/core-image-sato-qemux86.tar.bz2 ./tmp/sysroots/qemux86


Configure Yocto ADT in Eclipse


In the Eclipse menu Windows-> Preferences, Yocto Project ADT
Cross Compiler Options
Build system derived toolchain
Toolchain Root Location:
/home/.../Poky/poky/build/
Sysroot Location:
/home/.../Poky/poky/build / tmp / sysroots / qemux86
Target Architecture: i586-poky-linux
Target Options:
QEMU
Kernel: /home/.../Poky/poky/build/tmp/deploy/images/qemux86/bzImage-qemux86.bin

Yocto Project ADT Preferences

Project Hello, World! in Eclipse with Yocto ADT


Create a new project
New Project-> C ++ Project
Project name: hello_qemu_cmake_04
Project type: Yocto Project ADT CMake Project-> Hello World C ++ CMake Project
New Yocto ADT CMake Project

Next, Next, Finish
Build project
In the project folder -> Debug you should get hello_qemu_cmake_04
Now you can start the application in the same way as was the case with the project created through Cross GCC except that QEMU is now launched in Eclipse via the menu
Run-> External Tools-> qemu_i586-poky-linux

Starting and Debugging from the Eclipse IDE


Now configure Eclipse so that you can launch and debug the application directly from the IDE.
The instructions are taken from here:
Downloading and debugging the application using ADT tools in Eclipse
For convenience, the remote machine must be started before configuration (Run-> External Tools-> qemu_i586-poky-linux, as in the previous section).
To configure debugging, select in the menu Eclipse
Run -> Debug Configurations ...
In the list on the left you need to find “C / C ++ Remote Application”, there should be an item with the name of our project and virtual machine. I have this “hello_qemu_cmake_04_gdb_i586-poky-linux”. You have to choose it.
The Yocto manual suggests that you specify Remote Absolute File Path for C / C ++ Application. But now is not the best time for this. It will be more convenient to first configure the connection with the remote machine.
In the meantime, in the right pane, select the Debugger tab, here in the Debugger drop-down list, select remote gdb / mi. I have this is the only element of the list, but you still need to select it. In this case, fill in some other form fields.
Eclipse-> Debug Configurations - Debugger
Go back to the Main tab and create a connection.
In the Connection section, select New .... In the New Connection window, select TCF. I have two of them. I do not know why the second, but the choice of the first definitely leads to a positive result.

Eclipse-> Debug Configurations - Main-> New Connection

In the Host name field, enter the IP machines in QEMU. The Connection name field can be left filled with IP. , ... In order to less fuss later, here you can specify login when connecting. In the Connection section, click Edit ... and fill in the Default User ID. Root login

Eclipse-> Debug Configurations - Main-> Edit - Properties
On the Main tab, select the connection you just created.
Now we specify the path to the file and the name of the file with which Eclipse will download the debugged application to the remote machine.
If QEMU is running, then you can click Browse ... and if everything is OK with the connection, you can look at the file system of the remote machine and select the place where to download the application. You will not necessarily have the same picture as in the screenshot below. But here is the important thing: you need to specify the file. If you are going to specify a folder in which there is no file with the name with which you want to download the executable file, then you will not be limited to this window. Click and add the file name in the Debug Configurations window.

Eclipse-> Debug Configurations - Main-> Select remote application file

The result should be something like this:

Eclipse-> Debug Configurations - Main

Now you can click.

In my Eclipse console window, “Remote Shell” was like this:

root@qemux86:/# 
e
c
h
o
$
P
WD'>'
/>
…

Then an invitation to switch to the Debug perspective. It makes sense to agree.
Debugger stopped on line
printf("Hello World!\n");

Click Step Over (F6)
In the terminal
...
Remote debugging from host 192.168.7.1
Hello World!

Now you can write a program. So far for QEMU x86.

Also popular now: