The purpose of this module is to deploy a test image on a EFI-enabled hardware and run our runtime tests. A bit of background: - testimage.bbclass uses the concept of TEST_TARGET which is a class name that is responsible for target deploying. A layer can provide it's own TEST_TARGET. Right now has OE-core has a QemuTarget and a SimpleRemoteTarget (ssh into an already up and running machine and run tests), the default one being qemu. - basically testimage does something like: target.deploy() try: target.start() runTests() finally: target.stop() This module assumes a running EFI machine with gummiboot as bootloader and core-image-testmaster installed (or similar). Also your hardware under test has to be in a DHCP-enabled network that gives it the same IP for each reboot. One time setup (master image): - build core-image-testmaster with EFI_PROVIDER = "gummiboot" - install the image on the target Test image setup: - build your test image, e.g core-image-sato as you usually do, but with these in local.conf: IMAGE_FSTYPES += "tar.gz" - Now run the tests: INHERIT += "testimage" TEST_TARGET = "GummibootTarget" TEST_TARGET_IP = "192.168.2.3" bitbake core-image-sato -c testimage Other notes: - TEST_POWERCONTROL_CMD (togheter with TEST_POWERCONTROL_EXTRA_ARGS) can be 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). In my case I use something like TEST_POWERCONTROL_CMD="powercontrol.exp test 10.11.12.1 nuc1" in local.conf. Basically my expect script does: 'ssh test@10.11.12.1 "pyctl nuc1 <arg>" and runs a python script there that controls power for a label called nuc1'. The reason why my expect script has to ssh into another machine is because of network topology, and that machine is the one actually connected to the test rack and the power strip. That's why TEST_POWERCONTROL_CMD and _ARGS need to be customized for one's setup, the only requirement being that it accepts: on/off/cycle as the last argument. - if no command is defined it would use classic reboot. This is fine as long as the machine actually reboots (as in the ssh test hasn't failed), but it's useful for "simple-setup-with-one-board-on-the-desk" scenario, where some manual interaction is okay from time to time. [YOCTO #5614] (From OE-Core rev: e00f888a88d0851b088c232dec66418e575a2e90) Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
||
---|---|---|
bitbake | ||
documentation | ||
meta | ||
meta-selftest | ||
meta-skeleton | ||
meta-yocto | ||
meta-yocto-bsp | ||
scripts | ||
.gitignore | ||
.templateconf | ||
LICENSE | ||
README | ||
README.hardware | ||
oe-init-build-env | ||
oe-init-build-env-memres |
README
Poky ==== Poky is an integration of various components to form a complete prepackaged build system and development environment. It features support for building customised embedded device style images. There are reference demo images featuring a X11/Matchbox/GTK themed UI called Sato. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK with IDE integration. Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of layers which extend the systems capabilities in a modular way. As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation and various sources of information e.g. for the hardware support. Poky is in turn a component of the Yocto Project. The Yocto Project has extensive documentation about the system including a reference manual which can be found at: http://yoctoproject.org/documentation OpenEmbedded-Core is a layer containing the core metadata for current versions of OpenEmbedded. It is distro-less (can build a functional image with DISTRO = "nodistro") and contains only emulated machine support. For information about OpenEmbedded, see the OpenEmbedded website: http://www.openembedded.org/ Where to Send Patches ===================== As Poky is an integration repository, patches against the various components should be sent to their respective upstreams. bitbake: bitbake-devel@lists.openembedded.org meta-yocto: poky@yoctoproject.org Most everything else should be sent to the OpenEmbedded Core mailing list. If in doubt, check the oe-core git repository for the content you intend to modify. Before sending, be sure the patches apply cleanly to the current oe-core git repository. openembedded-core@lists.openembedded.org Note: The scripts directory should be treated with extra care as it is a mix of oe-core and poky-specific files.