Another option you have to get started is to use pre-built binaries. The Yocto Project provides many types of binaries with each release. See the "Images" chapter in the Yocto Project Reference Manual for descriptions of the types of binaries that ship with a Yocto Project release.
Using a pre-built binary is ideal for developing software applications to run on your target hardware. To do this, you need to be able to access the appropriate cross-toolchain tarball for the architecture on which you are developing. If you are using an SDK type image, the image ships with the complete toolchain native to the architecture. If you are not using an SDK type image, you need to separately download and install the stand-alone Yocto Project cross-toolchain tarball.
Regardless of the type of image you are using, you need to download the pre-built kernel that you will boot in the QEMU emulator and then download and extract the target root filesystem for your target machine’s architecture. You can get architecture-specific binaries and file systems from machines. You can get installation scripts for stand-alone toolchains from toolchains. Once you have all your files, you set up the environment to emulate the hardware by sourcing an environment setup script. Finally, you start the QEMU emulator. You can find details on all these steps in the "Using Pre-Built Binaries and QEMU" section of the Yocto Project Quick Start. You can learn more about using QEMU with the Yocto Project in the "Using the Quick EMUlator (QEMU)" section.
Using QEMU to emulate your hardware can result in speed issues
depending on the target and host architecture mix.
For example, using the qemux86
image in the emulator
on an Intel-based 32-bit (x86) host machine is fast because the target and
host architectures match.
On the other hand, using the qemuarm
image on the same Intel-based
host can be slower.
But, you still achieve faithful emulation of ARM-specific issues.
To speed things up, the QEMU images support using distcc
to call a cross-compiler outside the emulated system.
If you used runqemu
to start QEMU, and the
distccd
application is present on the host system, any
BitBake cross-compiling toolchain available from the build system is automatically
used from within QEMU simply by calling distcc
.
You can accomplish this by defining the cross-compiler variable
(e.g. export CC="distcc"
).
Alternatively, if you are using a suitable SDK image or the appropriate
stand-alone toolchain is present,
the toolchain is also automatically used.
QEMU provides a framebuffer interface that makes standard consoles available.
Generally, headless embedded devices have a serial port. If so, you can configure the operating system of the running image to use that port to run a console. The connection uses standard IP networking.
SSH servers exist in some QEMU images.
The core-image-sato
QEMU image has a
Dropbear secure shell (SSH) server that runs with the root
password disabled.
The core-image-full-cmdline
and
core-image-lsb
QEMU images
have OpenSSH instead of Dropbear.
Including these SSH servers allow you to use standard
ssh
and scp
commands.
The core-image-minimal
QEMU image,
however, contains no SSH server.
You can use a provided, user-space NFS server to boot the QEMU session
using a local copy of the root filesystem on the host.
In order to make this connection, you must extract a root filesystem tarball by using the
runqemu-extract-sdk
command.
After running the command, you must then point the runqemu
script to the extracted directory instead of a root filesystem image file.