aboutsummaryrefslogtreecommitdiffstats
path: root/meta/lib/oeqa/controllers
AgeCommit message (Collapse)Author
2016-07-20oeqa/controllers: Add test target for Systemd-bootJose Perez Carranza
A new test target is neede to test Systemd-boot similar to gummiboot. Created a copy of GummibootTarget class and named as SystemdbootTarget, at this point the gummibootTarget will remain until documentation is updated with new systed information. Signed-off-by: Jose Perez Carranza <jose.perez.carranza@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-06-02classes/lib: Complete transition to python3Richard Purdie
This patch contains all the other misc pieces of the transition to python3 which didn't make sense to be broken into individual patches. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-06-23meta: Add explict getVar param for (non) expansionRichard Purdie
Rather than just use d.getVar(X), use the more explict d.getVar(X, False) since at some point in the future, having the default of expansion would be nice. This is the first step towards that. This patch was mostly made using the command: sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *` Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-13controllers/masterimage.py: Make testimage kernel naming pattern universalCorneliu Stoicescu
YB: #6254 The QemuTargetControl class does not specify any kernel naming but the runqemu script it uses uses the " KERNEL_IMAGETYPE + MACHINE + '.bin' " naming scheme. Modifying the other major target controller class, MasterImageHardwareTarget, to use the same kernel naming scheme. This is usefull also to outside scripts that want to anticipate the kernel file name for all target controllers. Signed-off-by: Corneliu Stoicescu <corneliux.stoicescu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-13oeqa/controllers/testtargetloader.py: add 'import os'Corneliu Stoicescu
YB: #6254 This module uses os but relies on other modules to import it. Adding 'import os' in order to be self-sustained. Signed-off-by: Corneliu Stoicescu <corneliux.stoicescu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-13masterimage.py: enable dynamical determination of rootfs typeCorneliu Stoicescu
YB: #6375 Adding support for get_image_fstype() in the MasterImageHardwareTarget and GummibootTarget classes. Signed-off-by: Corneliu Stoicescu <corneliux.stoicescu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30oeqa: add proper handling for command errors where neededPaul Eggleton
For use outside of tests themselves, we want a better error than AssertionError, so create one and allow us to request it when calling runCmd(). This enables us to avoid tracebacks during master image operations if the power control command fails. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30oeqa/controllers/masterimage: more robust master image startupPaul Eggleton
Instead of powering up the target when the object is constructed, wait until deploy is called. Then there are basically two different scenarios: a) The device is booted into the master image already, in which case we can just use it b) The device is booted into another image or can't be contacted, in which case we need to power cycle it. Here we also now wait until it has booted up instead of trying to contact it immediately. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30oeqa/controllers/masterimage: add a serial control commandStefan Stanacar
Similar to power control command, this depends on a user's setup to get to the serial port of a board. For a local connected board this could just be: TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200" and for a serial console server: "telnet 10.11.12.13 7003" or some conmux command. Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30oeqa/targetcontrol: restart method shouldn't be abstractStefan Stanacar
And drop the un-needed and un-used restart methods. Only qemu ever used this and actually does it safely. Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30oeqa/controllers/masterimage: add a base class for hw targetsStefan Stanacar
Right now GummibootTarget is the only hardware TEST_TARGET with deployment, but we will add more, so let's make an abstract base class, that will do the common thing for all the hw targets. Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-03-31lib/oeqa: add a test target controller for EFI targetsStefan Stanacar
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] Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-02lib/oeqa: allow multiple layers to provide their own TEST_TARGET classSipke Vriend
Use a python module "folder" rather than a single module within layers to ensure multiple layers can define a TEST_TARGET class. Current implementation using controllers.py module will only allow a single layer to define test targets. Add a controllers folder as well as a TestTargetLoader class whose job is to load the given TEST_TARGET class from any number of python modules within the oeqa/controllers/ directory of any layer. The only condition will be that layers will need to ensure the TEST_TARGET class name they provide is unique otherwise there is no guarantee which class is instantiated. a bb.warn is used to alude to this if it happens. Signed-off-by: Sipke Vriend <sipke.vriend@xilinx.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>