On 7 July 2017 at 03:03, Elric Hindy elric.hindy@seeingmachines.com wrote:
Hi,
I have been investigating LAVA for use in our organisation and i'm stuck trying to get a hello world test case running on our hardware and looking for some help.
As in the docs, adding support for new hardware is the hardest possible thing to do in LAVA - it is NOT to be considered a "hello world" task, it requires a lot of careful and detailed knowledge.
Please follow the documentation and learn LAVA with known working devices first. We fully expect that to take a month or longer. The learning curve is steep but there are no shortcuts.
Start with QEMU then add a known working supported device type like beaglebone-black or cubietruck. Learn how to run test jobs on those because there will still need to be admin tasks to get those automated. All those same tasks will need to be done for the new hardware plus a lot of other work. Until QEMU and ideally one known working device are regularly running test jobs to completion, there is little point attempting to add a completely new device type.
We looked at the YOCTO test tools however it can only use devices with a fixed ip which we can't guarantee or want during our testing as we also test network settings. It's also limited in configuration, LAVA package seems to meet all our requirements however i'm still unsure on how to do a few things.
We use Yotco images and boot with the grub bootloader.
Grub is one of the easier bootloaders to integrate but it is still a lot of work and most of it cannot be documented because it is specific to how you have configured your lab and your devices. There are examples of using grub in the existing known device-types but it depends on what else is involved, e.g. UEFI or UBoot or fastboot, before Grub loads.
All our devices are connected via Ethernet only and power and peripheral switching is controlled via usb relays.
After reading through all the documentation i'm still unsure of how to set up and actually run a test on our hardware. What tools do i need to install in the test image and how do i get it to communicate with grub?
The test image does not communicate with grub. The lava-slave communicates with the device over serial, including sending commands to grub so that grub can use TFTP to obtain the kernel image which has been deployed to a suitable location by LAVA.
For most Grub devices, the only requirements are TFTP and tftpd-hpa is typically installed alongside lava-dispatcher already.
I assume a base image is one that includes nothing but the tools and grub.
No.
Grub does not typically get re-deployed unless you are using PXE. There is confusion here about what you mean by base image.
Typically, LAVA devices only need to have enough software pre-installed to get to a prompt which LAVA can interrupt. Nothing else is actually required.
We have a recovery partition with tiny core which could facilitate that but it's not required for the automated testing.
I've used the akbennet/lava-server docker image and it is up and running, although test jobs are scheduled but never run on the qemu devices so a little stuck there.
We don't use those images ourselves, everything used by the LAVA software team is installed in a full VM or on bare metal Debian Jessie. If there are problems with those images, you will need to debug that at your end by checking the logs as described in the documentation.
Basically, I need help to get LAVA to connect to one of our devices to load
the image and run tests?
Choosing the image, writing tests and mostly configuring the pipeline I understand.
Debug your QEMU issues first. Then add a UBoot device like beaglebone-black or cubietruck for which standard test jobs exist which are known to work. Then have a look at some of the grub support in LAVA V2 - x86 uses grub over PXE and mustang uses grub via UEFI.