If you did not set TEST_TARGET
to
"GummibootTarget", then you do not need any information
in this section.
You can skip down to the
"Running Tests"
section.
If you did set TEST_TARGET
to
"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
is as follows:
EFI_PROVIDER = "gummiboot"
Build the master image:
Build the core-image-testmaster
image.
The core-image-testmaster
recipe is provided as an example for a
"master" image and you can customize the image
recipe as you would any other recipe.
Here are the image recipe requirements:
Inherits
core-image
so that kernel modules are installed.
Installs normal linux utilities
not busybox ones (e.g.
bash
,
coreutils
,
tar
,
gzip
, and
kmod
).
Uses a custom initramfs image with a custom installer. A normal image that you can install usually creates a single rootfs partition. This image uses another installer that creates a specific partition layout. Not all Board Support Packages (BSPs) can use an installer. For such cases, you need to manually create the following partition layout on the target:
First partition mounted
under /boot
,
labeled "boot".
The main rootfs
partition where this image gets
installed, which is mounted under
/
.
Another partition labeled "testrootfs" where test images get deployed.
Install image: Install the image that you just built 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:
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
.
TEST_POWERCONTROL_CMD
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 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). 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.