On Mon, 8 Oct 2018 at 17:15, Diego Russo <Diego.Russo@arm.com> wrote:
Hello,

Currently I'm testing a board type which deploys OE via u-boot-ums. Before flashing the image into the device, LAVA slave modifies the image copying tests definition onto it. Once the image is modified with all the tests, this is dd'ed into the device, booted and tests will be running.
This is OK so far but as soon as we enable signed images (roofs will be R/O but we will be having other R/W partitions) this won't work anymore as we are changing the image and it needs to be resigned. Moreover, this is very board specific.

I'm here to investigate alternative solutions which have a more "generic" approach which also a developer (without LAVA) can run. The only assumption is that *the DUT has always wired network connectivity with the SLAVE*.

Then you can use the existing transfer-overlay support. https://master.lavasoftware.org/static/docs/v2/actions-boot.html#transfer-overlay

The restriction you didn't mention but which must be implemented is: the DUT must have a static IPv4 address.
 

The workflow I have in mind is something like:
1) I have a signed image which I deploy onto the DUT
2) Boot the DUT
3) Instruct the device to get tests from somewhere (either from the SLAVE or internet)

That needs to be done by the automation or it will not scale. The DUT cannot know, in advance, where to find the specific "thing" for this test job as opposed to the slightly different "thing" which is meant to be used by the next or previous test job on another DUT of the same kind right next to it on the same shelf in the same lab - not without building an enormous matrix of almost identical images. It does not scale.

 
4) Run those tests

The step I'd like to solve is 3). I was thinking something like that:
* download/compile all I need on the SLAVE (it is not possible to do it on the DUT due to limited resources/libraries/tooling)
* setup some sort of server http on the SLAVE in order to serve those files
* wget those files onto the DUT
* setup and execute the tests.

The above approach should work WITHOUT LAVA as well. Basically, replace SLAVE with "developer computer"

It needs to be under the control of LAVA. Avoid thinking that the signed image on the DUT should go off and find this thing automatically - there are always temporary path names involved or it simply will not scale. All LAVA does is initiate the call to something like wget on the DUT with a known path name which includes a unique location for this test job (so that another test job on a second DUT in the same lab can simultaneously get it's own) , unpacks it with tar *and* knows where to find the script to start the process.

LAVA provides an apache service on the worker to support the download.

 

Is it something I can architect with LAVA? Does LAVA give me this flexibility?

Thanks for your help

Regards

--
Diego Russo
Staff Software Engineer - diego.russo@arm.com
Direct Tel. no: +44 1223 405920
Main   Tel. no: +44 1223 400400
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - http://twitter.com/diegor
http://www.linkedin.com/in/diegor

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
Lava-users mailing list
Lava-users@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lava-users


--

Neil Williams
=============
neil.williams@linaro.org
http://www.linux.codehelp.co.uk/