diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index b0cdc8342e..b2657cb6ff 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -5753,27 +5753,120 @@
Hardware
- This section needs the information specific to enabling
- tests to run on actual hardware.
- Here are some developer notes:
+ In order to run tests on hardware, you need to set
+ TEST_TARGET to an appropriate value.
+ For QEMU, you do not have to change anything, the default
+ value is "QemuTarget".
+ For running tests on hardware, two options exits:
+ "SimpleRemoteTarget" and "GummiBootTarget".
+
+ "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.
+
+ "GummiBootTarget":
+ Choose "GummiBootTarget" if your hardware is
+ a running EFI machine with
+ gummiboot as bootloader and
+ core-image-testmaster
+ (or something similar) is installed.
+ Also, your hardware under test must be in a
+ DHCP-enabled network that gives it the same IP
+ address for each reboot.
+
+
+
+
+
+ If you set TEST_TARGET to
+ "GummiBootTarget", you also need to
+ setup your master image by doing the following:
+
+ Set EFI_PROVIDER:
+ Be sure that EFI_PROVIDER
+ is as follows:
+
+ EFI_PROVIDER = "gummiboot"
+
+
+ Build the master image:
+ Build the core-image-testmaster
+ image.
+
+ Install image:
+ Install the image on the target system.
+
+
+
+
+
+ The final thing you need to do when setting
+ TEST_TARGET to "GummiBootTarget" is
+ to set up the test image:
+
+ Set up your local.conf file:
+ Make sure you have the following statements in
+ your local.conf file:
+
+ IMAGE_FSTYPES += "tar.gz"
+ INHERIT += "testimage"
+ TEST_TARGET = "GummibootTarget"
+ TEST_TARGET_IP = "192.168.2.3"
+
+
+ Build your test image:
+ Use BitBake to build the image:
+
+ $ bitbake core-image-sato
+
+
+
+
+
+
+ Here is some additional information regarding running
+ "GummibootTarget" as your test target:
- Paul says this "If you have deployed the image yourself,
- you can manually boot it, you know the IP address
- it will show up under, and SSH is installed with no
- password, then you can now run tests on any real
- machine."
+ You can use
+ TEST_POWERCONTROL_CMD
+ together with
+ TEST_POWERCONTROL_EXTRA_ARGS
+ as a command that runs on the host and does power
+ cycling.
+ The test code passes one argument to that command:
+ off, on or cycle (off then on).
+ Here is an example that could appear in your
+ local.conf file:
+
+ TEST_POWERCONTROL_CMD = "powercontrol.exp test 10.11.12.1 nuc1"
+
+ In this example, the expect script does the
+ following:
+
+ ssh test@10.11.12.1 "pyctl nuc1 <arg>"
+
+ It then runs a Python script that controls power
+ for a label called nuc1.
+
+ You need to customize
+ TEST_POWERCONTROL_CMD
+ and _ARGS for your own
+ setup.
+ The one requirement is that it accepts
+ "on", "off", and "cycle" as the last argument.
+
- TEST_TARGET variable needs to equal
- "simpleremote"
-
-
- Here are some notes from the patch - "The remote machine
- must be up with network and ssh and you need to set
- TEST_TARGET_IP with the IP address
- of the remote machine (it can still be a qemu instance that
- was manually started)
+ When no command is defined, it uses classic reboot.
+ Classic reboot is fine as long as the machine
+ actually reboots (i.e. the SSH test has not
+ failed).
+ It is useful for scenarios where you have a simple
+ setup, typically with a single board, and where
+ some manual interaction is okay from time to time.