diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml
index d73bb967a7..763582d874 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -297,20 +297,85 @@
Using Pre-Built Binaries and QEMU
- Another option you have to get started is to use pre-built binaries.
- This scenario is ideal for developing software applications to run on your target hardware.
- To do this, you need to install the stand-alone Yocto Project cross-toolchain tarball and
- then download the pre-built kernel that you will boot in the QEMU emulator.
- Next, you must download and extract the target root filesystem for your target
- machine’s architecture.
- Finally, you set up the environment to emulate the hardware and then start the QEMU emulator.
+ 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 Reference: Images
+ section 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 filesystem from
+ machines.
+ You can get 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.
+
+
+ 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 in /opt/poky,
+ the toolchain is also automatically used.
+
+
+
+ Several mechanisms exist that let you connect to the system running on the
+ QEMU emulator:
+
+ 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.
+ The QEMU images have a Dropbear secure shell (ssh) server
+ that runs with the root password disabled.
+ This allows you to use standard ssh and
+ scp commands.
+ The QEMU images also contain an embedded Network Files
+ System (NFS) server that exports the image's root filesystem.
+ This allows you to make the filesystem available to the
+ host.
+
+