Dear Lava users,
Our embedded SW offers 3 boot modes, selectable from u-boot.
When booting, u-boot offers the possibility to select the boot mode:
Select the boot mode
1: <boot mode 1>
2: <boot mode 2>
3: <boot mode 3>
Enter choice: 1: <boot mode 1>
<boot mode 1> is a default value, used after a counter has expired.
All this is done using the extlinux feature.
We have scripts that allow to select the boot mode, using Kermit. Now, we'd like to integrate this boot mode selection in a Lava job, and our current solution is not compatible.
In Lava we may boot the kernel, modify the extlinux configuration and reboot, but do you know a direct way (with interactive mode maybe) to select the boot mode from u-boot?
Best regards,
Denis
Hello everyone,
I am having problems with timeouts when using the LAVA multinode protocol. Assume the following minimal pipeline with two nodes (device = DUT, remote = some kind of external hardware interfacing with the DUT):
- deploy:
role: device
- boot:
role: device
- deploy:
role: remote
- boot:
role: remote
- test:
role: remote
- test:
role: device
What I would expect: The device is booted first, then the remote is booted. Afterwards, the tests run on both nodes, being able to interact with each other.
The pipeline model seems to be implemented in a way that each node has its own pipeline. This kind of makes sense, because the tests of course have to run simultaneously.
However, in my case booting the device takes a lot more time than booting the remote. This makes the 'test' stage on the remote run a lot earlier than the 'test' stage on the device.
My problem: How do I define a useful timeout value for the 'test' stage on the remote? Obviously I have to take the boot time difference between the two nodes into account. This seems counter-intuitive to me, since the timeout value should affect the actual test only. What happens if I use an image on the device which takes even a lot more time to boot? Or if I insert more testcases on the device which do not need the remote before? In both cases I would have to adjust the timeout value for the remote 'test' stage.
Is this a design compromise? Or are there any possibilities of synchronizing pipeline stages on different nodes? I am thinking of some mechanism like "do not start 'test' stage on remote before 'boot' stage on device has finished".
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hi,
Is there a way to specify an arbitrary parameter, that is board
specific, in device dictionary? The parameter should be available from
test shell. The use case is as follows: DUT is connected to test
supporting hardware (chamelium board in this case). Tests access
supporting hardware using IP address. IP address is 'static' and the
supporting hw is assumed to be always turned on. Supporting hardware
is dedicated to specific DUT and can't be shared (because of HW
connections) between other boards of the same type (similar to energy
probes). Tests run directly on DUT and access supporting hardware from
there.
I found 'exported parameters' in device dictionary docs:
https://master.lavasoftware.org/static/docs/v2/lava-scheduler-device-dictio….
But they only list device_ip, device_mac and storage_info. Is there a
way to extend this list? If not, is there any other way to provide
device specific information to test shells?
milosz
Hi everyone,
I'm writing this email after discussion with Neil.
I'm working at NXP and he told me Linaro wanted to run functional tests on
imx8m
with the new u-boot support.
He told me it requires full open access, no license click-through or
passwords.
Philippe Mazet is more qualified to answer this type of question as I only
use Android atm. He will follow up the discussion.
Here you have the Yocto source code :
https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-l…
You can get the latest GA release with this :
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b
imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml
You can build these sources like this :
DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source ./fsl-setup-release.sh -b
build
But, this will redirect you to a license click-through.
However, you can bypass the license click-through, like "auto accept it"
with this command :
EULA=1 DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source
./fsl-setup-release.sh -b build
We use this bypass to automate builds.
So, let us know if this would be suitable for Linaro's needs.
Best regards,
Axel
Hello Lava-users,
Do we have support in LAVA for deploying to target the SWUpdate images
directly if target supports the swupdate image deployment(
http://sbabic.github.io/swupdate/).
Thanks,
Hemanth.
Hi all,
We're planning to use TI AM4378 IDK in the board farm for testing (http://www.ti.com/tool/TMDSIDK437X) but it seems there is not device-type for this board. I tried to search from these links:
- https://git.lavasoftware.org/lava/lava/tree/master/lava_scheduler_app/tests…
- https://git.linaro.org/lava/lava-lab.git/tree/shared/device-types
Did I just miss it, or is it missing from the device-types? If it is missing, are there any templates available / what template could be used as a base for the device
Br
Olli Väinölä
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.
Hi All,
I have a Rpi3 board with android install on it, it can be accessed using
adb from my Linux PC.
I am successfully able to use Lava-LXC for testing a device.
Can someone please share the steps how I can use LAVA to test an android
device and how the setup will look like. If anyone can share a test job
with some basic android tests would be very helpful.
Thanks,
Ankit
Hello Lava users,
I'm trying to build a query to monitor all the test jobs done in a given period. Let's say all the jobs done in January, just to check the robustness of my setup (incomplete jobs rate).
In the query interface, I can add a condition on start_time of a job, but only with a "greater than" operator, when I want to add also a condition on start_time "less than".
Do you have any hint to do this?
Best regards,
Denis
Hello,
I have the following setup: a WaRP7 which exposes a network connection over USB gadget driver (http://trac.gateworks.com/wiki/linux/OTG#g_etherGadget)
A possible test case is to have some process running on the LAVA dispatcher (within a LXC container) which targets the WaRP7 over this network interface.
Through LXC I'm able to passtrhough this interface from the host to the container and use it within the container (via /etc/lxc/default.conf)
If a test requires the reboot of the WaRP7, the usb0 interface disappears from the container. When the WaRP7 boots again the usb0 interface is available on the host (but not in the container).
Things I tried or thought about:
* I tried synchronizing boots both of the WaRP7 and LXC container but it seems not possible to "reboot" (restart) a container within the same job execution.
* Is it possible to "restart" a container during a job execution?
* Outside LAVA it is possible to run a command (lxc-device --name diegor-test -- add usb0) which re-passthrough the interface from Linux to LXC container.
* Is it possible to run the above command ad job execution time on the lava dispatcher?
How can I solve this situation?
Cheers
--
Diego Russo
Staff Software Engineer - diego.russo(a)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/diegorhttp://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.
