ref-manual, dev-manual: Edits to running tests on hardware

Fixes [YOCTO #5554]

Applied edits to the section in the dev-manual on running tests
on hardware.

Edited the TEST_TARGET and TEST_IMAGE variables.

(From yocto-docs rev: a26ba11c739aabab4009a944d9b622e2814c7fca)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2014-04-11 08:52:46 -07:00 committed by Richard Purdie
parent e63348fb8c
commit f3dccea14a
2 changed files with 69 additions and 38 deletions

View File

@ -5660,7 +5660,7 @@
</para> </para>
<section id='qemu-image-enabling-tests'> <section id='qemu-image-enabling-tests'>
<title>QEMU</title> <title>Enabling Runtime Tests on QEMU</title>
<para> <para>
In order to run tests, you need to do the following: In order to run tests, you need to do the following:
@ -5750,7 +5750,43 @@
</section> </section>
<section id='hardware-image-enabling-tests'> <section id='hardware-image-enabling-tests'>
<title>Hardware</title> <title>Enabling Runtime Tests on Hardware</title>
<para>
The OpenEmbedded build system can run tests on real
hardware, and for certain devices it can also deploy
the image to be tested onto the device beforehand.
</para>
<para>
For automated deployment, a "master image" is installed
onto the hardware once as part of setup.
Then, each time tests are to be run, the following
occurs:
<orderedlist>
<listitem><para>The master image is booted into and
used to write the image to be tested to
a second partition.
</para></listitem>
<listitem><para>The device is then rebooted using an
external script that you need to provide.
</para></listitem>
<listitem><para>The device boots into the image to be
tested.
</para></listitem>
</orderedlist>
</para>
<para>
When running tests (independent of whether the image
has been deployed automatically or not), the device is
expected to be connected to a network on a
pre-determined IP address.
You can either use static IP addresses written into
the image, or set the image to use DHCP and have your
DHCP server on the test network assign a known IP address
based on the MAC address of the device.
</para>
<para> <para>
In order to run tests on hardware, you need to set In order to run tests on hardware, you need to set
@ -5762,13 +5798,17 @@
<itemizedlist> <itemizedlist>
<listitem><para><emphasis>"SimpleRemoteTarget":</emphasis> <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
Choose "SimpleRemoteTarget" if you are going to Choose "SimpleRemoteTarget" if you are going to
run tests on a target system that is already up and run tests on a target system that is already
running either on the network or as an image in running the image to be tested and is available
QEMU. on the network.
You can use "SimpleRemoteTarget" in conjunction
with either real hardware or an image running
within a separately started QEMU or any
other virtual machine manager.
</para></listitem> </para></listitem>
<listitem><para><emphasis>"GummiBootTarget":</emphasis> <listitem><para><emphasis>"GummiBootTarget":</emphasis>
Choose "GummiBootTarget" if your hardware is Choose "GummiBootTarget" if your hardware is
a running EFI machine with an EFI-based machine with
<filename>gummiboot</filename> as bootloader and <filename>gummiboot</filename> as bootloader and
<filename>core-image-testmaster</filename> <filename>core-image-testmaster</filename>
(or something similar) is installed. (or something similar) is installed.
@ -5781,8 +5821,8 @@
<para> <para>
If you set <filename>TEST_TARGET</filename> to If you set <filename>TEST_TARGET</filename> to
"GummiBootTarget", you also need to "GummiBootTarget", you also need to perform a one-time
setup your master image by doing the following: setup of your master image by doing the following:
<orderedlist> <orderedlist>
<listitem><para><emphasis>Set <filename>EFI_PROVIDER</filename>:</emphasis> <listitem><para><emphasis>Set <filename>EFI_PROVIDER</filename>:</emphasis>
Be sure that <filename>EFI_PROVIDER</filename> Be sure that <filename>EFI_PROVIDER</filename>
@ -5797,6 +5837,8 @@
</para></listitem> </para></listitem>
<listitem><para><emphasis>Install image:</emphasis> <listitem><para><emphasis>Install image:</emphasis>
Install the image on the target system. Install the image on the target system.
&lt;Need some clarification here from Stefan,
partition layout, etc.&gt;
</para></listitem> </para></listitem>
</orderedlist> </orderedlist>
</para> </para>
@ -5853,14 +5895,17 @@
<note> <note>
You need to customize You need to customize
<filename>TEST_POWERCONTROL_CMD</filename> <filename>TEST_POWERCONTROL_CMD</filename>
and <filename>_ARGS</filename> for your own and
setup. <filename>TEST_POWERCONTROL_EXTRA_ARGS</filename>
for your own setup.
The one requirement is that it accepts The one requirement is that it accepts
"on", "off", and "cycle" as the last argument. "on", "off", and "cycle" as the last argument.
</note> </note>
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
When no command is defined, it uses classic reboot. When no command is defined, it connects to the
device over SSH and uses the classic reboot command
to reboot the device.
Classic reboot is fine as long as the machine Classic reboot is fine as long as the machine
actually reboots (i.e. the SSH test has not actually reboots (i.e. the SSH test has not
failed). failed).
@ -5889,18 +5934,6 @@
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>: <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
<literallayout class='monospaced'> <literallayout class='monospaced'>
TEST_IMAGE = "1" TEST_IMAGE = "1"
</literallayout>
Next, also in the <filename>local.conf</filename>, set the
<filename>TEST_TARGET</filename> variable to
"simpleremote" if you want to run tests on real hardware or
set it to "qemu" if you want to run tests using QEMU.
file:
<literallayout class='monospaced'>
TEST_TARGET = "simpleremote"
</literallayout>
or
<literallayout class='monospaced'>
TEST_TARGET = "qemu"
</literallayout> </literallayout>
Next, build your image. Next, build your image.
If the image successfully builds, the tests will be If the image successfully builds, the tests will be
@ -6013,7 +6046,6 @@
Exporting tests is required if you want to be able to hand Exporting tests is required if you want to be able to hand
the test execution off to a scheduler. the test execution off to a scheduler.
You can only export tests that are defined in You can only export tests that are defined in
Tests exported are the ones defined in
<ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_SUITES'><filename>TEST_SUITES</filename></ulink>. <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_SUITES'><filename>TEST_SUITES</filename></ulink>.
</para> </para>

View File

@ -7620,10 +7620,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
<para> <para>
Automatically runs the series of automated tests for Automatically runs the series of automated tests for
images when an image is successfully built. images when an image is successfully built.
<note> </para>
Currently, there is only support for running these tests
under QEMU. <para>
</note>
These tests are written in Python making use of the These tests are written in Python making use of the
<filename>unittest</filename> module, and the majority of <filename>unittest</filename> module, and the majority of
them run commands on the target system over them run commands on the target system over
@ -7722,24 +7721,21 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
You can provide the following arguments with You can provide the following arguments with
<filename>TEST_TARGET</filename>: <filename>TEST_TARGET</filename>:
<itemizedlist> <itemizedlist>
<listitem><para><emphasis>"qemu":</emphasis> <listitem><para><emphasis>"qemu" and "QemuTarget":</emphasis>
Boots a QEMU image and runs the tests. Boots a QEMU image and runs the tests.
See the See the
"<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests'>QEMU</ulink>" "<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests'>Enabling Runtime Tests on QEMU</ulink>"
section in the Yocto Project Development Manual for section in the Yocto Project Development Manual for
more information. more information.
</para></listitem> </para></listitem>
<listitem><para><emphasis>"QemuTarget":</emphasis> <listitem><para><emphasis>"simpleremote" and "SimpleRemoteTarget":</emphasis>
Identical to "qemu".
</para></listitem>
<listitem><para><emphasis>"simpleremote":</emphasis>
Runs the tests on target hardware that is already Runs the tests on target hardware that is already
up and running. up and running.
The hardware can be on the network or it can be The hardware can be on the network or it can be
a device running an image on QEMU. a device running an image on QEMU.
You must also set You must also set
<link linkend='var-TEST_TARGET_IP'><filename>TEST_TARGET_IP</filename></link> <link linkend='var-TEST_TARGET_IP'><filename>TEST_TARGET_IP</filename></link>
when you use "simpleremote". when you use "simpleremote" or "SimpleRemoteTarget".
<note> <note>
This argument is defined in This argument is defined in
<filename>meta/lib/oeqa/targetcontrol.py</filename>. <filename>meta/lib/oeqa/targetcontrol.py</filename>.
@ -7747,9 +7743,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
reasons. reasons.
</note> </note>
</para></listitem> </para></listitem>
<listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
Identical to "simpleremote".
</para></listitem>
<listitem><para><emphasis>"GummibootTarget":</emphasis> <listitem><para><emphasis>"GummibootTarget":</emphasis>
Automatically deploys and runs tests on an Automatically deploys and runs tests on an
EFI-enabled machine that has a master image EFI-enabled machine that has a master image
@ -7761,6 +7754,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
</para></listitem> </para></listitem>
</itemizedlist> </itemizedlist>
</para> </para>
<para>
For information on running tests on hardware, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#hardware-image-enabling-tests'>Enabling Runtime Tests on Hardware</ulink>"
section in the Yocto Project Development Manual.
</para>
</glossdef> </glossdef>
</glossentry> </glossentry>