mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-31 12:49:46 +00:00
Code Issues Projects Releases Wiki Activity

dev-manual, ref-manual: Eliminated pre-built section

Browse Source 
Fixes [YOCTO #11630]

I took the section that described how to use a pre-built kernel
and run it through QEMU out.  This is basically a QEMU usage
section and is not in that area.  There were some QEMU speed
up items suitable for the QEMU concepts section in the ref-manual.
I put those in that area.

(From yocto-docs rev: b081013aa10b42e4eb88ed54940112c5ae106911)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2017-07-18 10:44:37 -07:00
committed by Richard Purdie
parent 2217d97ba9
commit 15901164ee
2 changed files with 80 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/dev-manual/dev-manual-start.xml
+2 -57
View File
@@ -858,6 +858,7 @@
</para> </para>
</section> </section>
<!--
<section id='using-pre-built-binaries-and-qemu'> <section id='using-pre-built-binaries-and-qemu'>
<title>Using Pre-Built Binaries and QEMU</title> <title>Using Pre-Built Binaries and QEMU</title>
@@ -906,64 +907,8 @@
"<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>" "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
section. section.
</para> </para>
<para>
Using QEMU to emulate your hardware can result in speed issues
depending on the target and host architecture mix.
For example, using the <filename>qemux86</filename> 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 <filename>qemuarm</filename> image on the same Intel-based
host can be slower.
But, you still achieve faithful emulation of ARM-specific issues.
</para>
<para>
To speed things up, the QEMU images support using <filename>distcc</filename>
to call a cross-compiler outside the emulated system.
If you used <filename>runqemu</filename> to start QEMU, and the
<filename>distccd</filename> 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 <filename>distcc</filename>.
You can accomplish this by defining the cross-compiler variable
(e.g. <filename>export CC="distcc"</filename>).
Alternatively, if you are using a suitable SDK image or the appropriate
stand-alone toolchain is present,
the toolchain is also automatically used.
</para>
<note>
Several mechanisms exist that let you connect to the system running on the
QEMU emulator:
<itemizedlist>
<listitem><para>QEMU provides a framebuffer interface that makes standard
consoles available.</para></listitem>
<listitem><para>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.</para></listitem>
<listitem><para>
SSH servers exist in some QEMU images.
The <filename>core-image-sato</filename> QEMU image has a
Dropbear secure shell (SSH) server that runs with the root
password disabled.
The <filename>core-image-full-cmdline</filename> and
<filename>core-image-lsb</filename> QEMU images
have OpenSSH instead of Dropbear.
Including these SSH servers allow you to use standard
<filename>ssh</filename> and <filename>scp</filename> commands.
The <filename>core-image-minimal</filename> QEMU image,
however, contains no SSH server.
</para></listitem>
<listitem><para>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
<filename>runqemu-extract-sdk</filename> command.
After running the command, you must then point the <filename>runqemu</filename>
script to the extracted directory instead of a root filesystem image file.</para></listitem>
</itemizedlist>
</note>
</section> </section>
-->
</chapter> </chapter>
<!-- <!--
vim: expandtab tw=80 ts=4 vim: expandtab tw=80 ts=4
documentation/ref-manual/usingpoky.xml
+78
View File
@@ -1111,6 +1111,84 @@
</para> </para>
</section> </section>
<section id='qemu-performance'>
<title>QEMU Performance</title>
<para>
Using QEMU to emulate your hardware can result in speed issues
depending on the target and host architecture mix.
For example, using the <filename>qemux86</filename> 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 <filename>qemuarm</filename> image
on the same Intel-based host can be slower.
But, you still achieve faithful emulation of ARM-specific issues.
</para>
<para>
To speed things up, the QEMU images support using
<filename>distcc</filename> to call a cross-compiler outside the
emulated system.
If you used <filename>runqemu</filename> to start QEMU, and the
<filename>distccd</filename> 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 <filename>distcc</filename>.
You can accomplish this by defining the cross-compiler variable
(e.g. <filename>export CC="distcc"</filename>).
Alternatively, if you are using a suitable SDK image or the
appropriate stand-alone toolchain is present, the toolchain is
also automatically used.
</para>
<note>
Several mechanisms exist that let you connect to the system
running on the QEMU emulator:
<itemizedlist>
<listitem><para>
QEMU provides a framebuffer interface that makes standard
consoles available.
</para></listitem>
<listitem><para>
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.
</para></listitem>
<listitem><para>
SSH servers exist in some QEMU images.
The <filename>core-image-sato</filename> QEMU image has a
Dropbear secure shell (SSH) server that runs with the root
password disabled.
The <filename>core-image-full-cmdline</filename> and
<filename>core-image-lsb</filename> QEMU images
have OpenSSH instead of Dropbear.
Including these SSH servers allow you to use standard
<filename>ssh</filename> and <filename>scp</filename>
commands.
The <filename>core-image-minimal</filename> QEMU image,
however, contains no SSH server.
</para></listitem>
<listitem><para>
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
<filename>runqemu-extract-sdk</filename> command.
After running the command, you must then point the
<filename>runqemu</filename>
script to the extracted directory instead of a root
filesystem image file.
See the
"<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-running-under-a-network-file-system-nfs-server'>Running Under a Network File System (NFS) Server</ulink>"
section in the Yocto Project Development Manual for more
information.
</para></listitem>
</itemizedlist>
</note>
</section>
<section id='qemu-command-line-syntax'> <section id='qemu-command-line-syntax'>
<title>QEMU Command-Line Syntax</title> <title>QEMU Command-Line Syntax</title>