From d8ee1658de04cb26d401038c6b001def5991de8c Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 8 Apr 2014 11:46:42 -0700 Subject: dev-manual: Added new "Hardware" section for running tests. Fixes [YOCTO #5554] This is the section that describes how to enable tests for actual hardware. (From yocto-docs rev: fd33b19e7fa32797ab2abd2b506b0d63209fbfc6) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 125 ++++++++++++++++++--- 1 file changed, 109 insertions(+), 16 deletions(-) (limited to 'documentation/dev-manual') 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". - - 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." + "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: + - TEST_TARGET variable needs to equal - "simpleremote" + 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. + - 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. -- cgit v1.2.3-54-g00ecf