[Lava-users] about DUT inner program to communicate with Worker
neil.williams at linaro.org
Thu Aug 2 06:55:59 UTC 2018
On Thu, 2 Aug 2018 at 04:02, ljh_dev <ljh_dev at 126.com> wrote:
> If there is no “dameon” program in DUT. How to add/update the program running in DUT
> for example application test program or linux kernel or uboot etc.?
The LAVA test job deploys a new linux kernel. Most DUTs are not capable of
having a new U-Boot deployed in automation because there is no way to
automatically recover from a broken deployment.
Please read through the documentation, starting with the first pipeline
QEMU job and have a look at how existing test jobs work on LAVA instances
It sounds like you are approaching this with a fixed set of assumptions,
based on some existing tooling?
LAVA supports deploying new software builds to real hardware under
automation. Typically that means a new kernel and root filesystem (so there
would be nowhere for a daemon to exist on the DUT as everything above the
kernel is freshly deployed on every test job). *Some* hardware (out of over
100 device types, there are only 2 with this support) can automatically
recover from a broken firmware / bootloader deployment and so can deploy a
new build of U-Boot or UEFI for each test job. The two types are hikey 6220
(NOT 960) and Juno. Even so, there are limitations - for example only one
hikey 6220 can be configured for automated firmware deployment on any one
worker because the hikey 6220 does not uniquely identify itself when in
Please fully describe your use case, including details of the devices you
want to test, how you want to test the software using those devices and how
you will isolate testing of each component. (Change only one thing at a
time - do not try to do full software stack testing with multiple changes
per test run. Make the job matrix large enough that every change to every
component is individually tested against known working versions of every
other component.) If your device does support automated U-Boot deployment
(the vast majority cannot - anything relying on U-Boot on an SD card
cannot) then each change to U-Boot must be tested against a known working
kernel and root filesystem. When you change the kernel, you keep to a known
working U-Boot and root filesystem etc.
Do not make it a requirement to be able to reliably automate deployment of
U-Boot, at scale. It is exceptionally rare to find a device which can
support it. It generally involves the specific hardware designed into the
device at the earliest stages to act as a baseboard management controller.
This is not a limitation of the automation software, this is a reality of
the hardware design of the DUT. LAVA has tested many attempts at making a
device which can muiltiplex SD cards - NONE have proven to be reliable. To
make automated testing work at scale demands high reliability and every
additional layer of hardware (like SD card replacement or battery
isolation) adds complexity and lowers reliability.
Please read https://linux.codehelp.co.uk/automation-and-risk.html for more
on the background to automation and the risk of failure. It is a long read
but we've built up a lot of data on how to do this kind of testing at scale.
> Jiang Lao
> On Wed, 1 Aug 2018 at 10:18, ljh_dev <ljh_dev at 126.com <https://lists.linaro.org/mailman/listinfo/lava-users>> wrote:
> >* Hi,
> *>* I have browsed the website documentation of lava overall. I think the
> *>* DUT(Device Under Test) should has "dameon" program to communicate with the
> *>* Worker Dispatcher module. But I did not find where the DUT "dameon"
> *>* program source code is,and how to build&install this DUT "dameon" program.
> It does not need to be built or installed. The lava-dispatcher package does
> all that work for you.
> Lava-users mailing list
> Lava-users at lists.linaro.org
neil.williams at linaro.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lava-users