diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 63aba00abb..fa6e9cd9b8 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -5660,7 +5660,7 @@
- QEMU
+ Enabling Runtime Tests on QEMU
In order to run tests, you need to do the following:
@@ -5750,7 +5750,43 @@
- Hardware
+ Enabling Runtime Tests on Hardware
+
+
+ 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.
+
+
+
+ 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:
+
+ The master image is booted into and
+ used to write the image to be tested to
+ a second partition.
+
+ The device is then rebooted using an
+ external script that you need to provide.
+
+ The device boots into the image to be
+ tested.
+
+
+
+
+
+ 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.
+
In order to run tests on hardware, you need to set
@@ -5762,13 +5798,17 @@
"SimpleRemoteTarget":
Choose "SimpleRemoteTarget" if you are going to
- run tests on a target system that is already up and
- running either on the network or as an image in
- QEMU.
+ run tests on a target system that is already
+ running the image to be tested and is available
+ 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.
"GummiBootTarget":
Choose "GummiBootTarget" if your hardware is
- a running EFI machine with
+ an EFI-based machine with
gummiboot as bootloader and
core-image-testmaster
(or something similar) is installed.
@@ -5781,8 +5821,8 @@
If you set TEST_TARGET to
- "GummiBootTarget", you also need to
- setup your master image by doing the following:
+ "GummiBootTarget", you also need to perform a one-time
+ setup of your master image by doing the following:
Set EFI_PROVIDER:
Be sure that EFI_PROVIDER
@@ -5797,6 +5837,8 @@
Install image:
Install the image on the target system.
+ <Need some clarification here from Stefan,
+ partition layout, etc.>
@@ -5853,14 +5895,17 @@
You need to customize
TEST_POWERCONTROL_CMD
- and _ARGS for your own
- setup.
+ and
+ TEST_POWERCONTROL_EXTRA_ARGS
+ for your own setup.
The one requirement is that it accepts
"on", "off", and "cycle" as the last argument.
- 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
actually reboots (i.e. the SSH test has not
failed).
@@ -5889,18 +5934,6 @@
Build Directory:
TEST_IMAGE = "1"
-
- Next, also in the local.conf, set the
- TEST_TARGET 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:
-
- TEST_TARGET = "simpleremote"
-
- or
-
- TEST_TARGET = "qemu"
Next, build your image.
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
the test execution off to a scheduler.
You can only export tests that are defined in
- Tests exported are the ones defined in
TEST_SUITES.
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 164ea1c817..fbf0a43dee 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -7620,10 +7620,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Automatically runs the series of automated tests for
images when an image is successfully built.
-
- Currently, there is only support for running these tests
- under QEMU.
-
+
+
+
These tests are written in Python making use of the
unittest module, and the majority of
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
TEST_TARGET:
- "qemu":
+ "qemu" and "QemuTarget":
Boots a QEMU image and runs the tests.
See the
- "QEMU"
+ "Enabling Runtime Tests on QEMU"
section in the Yocto Project Development Manual for
more information.
- "QemuTarget":
- Identical to "qemu".
-
- "simpleremote":
+ "simpleremote" and "SimpleRemoteTarget":
Runs the tests on target hardware that is already
up and running.
The hardware can be on the network or it can be
a device running an image on QEMU.
You must also set
TEST_TARGET_IP
- when you use "simpleremote".
+ when you use "simpleremote" or "SimpleRemoteTarget".
This argument is defined in
meta/lib/oeqa/targetcontrol.py.
@@ -7747,9 +7743,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
reasons.
- "SimpleRemoteTarget":
- Identical to "simpleremote".
- "GummibootTarget":
Automatically deploys and runs tests on an
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"
+
+
+ For information on running tests on hardware, see the
+ "Enabling Runtime Tests on Hardware"
+ section in the Yocto Project Development Manual.
+