Hello again,
I have several test cases where we use LAVA multinode to test hardware and software interfaces externally. E.g. we have an SFTP server running on our DUT. In order to test that, we submit a test using two nodes:
1. The DUT
2. An LXC container
The LXC device connects to the DUT via SFTP and uploads a file. Both sides determine the MD5 sum and the DUT compares them.
This works as long as both the DUT and the LXC device are in the same network (or at least can reach each other via the network).
Now there are more test cases which require additional hardware connections between the worker and the DUT, e.g. a serial interface test. The serial interface on the DUT is connected via an RS232-USB converter to the worker. The LXC can access this converter and send or receive data from the serial interface.
This works as long as the LXC is running on the expected worker the serial interface of the DUT is connected to.
As we are growing our lab, we will add more workers to our setup. There will be LXC devices on all of the workers.
When submitting such a multinode job, which relies on hardware connections between the DUT and the worker, how can I make sure that the LXC part of the job is scheduled on an LXC device on the correct worker?
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,
I'm looking into LAVA and I figured I'd give it a try by flashing a frdm-k64f MCU board and parse its output (the board behaves as a USB to UART adapter through /dev/ttyACM0 at 115200bps). I created the board instance as:
{% extends 'frdm-k64f.jinja2' %}
{% set board_id = '0240000048824e45004a700add89001a8761000097969900' %}
{% set usb_mass_device = '/dev/disk/by-id/usb-MBED_VFS_0240000048824e45004a700add89001a8761000097969900-0:0' %}
I'm able to launch a job (frdm-k64f.job) but LAVA complains and returns:
Invalid job data: ["Invalid device configuration - missing 'commands'"]
So I went looking for an example and found this<https://git.lavasoftware.org/fabo/lava/blob/bc44750733f57de09909f45ba7e65fa…> which defines something called connection_commands as:
{% set connection_commands = {'usb0': 'telnet lab-slave-0 7115'} %}
Based on the documentation<https://docs.lavasoftware.org/lava/connections.html> I'm under the impression that the slave/dispatcher is expected to momentarily open a telnet server on port 7115 and forward the output of the serial port through that server to be retrieved by a client implemented by the master.
If I match the example the dispatcher flashes the board, but a telnet server is never launched on the slave. It's not surprising as at no point did I specify a tty or a baud rate for the dispatcher to connect to the board in order and launch something like:
socat TCP-LISTEN:7115,fork,reuseaddr FILE:/dev/ttyACM0,b115200,raw
When I sit on the slave and manually launch the command the master successfully connects to TCP port 7115. Problem is it does so after the board outputted its results (and obviously it's not the right way to do it).
So I have 3 questions:
* How should a UART connection be specified (/dev/ttyACM0, 115200bps) to LAVA?
* Once the UART connection specified, will the dispatcher buffer the board's output until it is retrieved by the master?
* Why does LAVA rely on a telnet channel instead of the existing zmq channel to forward the output of the board from the slave to the master?
Thanks
Hello,
We have few device types in our LAVA instance that use ums mechanism to be deployed. This has worked well so far but we have now the need to test secure boot flow (BL1, BL2...) and we cannot rely anymore in u-boot for deploying them.
Assuming we have the HW in place to put the DUT in recovery mode, how can we achieve this via LAVA? Do you have an existent example where you automate the recovery mode of a board?
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
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.
Hello everyone,
I have the following entry in my lxc device dictionary:
{% set static_info = [
{'board_id': 'FTXTBHMA'},
] %}
This adds my USB-serial converter installed on the worker machine to the LXC. It appears correctly in the LXC:
root@lxc-generic-remote-5937:~# ls -la /dev/ttyUSB*
crw-r----- 1 root root 188, 0 Jul 30 13:15 /dev/ttyUSB0
crw-r----- 1 root root 188, 1 Jul 30 13:15 /dev/ttyUSB1
crw-r----- 1 root root 188, 2 Jul 30 13:15 /dev/ttyUSB2
crw-r----- 1 root root 188, 3 Jul 30 13:15 /dev/ttyUSB3
I cannot read from or write to it, though:
root@lxc-generic-remote-5937:~# cat /dev/ttyUSB0
cat: /dev/ttyUSB0: Operation not permitted
This does not seem to be a permission issue in the LXC, it fails even if I set all permissions:
root@lxc-generic-remote-5937:~# chmod a+rwx /dev/ttyUSB0
root@lxc-generic-remote-5937:~# cat /dev/ttyUSB0
cat: /dev/ttyUSB0: Operation not permitted
Does anybody have an idea what is missing here?
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
Hello, LAVA Team!
I have question about device description.
I have problems with *pre_power_command*
If I don't use requests : pre_power_command in my job description, i get
error, that no request implementation.
So in my case, I need to switch device to fastboot mode by sending command
via serial connection. And I decided, that pre_power_command is better
solution for me. Cause before fastboot deploying by setting up this command
I will switch device's mode.
And here I stuck, cause I received error message:
no pre_power_command implementation.
Device description:
https://pastebin.com/FLhGUnyH
Job description:
https://pastebin.com/Ts6VUXZe
Error log:
https://pastebin.com/9jXvjxZb
best regards, Ilya
Hi, LAVA Team!
I'm trying to add my new device.
It must be flashed by fastboot.
To turn device into fastboot mode, I need to write "reboot bootloader" via
serial connection.
I have tried
set soft_reboot_command = ['reboot bootloader']
and received error message
lava-lxc protocol: FAILED executing 'lxc-attach -n lxc-hikey-test-4 -- adb
reboot bootloader'
Ilya
Hi,
we have a LAVA test setup working for some time. Automated pipelines are
running tests on different devices in parallel.
After updating to version 2018.10+stretch and changing to in-line job
definitions we started to get some sporadic errors.
The error message shows up after jobs are submitted and the return from the
submission is then used to ask for server job details:
res = lava_server.submit_job(lava_test_job_description)
for entry in res:
job_details = lavasrv.job_details(entry)
...
Resulting in the following error:
lib/python3.5/site-packages/lavac/server.py", line 272, in job_details
raise get_server_error(error, job_id)
lavac.server.NoSuchJob: No such job: 68271.0
Trying to access LAVA WebUI using the jobid (68271.0):
500 Internal Server Error
Reverse for 'lava.scheduler.job.detail' with arguments '('',)' not found. 1
pattern(s) tried: ['scheduler/job/(?P<pk>[0-9]+|[0-9]+\\.[0-9]+)$']
Can you give me a hint about this error?
Thanks!
Hi Milosz,
I am using the Raspberry Pi 3 B+ board as a real target. It has AOSP Pie 9 on it and runs.
I would be interested now, to see like you said if I could run CTS,VTS on the board and omit deploy section.
What should I put in the boot section as method:
Would be the same fastboot or another method? I ask because the board is connected to LAN (and not over USB).
Is it ok just to omit deploy section?
In other words how would Lava know to access the board on ADB over its IP. Where should I set this info?
Example section (Milosz CTS&VTS example):
https://pastebin.com/hBn0pq6U
Hi Lava Users,
I have decided to continue using a real device: a Raspberry Pi 3 B+.
Because I have an iso with Android 9 Pie, to flash the board I want to use
deploy:
to: iso-installer
The question I'm having is:
Is it possible to use this mode to flash the board with ADB via Wifi?
(The board, I connected wifi to our router and I am able to connect with adb using wifi)
(The board does not have USB/OTG interface so the only option is to use ADB on wifi.)
What I try to achieve is deploy the image I have - iso one (flash), with adb using wifi, and run as tests CTS and VTS.
george
-----Original Message-----
From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
Sent: Wednesday, August 21, 2019 11:27 AM
To: George Nistor <george.n(a)l4b-software.com>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] old comercial phones supported by Lava
On Wed, 21 Aug 2019 at 08:00, George Nistor <george.n(a)l4b-software.com> wrote:
>
> Hi,
>
> But I do not understand exactly for example if I can use a Nexus5x; the device is in the list of supported devices Steve McIntyre sent me.
> Milosz Wasilewski said I cannot use it with Lava due to the lack of possibility to force power cycle on them (via serial interface - USB).
>
our current use case doesn't require power cycling the device. It uses the same OS build and tests are executed in chroot environment. This is pretty specific setup for the use case (doesn't require changing kernel).
> To be able to use it requires hw modification of the device?
yes, you need to be able to forcibly power cycle the device. With battery inside the phone this isn't possible, so you have to remove battery and replace it with power supply you can turn off.
>
> What we want to have for the moment is a real device (ex, Nexus 5) on which to run Tradef with Lava.
What is your use case? Are you testing tradefed (ex CTS) changes and stick with the same Android build or do you test Android (kernel, libraries, etc) changes? If it's the former you might be lucky and use existing nexus5 support. If you want to test android using CTS, HW modification is necessary.
milosz
>
> george
>
> -----Original Message-----
> From: Steve McIntyre <steve.mcintyre(a)linaro.org>
> Sent: Tuesday, August 20, 2019 8:51 PM
> To: George Nistor <george.n(a)l4b-software.com>
> Cc: lava-users(a)lists.lavasoftware.org
> Subject: Re: [Lava-users] real devices supported by Lava by default
>
> Hi George,
>
> On Tue, Aug 20, 2019 at 12:54:21PM +0000, George Nistor wrote:
> >
> >I have a question regarding real devices supported by Linaro Lava.
> >
> >Besides these dev boards I found here :
> >https://validation.linaro.org/static/
> >docs/v2/standard-armmp-ramdisk-bbb.html#standard-known-devices
> >
> >Are any other real devices supported in Lava by default? (any
> >commercial phone for example Nexus 5)?
>
> There's a huge set of supported devices. If you don't already have
> LAVA installed, the easiest way to find the list is by looking at the
> set of device type configurations at
>
>
> https://git.lavasoftware.org/lava/lava/tree/master/etc/dispatcher-conf
> ig/device-types
>
> Cheers,
> --
> Steve McIntyre steve.mcintyre(a)linaro.org
> <http://www.linaro.org/> Linaro.org | Open source software for ARM
> SoCs
>
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
