Hi,
For imx armv7 series board, tee is default not built in, there is a separate file there to play the role.
I'm not sure for next scenario, if LAVA could handle it with "method: u-boot commands: nfs"? Could you give some guide?
setenv autoload no
setenv initrd_high 0xffffffff
setenv fdt_high 0xffffffff
dhcp
setenv serverip 10.192.244.84
tftp 0x12000000 trial/zImage-imx6qsabresd.bin
tftp 0x18000000 trial/zImage-imx6q-sabresd.dtb
tftp 0x20000000 trial/uTee-6qsdb
tftp 0x12C00000 trial/ramdisk.cpio.gz.uboot
bootm 0x20000000 0x12C00000 0x18000000
If not, if you have buffer to add the support? Or we can submit a MR for review?
Thanks Antonio for the clarify.
A side question:
For docker test shell, if possible add more docker options for user? E.g. bind mount, etc.
A scenario is:
If we have some code needed when test, currently, we could just inject it into docker image when do docker build, or when test git clone the code from network.
You know docker test shell use `--rm`, means every time, we need to git clone it, or if a small changes we need to build the image.
A bind mount there to mount our code may make things easier for us?
-----Original Message-----
From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of lava-users-request(a)lists.lavasoftware.org
Sent: Saturday, June 6, 2020 8:00 PM
To: lava-users(a)lists.lavasoftware.org
Subject: [EXT] Lava-users Digest, Vol 22, Issue 7
Caution: EXT Email
Send Lava-users mailing list submissions to
lava-users(a)lists.lavasoftware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…
or, via email, send a message with subject or body 'help' to
lava-users-request(a)lists.lavasoftware.org
You can reach the person managing the list at
lava-users-owner(a)lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..."
Today's Topics:
1. Re: [EXT] Re: docker shell cannot handle adbd. (Antonio Terceiro)
----------------------------------------------------------------------
Message: 1
Date: Fri, 5 Jun 2020 09:26:18 -0300
From: Antonio Terceiro <antonio.terceiro(a)linaro.org>
To: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] [EXT] Re: docker shell cannot handle adbd.
Message-ID: <20200605122618.GA359587(a)linaro.org>
Content-Type: text/plain; charset="us-ascii"
On Fri, Jun 05, 2020 at 07:06:16AM +0000, Larry Shen wrote:
> Hi, Milosz,
>
> Maybe I understand wrong, but I already see there is code like next to
> add dynamic device node to docker container.
>
> I tried it in manual, adb find devices after a new device node added
> with next code. But I don't see the docker shell try to call it with
> some way. What's the aim of next code if you did not want to use it?
> Could you double confirm internal maybe some guys is handling it, but
> just in process? Could you do me a favor inform me your plan if my
> guess is true?
>
> I don't think people could switch from lxc to docker on android if
> this not support, maybe my environment wrong or anything else?
Yes, you are right. The way the docker test shell currently works won't support such a use case.
First, there was an issue with the udev rules being too strict, which was recently fixed and will be in the next release:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…
This issue that you mention also needs to be fixed; I created an issue to track and I will work on it:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…
Hello Lava-Users,
For minimal boot setup should the dispatcher with which target is configured should have apache server setup configuration ?Having the Lava server version of 2019.11.
When trying to pull test suites from the dispatcher with overlay mechanism facing http not found error during job execution.
--2020-06-24 14:50:07-- http://xx.xx.xx.31/tmp/21866/compress-overlay-mmk3i76o/overlay-1.4.2.4.tar.…
Connecting to xx.xx.xx.31:80... connected.
HTTP request sent, awaiting response... 404 Not Found
Also needed suggestion on
Presently trying with the multi deploy mechanism where in 1st deploy boot test method we boot with nfs boot and wget the latest wic image and write that image to hard disk as test case.
In the scenario of writing of Image fails how should we exit from job execution without going to 2nd deploy boot test
Thanks,
Hemanth.
Hello,
Situation with running Docker containers inside the official
Docker-based LAVA setup
(https://git.lavasoftware.org/lava/pkg/docker-compose) was already
discussed at least once recently.
LAVA starts to offer more and more convenient usages of Docker
containers to extend its functionality (e.g.
https://connect.linaro.org/resources/ltd20/ltd20-304/), and people
start to leverage it. For docker-compose based setup, that effectively
means running Docker containers inside the docker-compose, and that
currently doesn't work.
Another reason for raising this matter again are the apparent plans to
migrate components of the production LAVA setup as run by Linaro
(https://validation.linaro.org/) to Docker-based setup. The concern is
that if Docker-in-Docker scenario is not explicitly accounted and
planned for, then there will be a regression due to this switchover.
So, I posted
https://git.lavasoftware.org/lava/pkg/docker-compose/-/issues/7 with
more detailed discussion, and would be ready to follow up with a patch
(we just need to decide what kind of patch, please the proposed
options there).
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
What is the procedure to follow in order to upgrade LAVA to a new release
while preserving the test results database? I am using the docker-based
setup.
I tried
>
> sudo tar cvzf lava-server-pgdata-backup.tgz
> /var/lib/docker/volumes/lava-server-pgdata
> <wipe away old LAVA, rebase to latest>
> sudo tar xvzf lava-server-pgdata-backup.tgz -C
> /var/lib/docker/volumes/lava-server-pgdata
But the old results don't seem to show up in the UI after the upgrade. Also
the user accounts, settings, etc. are gone, and it'd have been nice to keep
them.
Thanks,
Vincent
--
-----------------------
Vincent Wan
Linaro.org
Hi, guys,
I have a job like next:
- test:
timeout:
minutes: 10
docker:
image: terceiro/android-platform-tools
definitions:
- from: inline
name: smoke-case
path: inline/install-google-fastboot.yaml
repository:
metadata:
format: Lava-Test Test Definition 1.0
name: smoke-case-run
description: Run smoke case
run:
steps:
- env
- sleep 10
- adb devices
- adb root
- sleep 10
- adb devices
- lava-test-case get-release-version --shell adb shell getprop ro.vendor.build.fingerprint
It output as next:
+ sleep 10
+ adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
040c41d4d72d7393 device
+ adb root
+ sleep 10
+ adb devices
List of devices attached
+ lava-test-case get-release-version --shell adb shell getprop ro.vendor.build.fingerprint
<LAVA_SIGNAL_STARTTC get-release-version>
Received signal: <STARTTC> get-release-version
error: device '040c41d4d72d7393' not found
<LAVA_SIGNAL_ENDTC get-release-version>
Received signal: <ENDTC> get-release-version
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=get-release-version RESULT=fail>
Received signal: <TESTCASE> TEST_CASE_ID=get-release-version RESULT=fail
You know "adb root" will make usb bus change during run, so could docker shell handle this? How can I make above work? Thanks.
Hello Team,
With the existing JLink.py library i have modified and able to flash
multiple *.bin files in single instance/Job. I have used method : Jlink in
boot:
But On the Renesas boards, After flash the binaries through Debugger Say
JLink,
Will get U-boot prints at ttyACM0. I can see the prints through ser2net
telnet host.
Q1. How to send command at uboot level while using JLink boot method. I
need to *send run xa_boot from uboot prompt: =>*
*Below is sample Job description :*
- boot:
method: jlink
prompts: ["=>"]
commands: ["run xa_boot"]
timeout:
minutes: 5
*i am getting following error :*
*Invalid job definition:*
extra keys not allowed @ data['actions[1]']['boot']['jlink']['prompts']
I tried with out prompts and commands key values in job description Job
terminated once the flash has done.
Attached logs for reference:
Looking forward for your kind response
Thanks
Regards
Nagendra S
Hello Team,
To get better understanding the lava frame work , Can any one share me the code
flow diagram for LAVA.
I have gone through the available Doc's in lava, but i did not understand
the flow properly.
thanks & Regards
Nagendra S
Hi Team,
I am using U-boot method to boot up to linux.
But at the end of booting means before gets the login prompt it got hanged
at here..
[ 3.759014] Console: switching to colour dummy device 80x30[?25lfbv - The
Framebuffer Viewer/root/images/renesas_logo-800x480.jpg800 x 480[?25hWelcome
to Buildroot
after 2 minutes got *buildroot login: [ 90.929835] random: crng init done *
due to this Lava did not fetch "root" string and unable to login. And i
have seen stange string in lava while booting
[?25h .
I am able to boot manually (with out lava) with out an issue. And i did
not get [?25h string ..
How to avoid this problem .Attaching job description/device dictionary
files .
[ 2.837060] Run /sbin/init as init process�Starting logging: OKread-only
file system detected...doneStarting network: OKWed Oct 31 09:00:00 UTC 2018[
3.759014] Console: switching to colour dummy device 80x30[?25lfbv - The
Framebuffer Viewer/root/images/renesas_logo-800x480.jpg800 x 480[?25hWelcome
to Buildrootbuildroot login: [ 90.929835] random: crng init done
Hi,
The Renesas board I am using behaves as a USB to UART adapter through
/dev/ttyACM0 at 115200bps. Created the board instance in device dictionary
file as:
{% extends 'rza1h.jinja2' %}
{% set board_id = '0000000000001' %}
{% set console_device = 'ttyACM0' %}
{% set baud_rate = baud_rate|default(115200) %}
{% set usb_mass_device =
'/dev/serial/by-id/usb-Renesas_Electronics_Corporation_Renesas_RSK_USB_Serial_Port_0000000000001-if00'
%}
{% set connection_list = ['usb0'] %}
{% set connection_tags = {'usb0': ['primary', 'telnet']} %}
{% set connection_commands = {'usb0': 'telnet localhost 2000'} %}
With the above configuration, Dispatcher(Remote worker) flashes the board
through JLink.And I can see flashing log in the Job console.
But Even i specified the UART connection like (/dev/ttyACM0, 115200bps). I
am not getting the u-boot logs on /dev/ttyACM0. Did i miss any other
configuration to add in device dictionary???.
Manaually, I can able to see uboot prints on the console through minicom
with /dev/ttyACM0 with 115200bps.
Attaching logs for reference.
Thanks
Regards
Nagendra S
---------- Forwarded message ---------
From: Nagendra Singamsetti <nag.singam91(a)gmail.com>
Date: Fri, May 22, 2020 at 8:58 AM
Subject: Re: [EXT] [Lava-users] Test jobs to boot the targets through
trace32
To: Andrei Gansari <andrei.gansari(a)nxp.com>
Hi Andrei,
Good Morning !!
*lava-dispatcher machine did not reach the serial on the device*
I have debug the issue. Issue is telnet socket connection is not up. Now i
am able to flash Renesas board using Jlink Debugger through LAVA.
Attached job
[image: lava_jlink_uboot_download.png]
[image: lava_jlink_uboot_flash.png]
Thanks!! for your good time to debug this issue.
Now i am able to flash U-boot @specific offset say-0x18000000. Need to
flash .dtb,Kernal & rootfs. Should i run again with different Job's or Can
i run in single Job?? . Can you Please share your thoughts !!
Regards
Nagendra S
On Thu, May 21, 2020 at 5:45 PM Nagendra Singamsetti <nag.singam91(a)gmail.com>
wrote:
> Hi Andrei,
> Thanks for your kind response :) :)
>
> 1.
> *Is your board flashed with the desired uboot? You can check by erasing
> the flash and then running lava, the desired uboot should be flashed on the
> board.*
> Ans. Using lava, i am unable to flash with u boot also. As you mention I
> have erased the flash up to 0 0x2000000 and tried again getting same
> issue.error_msg: Invalid job data: ["Invalid device configuration - missing
> 'commands'"].
>
> 2.* Can you lava-dispatcher machine reach the serial on the device?*
> Ans. In rza1h.jinja2, device-type file: i have added following commands to
> open serial console
> {% set console_device = console_device|default("ttyACM0") %}
> {% set baud_rate = baud_rate|default(115200) %}
> {% set bootloader_prompt = bootloader_prompt|default("=>") %}
>
> But i don't know* lava-dispatcher** machine reach the serial on the
> device* or not. Due to job immediately terminated.
> *Manually i am able to flash through JLink with following commands* :
> JLinkExe -speed 15000 -if JTAG $JTAGCONF -device R7S721001 -CommanderScript
> load_spi_uboot.txt
>
> *load_spi_uboot.txt contains following:*
> rx 100
> exec SetSkipProgOnCRCMatch=0
>
> //
> // Download application into QSPI flash
> //
>
> loadbin u-boot.bin,0x18000000
> //verifybin u-boot.bin,0x18000000
>
> exit
>
>
> 3. board_id:* '{{ board_id|default('0000000000') }}',usb_vendor_id:
> '1366',usb_product_id: '0101' refers to JLink connected usb right. Can i
> change directly in the device-type .jinja2 file.*
>
> I am very thankful, if you can share your sample device jinja2 ,
> device-type (jinja2 file) and working job description file.
> I am just stuck with this issue issue.error_msg: Invalid job data:
> ["Invalid device configuration - missing 'commands'"] from last 5 day's. i
> gone through all the mail chain from lava-users but did not get proper
> information.Don't know how to debug this issue.
> Your presence and input is more valuable for me .
>
> I am attaching used job description and device& device-type .jinja files
> for your reference.
>
>
>
> On Wed, May 20, 2020 at 4:04 PM Andrei Gansari <andrei.gansari(a)nxp.com>
> wrote:
>
>> Hello Nagendra,
>>
>>
>>
>> Looks like *error_msg*: Invalid job data: ["Invalid device configuration
>> - missing 'commands'"] is issued from serial.py so the validation reached
>> executing serial commands.
>>
>>
>>
>> 1. Is your board flashed with the desired uboot? You can check by
>> erasing the flash and then running lava, the desired uboot should be
>> flashed on the board.
>> 2. Can you lava-dispatcher machine reach the serial on the device?
>> 3. Most likely it’s this pattern in job*.yaml it should look for the
>> printed uboot header of prompt when the board is reset. The configuration
>> below is used by Zephyr RTOS tests.
>>
>> - test:
>>
>> monitors:
>>
>> - name: tests
>>
>> * start: Running test suite common_test*
>>
>> * end: PROJECT EXECUTION SUCCESSFUL*
>>
>> * pattern: '(?P<result>(PASS|FAIL)) - (?P<test_case_id>.*)\.'*
>>
>> fixupdict:
>>
>> PASS: pass
>>
>> FAIL: fail
>>
>>
>>
>> Regards,
>>
>> Andrei G.
>>
>>
>>
>> *From:* Nagendra Singamsetti <nag.singam91(a)gmail.com>
>> *Sent:* Tuesday, May 19, 2020 8:01 PM
>> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>;
>> lava-users(a)lists.lavasoftware.org
>> *Cc:* andrei.gansari(a)linaro.org
>> *Subject:* Re: [EXT] [Lava-users] Test jobs to boot the targets through
>> trace32
>>
>>
>>
>> *Caution: *EXT Email
>>
>> Hi Andrei, Team,
>>
>>
>>
>> Issue is solved this is because of lava-server & remote worker version
>> mismatch. I tried to boot the DUT (RZA1_RSA , Renesas) Using the
>> rza1h.jinja2 file & job description with Segger Jlink debugger . I am
>> getting following issue:
>>
>> -
>> - *error_msg*: Invalid job data: ["Invalid device configuration -
>> missing 'commands'"]
>> - *error_type*: Job
>>
>> [image: renesas_jlink_Invalid_device_configuration.png]
>>
>> I am looking forward for your kind response..
>>
>>
>>
>> thanks
>>
>>
>>
>> Regards
>>
>> Nagendra S
>>
>>
>>
>>
>>
>> On Tue, May 19, 2020 at 8:12 PM Nagendra Singamsetti <
>> nag.singam91(a)gmail.com> wrote:
>>
>> Hello Andrei , Team,
>>
>> To get hands on knowledge, I have tried to boot Renesas images using
>> JLink & Renesas - RZA1_RSA ver2 board on QSPI flash.
>>
>> I took frdm-k64f.janja2 file as a reference created *rza1h.jinja2* as a
>> device-type. And added device as a *renesas_worker1(DUT)* under
>> device-type *rza1h.* And connected to remote worker.
>>
>> On Remote worker, Segger Jlink debugger is connected to the DUT with jtag
>> cable.
>>
>>
>>
>> But while submitting Job definition i am getting following error.
>>
>>
>>
>> [image: renesas_jlink_job_error.png]
>>
>>
>>
>> Attaching Job files and device-type file for reference.
>>
>> First time i am booting the hardware with Jlink using LAVA framework.
>> Please help me out to debug this issue.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards
>>
>> Nagendra S
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 27, 2020 at 5:28 PM Andrei Gansari <andrei.gansari(a)nxp.com>
>> wrote:
>>
>> Please have a look at my pull requests:
>>
>>
>>
>> https://git.lavasoftware.org/lava/lava/-/merge_requests/608/diffs
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…>
>> - script changes
>>
>> https://git.lavasoftware.org/lava/lava/-/merge_requests/758/diffs
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…>
>> - job sample
>>
>>
>>
>> With JLink you need to install Segger’s software on the server where Lava
>> dispatcher resides (in case you have multiple Lava servers).
>>
>> https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.segge…>
>>
>>
>>
>>
>>
>> Regards,
>>
>> Andrei
>>
>>
>>
>> *From:* Nagendra Singamsetti <nag.singam91(a)gmail.com>
>> *Sent:* Monday, April 27, 2020 12:42 PM
>> *To:* Andrei Gansari <andrei.gansari(a)nxp.com>
>> *Cc:* andrei.gansari(a)linaro.org; lava-users(a)lists.lavasoftware.org
>> *Subject:* Re: [EXT] [Lava-users] Test jobs to boot the targets through
>> trace32
>>
>>
>>
>> *Caution: *EXT Email
>>
>> Hi Andrei,
>>
>>
>>
>> Wonderful!!,
>>
>> Thanks for your time ..
>>
>> I need bit support from you, don't mine :) ,Can you please share your
>> Jink scripts. I will use these as a reference will write comparable boot
>> method for trace32 .
>>
>>
>>
>> And if you can, Please share the appropriate Doc (link) to
>> setup(interface) other software's in Lava server. Setup Jlink with Lava
>> server also fine.
>>
>>
>>
>>
>>
>> Regards
>>
>> Nagendra S
>>
>>
>>
>> On Mon, Apr 27, 2020 at 2:10 PM Andrei Gansari <andrei.gansari(a)nxp.com>
>> wrote:
>>
>> Hello Nagendra,
>>
>>
>>
>> JLink was added as most NXP mcus use this interface, there is no support
>> for T32 in Lava as far as I know.
>>
>> Even if they use the same JTAG interface standard, Segger and Lauterbach
>> use different hardware and software to interact.
>>
>> I’ve used JLinkExe command line software (from Segger) to control the
>> debugger, in the case of T32 you will probably need to use Lauterbach’s
>> Trace32 command line software + scripts, such as:
>> https://stackoverflow.com/questions/24883140/controlling-trace32-via-comman…
>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackover…>
>>
>> Haven’t used Trace32 GUI software for some years, never used the command
>> line.
>>
>>
>>
>> You can probably create a flashing script starting form JLink scripts,
>> you need to:
>>
>> - setup trace32 software on your Lava server
>> - learn how to use the command to flash your board using a cmm script
>> - change JLink scripts with T32 commands and cmm script generation
>> - pull request your changes so others can benefit 😊
>>
>>
>>
>> Andrei Gansari
>>
>>
>>
>> *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On
>> Behalf Of *Nagendra Singamsetti
>> *Sent:* Saturday, April 25, 2020 9:05 AM
>> *To:* Kumar Gala <kumar.gala(a)linaro.org>; andrei.gansari(a)linaro.org
>> *Cc:* lava-users(a)lists.lavasoftware.org
>> *Subject:* [EXT] [Lava-users] Test jobs to boot the targets through
>> trace32
>>
>>
>>
>> *Caution: *EXT Email
>>
>> Hi Kumar, Andrei
>>
>>
>>
>> From the previous lava- mailing list i have seen that you people
>> addressed jlink debugger information as like this :
>>
>> *On Thu, Jan 23, 2020 at 7:33 PM Andrei Gansari <andrei.gansari at nxp.com <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…>>*
>>
>> >>* wrote:*
>>
>> >>
>>
>> >>* From the screenshot it looks like you have a version of LAVA that does*
>>
>> >>* not support jlink boot method.*
>>
>> >>
>>
>> >>* JLink was added in version 2019.10-1*
>>
>>
>>
>>
>>
>> >>* On Tue, Nov 26, 2019 at 2:36 PM Andrei Gansari <andrei.gansari at nxp.com <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…>>*
>>
>> >>* wrote:*
>>
>> >>
>>
>> >>* I’ve tested lava+jlink on Cortex M with both onboard debugger and*
>>
>> >>* external debugger, like the one you referenced.*
>>
>> >>
>>
>> >>* You should change the following if needed:*
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>* address:*
>>
>> >>
>>
>> >>* *0x00000000**
>>
>> >>
>>
>> >>* options:*
>>
>> >>
>>
>> >>* - '-device *MK64FN1M0xxx12'**
>>
>> >>
>>
>> >>* - '-if SWD'*
>>
>> >>
>>
>> >>* - '-speed 4000'*
>>
>>
>>
>> Can you please let me know, whether the latest lava version can support trace32 boot method instead jlink/cmsis-dac. trace32 debugger tool is designed by lauterbach and it is licensed one.
>>
>> I am bit afraid whether this support is available from lava server or not as Jlink support added recently.
>>
>> https://www2.lauterbach.com/pdf/app_t32start.pdf <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww2.laut…>
>>
>> We need trace32 debugger support as we are using cortex-M55 processor operations over here.
>>
>> I am looking forward your kind support
>>
>>
>>
>> thanks
>>
>> Regards
>>
>> Nagendra S
>>
>>
Sorry, I missed title, send again.
Hello, Milosz,
Another question:
I see your documentation suggest to use pdudaemon. But I had a look for you
validation lava lab:
https://validation.linaro.org/scheduler/device/hi6220-hikey-r2-02/devicedict,
I see you use /usr/local/lab-scripts/snmp_pdu_control
I want to know why your lab not use the one which you suggest? I had a look
for pdudaemon, found it won't wait there until PDU operation finish. Will
this have any issue? Will next logic start before the pdu really finish the
operation?
Hi Kumar, Andrei
>From the previous lava- mailing list i have seen that you people addressed
jlink debugger information as like this :
*On Thu, Jan 23, 2020 at 7:33 PM Andrei Gansari <andrei.gansari at
nxp.com <https://lists.lavasoftware.org/mailman/listinfo/lava-users>>
*>>* wrote:
*>>>>* From the screenshot it looks like you have a version of LAVA that does
*>>* not support jlink boot method.
*>>>>* JLink was added in version 2019.10-1*
>>* On Tue, Nov 26, 2019 at 2:36 PM Andrei Gansari <andrei.gansari at nxp.com <https://lists.lavasoftware.org/mailman/listinfo/lava-users>>
*>>* wrote:
*>>>>* I’ve tested lava+jlink on Cortex M with both onboard debugger and
*>>* external debugger, like the one you referenced.
*>>>>* You should change the following if needed:
*>>>>>>>>* address:
*>>>>* *0x00000000*
*>>>>* options:
*>>>>* - '-device *MK64FN1M0xxx12'*
*>>>>* - '-if SWD'
*>>>>* - '-speed 4000'*
Can you please let me know, whether the latest lava version can support
trace32 boot method instead jlink/cmsis-dac. trace32 debugger tool is
designed by lauterbach and it is licensed one.
I am bit afraid whether this support is available from lava server or
not as Jlink support added recently.
https://www2.lauterbach.com/pdf/app_t32start.pdf
We need trace32 debugger support as we are using cortex-M55 processor
operations over here.
I am looking forward your kind support
thanks
Regards
Nagendra S
Dear Sir/Madam,
I'm new to LAVA. I'm still in initial stage to use lava in our farm. I use
customized board with Qualcomm's chip.
Recently I met a question, a very simple job, sometimes when I start to
operate uboot, the serial have chance to be closed. They I set retry in
lava job, let it retry a lots of times, but looks never successfully open
the serial again.
But, after job finish, I quickly open the serial in manual, it's ok!
I search your code a lot, and found in shell.py there is one comments, I
want to know is this the reason that I failed to retry for serial? When
will you fix it?
*# FIXME: deliberately closing the connection (and starting a new one)
needs to be supported.*
*Cheers,*
*Peter*
Hi Lava folks,
I am new to LAVA and trying to get some basic understand of lava. I am facing issues while I trying to set up a docker device in lava following the doc: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal…
Steps followed:
1. I have installed Debian VM on my mac book pro.
2. Installed lava: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal…
* Enabled lava site in apache “Production releases” https://docs.lavasoftware.org/lava/installing_on_debian.html (Btw, this step seems to be missing)
* Config like “ALLOW_HOSTS<https://docs.lavasoftware.org/lava/advanced-installation.html?highlight=all…>”, CSRF etc: (a
* Created one super user: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/config…
* Created a token (for lavacli): sudo lava-server manage tokens add --user root
1. Setup docker device for running tests: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/device-setup/do… ( I am following command line using lava-cli)
* $LAVACLI device-types add docker
* $LAVACLI devices add --type docker --worker buster.localdomain docker01
* $LAVACLI devices dict set docker01 test.jinja2 (test.jinja2 contains {% extend "docker.jinja2" %} )
* $LAVACLI devices update --health UNKNOWN docker01
After step “3”, I have the following error: “Configuration Error: missing or invalid template.”
I am assuming there is some pre-condition I am not meeting for docker device. How can I get some more debug information on this? Can you help?
Cheers,
Saheer Babu
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, Milosz,
Another question:
I see your documentation suggest to use pdudaemon. But I had a look for you
validation lava lab:
https://validation.linaro.org/scheduler/device/hi6220-hikey-r2-02/devicedict,
I see you use /usr/local/lab-scripts/snmp_pdu_control
I want to know why your lab not use the one which you suggest? I had a look
for pdudaemon, found it won't wait there until PDU operation finish. Will
this have any issue? Will next logic start before the pdu really finish the
operation?
Hi,
We have a problem here needs your help, as it's critical to us, could you give some suggestion? Thanks in advance.
You know, we submit a MR here about reset shell: https://git.lavasoftware.org/lava/lava/-/merge_requests/1023
It's nearly compatible from 2018.11 to 2020.04 release when we patch it in local, the only changes I remember is once upon a time you changed all "internal_pipeline" to "pipeline", so we had to follow the new name.
But in yesterday's 2020.05 release, I saw this commit: https://git.lavasoftware.org/lava/lava/-/commit/eefeef1864cc055c48215169b61…
In this commit, the test action no longer been added as before like next:
def __init__(self, parent, parameters):
super().__init__(parent)
self.action = TestShellRetry()
self.action.job = self.job
self.action.section = self.action_type
parent.add_action(self.action, parameters)
It becomes next:
@classmethod
def action(cls, parameters):
return TestShellRetry()
Correspondingly, in parse.py, it becomes from next:
action(pipeline, parameters)
to next:
action = cls.action(parameters)
That means "parent pipeline" no longer been passed to next level pipeline, parse.py will responsible for low level action inject into pipeline.
Above change is the key issue we encountered as in our "ResetTestShell" we need to reuse the parameters of "Boot" in same namespace, we need it to operate UBoot & Login again after device reset, like next:
def __init__(self, parent, parameters):
super().__init__(parent)
boot_action_para = None
for per_action in parent.actions:
if per_action.parameters["namespace"] == parameters["namespace"]:
if per_action.__class__.__base__.__name__ == "BootAction":
boot_action_para = per_action.parameters
self.action = TestShellLoop(boot_action_para)
self.action.job = self.job
self.action.section = self.action_type
parent.add_action(self.action, parameters)
You see we could get the "Boot" action from its parent action, thus we could get the boot action's parameters defined in job.yaml, then reconstruct the boot action, inject it as a internal action to our own test action.
But now, we can't do it as parent action no longer be passed to low level action...
Could you give me some suggestion on it, if any other way I could get the parameters of boot action when I'm in test action?
Thanks again.
Regards,
Larry
Hi,
I am looking into https://git.lavasoftware.org/lava/pkg/docker-compose
I have few questions about it:
* Are there guidelines somewhere about how to administrate a "master only" instance run from this docker-compose? Like tutorials about creating/restoring a backup, periodic maintenance/cleanup, restart one of the containers idenpendantly, upgrade versions, etc...
* Is there an easy way to inject a backup created from a previous instance? (backup created with pg_dump. Note that I am not psql expert at all...)
* Is LAVA coordinator supported in this docker solution ?
Many thanks,
Philippe
Hi,
I am looking for the LTP test suite included(inbuild) rootfs.cpio file for
the Qualcomm Snapdragon (arm64) seris.
Please can some one let me know as where can I find this .cpio file in
Linaro's prebuild releases?
Regards,
Koti
Oh, the action indeed DOES cause an infrastructure error if it fails, my command simply did not return an error in case of a failure.
Sorry for the noise!
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Schlachthofstrasse 20
21079 Hamburg
Direct: +49 40 791 899 - 183
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
-----Ursprüngliche Nachricht-----
Von: Tim Jaacks
Gesendet: Donnerstag, 30. April 2020 16:32
An: lava-users(a)lists.lavasoftware.org
Betreff: Evaluating return value of user_commands
Hello everyone,
I am using a command action with pre-defined user_commands in the device dictionary for switching relays, as described here:
https://master.lavasoftware.org/static/docs/v2/actions-command.html
The return value does not seem to be evaluated, though. The test continues even if my user_command fails. I would assume that this causes an infrastructure failure, resulting in an incomplete job. Why is this not the case?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Schlachthofstrasse 20
21079 Hamburg
Direct: +49 40 791 899 - 183
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 everyone,
I am using a command action with pre-defined user_commands in the device dictionary for switching relays, as described here:
https://master.lavasoftware.org/static/docs/v2/actions-command.html
The return value does not seem to be evaluated, though. The test continues even if my user_command fails. I would assume that this causes an infrastructure failure, resulting in an incomplete job. Why is this not the case?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Schlachthofstrasse 20
21079 Hamburg
Direct: +49 40 791 899 - 183
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 team,
i am trying to login IRC channel for #linaro-lava.
https://webchat.freenode.net/#linaro-lava
But , There is no register option for new user. It takes me to the group as
Unregistered user. Please share the proper link to complete
the registration for #linaro-lava.
thanks
Regards
Nagendra S
Hi team,
I am new to lava-server. I have written and uploaded the job description
for QEMU-arm64 to boot. But I can see in logs both kerenl
Image-qemuarm64.bin and rootfs core-image-minimal-qemuarm64.ext4 files are
downloaded in /var/lib/lava/dispatcher/tmp/* directory.
But i am getting following error .
auto-login-action: Wait for prompt ['Linux version [0-9]'] (timeout
00:02:00)
*W: /etc/qemu-ifup: no bridge for guest interface foundqemu-system-aarch64:
-kernel
/var/lib/lava/dispatcher/tmp/27/deployimages-otsvre77/kernel/Image-qemuarm64.bin:
Could not open
'format=raw,file=/var/lib/lava/dispatcher/tmp/27/deployimages-otsvre77/rootfs/core-image-minimal-qemuarm64.ext4':
No such file or directoryConnection closed*
*Attaching .yaml file for job discription.* Please let me know if i miss
anything.
Note : LAVA-SERVER version:version: 2019.01-5
QEMU boot command:sudo qemu-system-aarch64 -kernel Image-qemuarm64.bin
-netdev tap,id=net0,ifname=tap1,script=no,downscript=no -device
virtio-net-device,netdev=net0 -machine virt -cpu cortex-a57 -drive
id=disk0,file=core-image-minimal-qemuarm64.ext4,if=none,format=raw -device
virtio-blk-device,drive=disk0 -no-reboot -nographic -m 512 --append
"root=/dev/vda rw console=ttyAMA0,38400 mem=512M highres=off ip=192.168.7.4:
:192.168.7.3:255.255.255.0 rootfstype=ext4 console=ttyS0"
Tested and working fine on my debian machine(with out lava server)
thanks
Regards
Nagendra S
Hi Team,
Hi Team,
Thanks for giving kind support. We are booting *ARM-cortexM targets* using
lauterbach - trace32 debugger.
http://www.embeddedindia.com/lauterbach-gmbh.html
I would like to know *lauterbach** -trace32 debugger support* in lava
If support is available, Please share me the supported Device-type jinja
file or share me the reference file.
Please let me know anything required from my side.
I am looking forward your kind support
thanks
Regards
Nagendra S
Hi Team,
Today i have started working with remote worker. But In Lava-server Admin
page i have noticed that default lava-worker went office where as remote
worker operations are working fine as expected.
1. Is this expected behavior ??
On command prompt i can see lava-slave status as Online
[image: default_worker_onserver_command_line showing_online.png]
Where as On webpage it is showing offline:
[image: default_worker_onserver_webpage_status_offline.png]
The devices connected to default worker also showing offline.
2. Can we rename hostname for remote worker??
Thanks !!
Regards
Nagendra S
Hi, guys,
I have a question after listen Docker feature for Android testing<https://linarotechdays.sched.com/event/ZZFc/ltd20-103-improved-android-test…>, and the question is a little long.
1. I want to say sorry that I haven't ever tried it on android because currently not urgent for us to switch from lxc to docker.
But my real question is related to this feature at least I think.
2. The whole story is:
We have a device which use the "tftpboot(deploy) -> nfs(boot) -> shell(test)" mode to test, that's ok.
But now we have a team which for their testcases, they need to define other logic which behavior totally different with current lava solution.
There is legacy code on pc which we want to reuse, so the quicker way for us is to use docker device, in it we could do anything to control the device.
What we tried is:
- Deploy (to: docker)
- Boot (method: docker)
- Test
It's ok, as you see we could use the connection from boot in test. But as you know, not all device type accepts docker actions.
Then, I find the option after you give the presentation in linaro tech share, use docker test.
3. I tried the v2020.02 release, it's ok to use next with any device type in our job to do my things.
- test:
docker:
image: ubuntu:18.04
Although some android related log printed like "- ANDROID_SERIAL='xxx'", but I can bear.
4. Things broken when you improve this feature in v2020.04, you add next in pipeline:
WaitDeviceBoardID(self.get_board_id()
Then, the pipeline will have to wait for a udev event, but in our case, we don't have, we control device with "remote telnet device", then job hang.
5. So, my question here is: "What's the roadmap of this docker test action"?
a) Is it just for android scenario?
b) Why we can't make it works for more common scenario?
My opinion here is: with this docker test action, we even no longer need the old "docker deploy + docker boot"?
c) For this docker test, most of docker operation was written fixed in docker test, if possible to add in some place which user could configure? Like, if I want to add "-t", I can't control that although you define the interface in "DockerRun" with "def tty(self):", and others like more docker bind mounts etc?
6. BTW, a side question related to android (As definitely someday we need to switch from lxc to docker, I use this chance to ask the question).
What will happened if there is adbd restart or pdu reboot in "docker test"? You add "-device" for the usb bus (I'm not sure, just think it same way as lxc), but during adbd restart or pdu reboot, the usb bus will surely changes. I didn't see docker has such kinds of ability to renew the "-device". How would that happen? Sorry again, I haven't tired, just want to know the mechanism.
7. Anyway, currently what I care about is the roadmap of "docker test".
If your final direction is to make the "docker test" more common, then we are OK currently "STICK ON 2020.02". If just for android & "WaitDeviceBoardID" had to be here without any control by user, then we will give up this solution & try to find another way to reuse the device in LAVA?
Your direction matters our next step!
8. Finally,
Any other suggestion for our scenario which I described in item 2?
Regards,
Larry
Hi,
I have a question related to uboot boot action's retry settings, our job is:
- boot:
failure_retry: 2
namespace: test_suite_1
connection-namespace: burning-uboot_1
method: u-boot
commands: nfs
auto_login:
login_prompt: '(.*) login:'
username: root
prompts:
- 'root@(.*):~#'
timeout:
minutes: 10
1. From the code:
"UBootAction" extends from a RetryAction, while in its internal pipeline, there is action named "UBootRetry" which also extends from RetryAction.
If we define a "retry", when exception happened in "RetryAction", it will first cause "UbootRetry" to retry, then "UBootAction" to retry again.
Sounds confuse, I wonder for what reason we should had a nested retry here?
2. In fact the real issue here for us is next:
Let's suppose we define failure_retry: 2, our situation is:
1) First boot timeout for some random block issue.
2) Then, it start Retrying: 4.4 uboot-retry (599 sec), but timeout again.
3) Then, it start Retrying: 4 uboot-action (599 sec), but timeout again.
4) Then, it start Retrying: 4.4 uboot-retry (599 sec), this time a lucky boot here, but before we are happy, it finish the last action "export-device-env" in uboot-retry. Then, looks like "UBootAction" timeout resume, then the lucky boot becomes useless although it's in fact successfully boot.
The log is:
start: 4.4.5 expect-shell-connection (timeout 00:07:23) [test_suite_1]
Forcing a shell prompt, looking for ['root@(.*):~#']
root@imx8mnevk:~#
expect-shell-connection: Wait for prompt ['root@(.*):~#'] (timeout 00:10:00)
Waiting using forced prompt support. 299.9747439622879s timeout
end: 4.4.5 expect-shell-connection (duration 00:00:00) [test_suite_1]
start: 4.4.6 export-device-env (timeout 00:07:23) [test_suite_1]
end: 4.4.6 export-device-env (duration 00:00:00) [test_suite_1]
uboot-action timed out after 727 seconds
end: 4.4 uboot-retry (duration 00:02:07) [test_suite_1]
I'm not sure, but looks like: for second "uboot-action", there is two "uboot-retry" inside it because of "retry", which will make when "uboot-action" timeout resume, the time diff becomes less than 0, which directly raise exception? Is it a bug or I misunderstand it?
duration = round(action_max_end_time - time.time())
if duration <= 0:
signal.alarm(0)
parent.timeout._timed_out(None, None)
Any suggestion for this?
Hi,
I have some questions about the new adb/fastboot support in LAVA 2020.02 described
in the recent Tech Days LAVA presentation [1]. Main initial use cases are Android boot test,
before moving on to running Android tests. Android is AOSP 9/10.
[1] https://connect.linaro.org/resources/ltd20/ltd20-304/
Taking the boot test use case I was looking at Antonio's Example 1 from his presentation
for fastboot deploy, boot and test. I found doc for test in the 2020.02 release note but
nothing I could see for deploy or boot.
In the LXC approach a typical job definition would have had target and host namespaces,
with deploy and boot for the host space to create and boot the LXC container. Looking at
Example 1 deploy from the presentation it looks like that is a largely a target fragment as
it contains the image binary etc. A host deploy no longer being required as the Docker
container is now created outside lava.
Similarly the Example 1 boot looks like a target fragment and host boot fragment is not
required as LAVA simply needs to run the specified Docker container. Then finally in
Example 1 test the scope is the specified docker container so no namespace is required.
Is my interpretation of the Example 1 slides correct? I tried some fragments that were causing
fundamental errors that caused me to check here. Although as is often the case writing it out
helps you get it straighter in your mind.
If you have reasons to want to control fastboot for the flashing on the host is that possible?
For example if you had the host side process scripted.
Does the fastboot Docker OS need to be specified?
I'm running 2020.02 on the Worker via lava-docker, with Docker support within the Worker
container by sharing the host Docker socket to gain access to the Docker daemon.
Regards
Steve
Hi,
I'm trialling the fastboot support in Docker introduced in LAVA v2020.02 and getting a fundamental job
error about the deploy action of the job definition. I've checked against the examples from the recent
Linaro Tech Day LAVA presentation but I can't see the source of the error. Could someone familiar with
this new support please take a look at the job definition please? I'm thinking it must be something obvious.
Error snippet:
error_msg: None of the deployment strategies accepted your deployment parameters, reasons given: overlay:
"to" parameter is not "overlay" docker: 'docker' not in the device configuration deploy methods download: "to"
parameter is not "download" qemu-nfs:
Full error:
https://lava.genivi.org/scheduler/job/718
Job definition:
https://lava.genivi.org/scheduler/job/718/definition
One possible cause I can think of is that the LAVA Worker is running 2020.02, whilst the Server is running 2019.03+stretch.
My assumption is that the job definition parsing occurs in the dispatcher but maybe that is not correct? The Server will be
upgraded to match the Worker of course, but we took a two step approach whilst we first looked into Android support.
Thanks for any help,
Steve
Hi Team,
I have recently installed lava server (master) in my Debian machine.
My goal is to configure lava-server with *master- multiple workers*
*Lava-server : Master*
*[PFA] Debian configuration *:
root@LavaServer:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Now i am trying to setup multiple workers on other machine:
Q : *Can i configure/Install the worker on different Operating System other
than Debian ??*
If [No], please describe the process or share the useful Doc
thanks
Regarding
Nagendra S
Hi,
initially we have plan to connect 5 boards to my lava-master and
lava-dispatchers.
Please can some let me know servers configurations for this setup as
mentioned below?
a. Can you let me know the LAVA master server configuration ? (
Processor/DDR/memory etc... configurations details)
b. Can you let me know the Dispatcher server configuration ?
(Processor/DDR/memory etc...configuration details) . ( I guess
Dispatcher server configuration may be less than Master server
configuration)
c. PDU (I guess initial we have plan to connect 5 targets) . (If possible
please can you share me the Amazon link to orfer)
d. Serial port hub . (I guess initial we have plan to connect 5 targets)
. (If possible please can you share me the Amazon link to order)
Regards,
Koti
Hi, there,
If lava in some place possible to find who cancel a job? Or use lavacli or manual cancel a job?
Or for which detail reason, the job was canceled?
We are struggling to find why my job canceled sometimes, not sure someone not carefully do it or our external program by chance do it, especially when there are many people used the same master.
Regards,
Lary
Sometimes for some device, when lava enter "/lava-55904/bin/lava-test-runner /lava-55904/0"
It looks it will print:
-sh: /lava-55904/bin/lava-test-runnera-55904/0: No such file or directory
Looks some character miss.
We increases the test_character_delay, looks useful, but I'm interested about the details, so for next which you mentioned in the code:
What exactly "slow serial problems(iPXE)" mean, could you explain more about it or any reference materteral I can had a look?
Then I could know: yes, it's exactly the same problem I have.
>>> Extends pexpect.sendline so that it can support the delay argument which allows a delay
between sending each character to get around slow serial problems (iPXE).
pexpect sendline does exactly the same thing: calls send for the string then os.linesep.
Hi, there,
Frequently, I found when a job becomes incomplete there will immediately a health check job on that device happen automatically to check the status of the device.
But strange, some times I won't see that healthy check job.
So, my question is: when I see that healthy check job, is it just by chance? Or it really designed that there will be a healthy check after incomplete job? Thanks.
Regards,
Larry
Hello,
I hope that the mail subject set up an easy, cheerful background for
this discussion ;-). This definitely goes into the "stupid questions"
department. My plan was to collect "evidence"/feedback from my
colleagues, then at the Connect BUD20, crash into LAVA/QA rooms and ask
what I/we are doing wrong. As circumstances changed, but the "testing
debt" only builds up, there's little choice but to try figure out these
matters over a much narrower pipe.
So, before proceeding to the question per se, let me theorize that the
reasons why such questions come up at all, are sufficient differences in
the intended LAVA usage patterns. In other words, how I'd like to use
LAVA on the LITE team side may differ from how LAVA team intends it to
be used, or how QA team uses (the biggest user would it be). The
issue? How I'd intend to use it is IMHO one the most basic ways to use a
test system.
So, what's that usage? Well, I'm not much interested in "interactive"
use (submit jobs manually from my machine). Our interest is in
unattended automated CI, of which the testing system is the second half
after the build system. So let me remind how our build system, Jenkins,
works. Normally, it just builds binaries and uploads them to a
publishing server. It's invisible to me in this phase, and my
engineering work goes uninterrupted. But when a build fails, I get an
email with details about a failure. And I'll continue to get them while
it continues to fail. So, the only option I have is to go see the
failure, investigate, and fix it. When I arrive at Jenkins, I can easily
see which jobs failed and which not, then within each job, see which
builds failed and which succeeded. That's very easy, because failed
things are red, and successful things are green.
So, we've now arrived at the main question of this email - Why I don't
seem to be able to use LAVA in the same way? Why LAVA offers only
"Incomplete" and "Complete" job statuses? "Incomplete" is understood -
it's an infrastructure failure, such a job is definitely "failed". But
"Complete" doesn't give me any useful information whether the job
succeeded or failed. Because a "Complete" job may still have any number
of tests failed. And that's exactly the "last mile" LAVA misses to go:
for any test job, I want to see a cumulative number of test cases which
failed, straight at the page like
https://lite.validation.linaro.org/scheduler/alljobs . Then, I'd like
to filter out jobs which has this number >0. Then I'd like to receive a
notification only for "failed" jobs, "failed" defined as
"status != Complete OR failed_testcases > 0".
So, what am I missing and how to make LAVA work like the above?
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
After the recent Linaro Tech Day LAVA presentation I have been looking into the new
support in LAVA v2020.02 for deploying fastboot on the host to docker rather than lxc.
I am running my lava worker in a docker image derived from the linaro lava docker images
and so wanted to ask if the new feature supported docker in docker for the fastboot
containerisation?
Regards
Steve
Hello,
I just started working with hardware, firmware and lava. You have a big
documentation, but for me it's sometimes difficult to find something.
I wanted to submit a job on just one device like my "bbb-03" and not on
every beaglebone-black. Is there a device-tag to choose a device like
"device_type: "? My next question is if there is also a worker tag for a
job submit? For example I just want to run all "beaglebone-black" on my
"worker2".
Is there also a list of all job submissions tags with examples? I just
found the one for the "actions" part.
I'm sorry for disturbing and maybe the stupid question. But thank you for
your answer in advance.
I wish you a nice day
Hello,
As you know, we are trying to release a new version of LAVA every month.
We are delaying this month release (2020.03) due to some issues and crashes
that we found in the last days.
Issues where found on staging.vlo, lavafed and meta-lava, proving that the
CI is working.
Where are currently working on fixing the issues and proving that LAVA is
ready for release.
The next release should be ready for the end of next week and would be
called 2020.04.
Rgds
--
Rémi Duraffort
LAVA Architect
Linaro
Hello,
I recently went "on a spree" to submit a number of LAVA UI issues
either accumulated in my mind or just caught on exhaustive search for a
feature I miss. They are at
https://git.lavasoftware.org/lava/lava/-/issues?scope=all&author_username=p…
and I believe all of them worth fixing (and don't bring in concerns
like backward compatibility). So, they're up for triaging by the
maintainers and feedback from the community to confirm they're indeed
such. (Then, I'd be able to help with addressing them, as much as I
can).
There're more issues, about which I'm less sure. So, instead of
submitting such as bugs, let me ask for a feedback in the email,
starting with this one:
When you prepare a job definition YAML to submit to LAVA, in it you
something like:
job_name: 'zephyr-net-ping #823-2ac65a24'
It may be not immediately obvious, but what you had as a "job name" in
the YAML, ends up as a "description" when you visit job list in the
LAVA UI (E.g. at https://validation.linaro.org/scheduler/alljobs).
"Is it that much of a difference? Most people wouldn't even notice!"
you may think, and I can only second that. I for one never paid
attention to that for on-and-off, mostly very light usage of LAVA for
some 10 years (i.e. I started yet with the previous version which
might look different at all).
And indeed, it won't make any difference until may want to start
querying job results. And I would like to share a story of what that
difference costed me.
Here's a patch I submitted in June 2017:
https://git.linaro.org/ci/job/configs.git/commit/lite-aeolus/lava-job-defin…
with a commit message and inline comment of: "For some reason, LAVA
doesn't allow to query by real job name, so we need to duplicate it as
metadata."
Here's another patch which I submitted based on the analysis I
present here: https://review.linaro.org/c/ci/job/configs/+/34677
So, for almost 3 years I lived with a misconception that LAVA can't
query by a job name.
Call it an extreme case. Call me dumb. Say that there's autocompletion
for field names and any person with some agility of mind would type
different characters and would notice "description" as available field.
Yeah, I did all that. But I'm with me from 3 years ago: for me, "job
name" is "zephyr-net-ping #823-2ac65a24". "job description" would be
something like "Ping Zephyr dumb_http_server sample with packets of
different size and interval". To the best of my knowledge, there's no
such a field in jobdef YAML to include such a description, and I
definitely don't include it in my jobs, so never would I try to search
anything in "description", for the lack thereof in my jobs.
Unless I have too much time to apply random "genetic algorithms" to
LAVA UI or just do exhaustive search thru it. Which I usually don't
have time for (I'm not a test engineer, but a developer, with "test
that code" always in backlog). Until recently, when testing debt has
really become pressing, and I decided to face all "skeletons in closed"
I had with LAVA ;-).
So, even 3 years haven't passed until I "did my homework" on searching
jobs by name. But my point would be that there should be no need for any
"homework" regarding these matters, it all should just work right away
without double-thinking and guesswork.
And I would consider this a genuine bug. I'm less sure about fixing
though. Because it's not a matter of just changing a few UI labels.
It's more pervasive, as e.g. this URL shows:
https://lite.validation.linaro.org/results/query/+custom?entity=testjob&con…
And seeing that URL, one can actually conjecture how that "description"
appeared in the UI: it's actually name of the database table. Which
just bled into system public interface. Too bad, because another public
interface uses "job name" for that field, and internal naming like db
fields shouldn't prevail.
Anyway, I'm not going to argue that DB should be migrated, and it won't
help, as we definitely don't want to break existing queries, etc. So,
the only way to fix that would be to alias existing "description" to
clearer "name" (or "jobname", "job_name"), and perform mapping on DB
access. I'm note sure if it's worth. Based on my experience, I'd go
for it, and it doesn't sounds like rocker science. But only
maintainers could imagine how kludgy it would be in the actual LAVA
database and if it's worth it, taking into account other tasks and
priorities.
Thanks for reading the story (rant?).
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
I am facing the issue while porting Host's "adb-devices" to
lava-dispatcher docker.
Please can some one provide the right steps to detect "adb-devices" in
"lava-dispatcher" docker?
Current steps: (still my lava-dispatcher fail to detect the Host's
"adb-devices")
###########
1. Lauch the LAVA-lab using "docker-compose up" from the repo "
https://github.com/danrue/lava-docker-compose.git"
2. add "/dev/bus/usb" , "/etc/udev/rules.d" and "privileged: True" to
"lava-dispatcher" i.e
" dispatcher:
image: lavasoftware/lava-dispatcher:2019.12
container_name: lava_dispatcher
privileged: True
devices:
- /dev/kvm # needed for QEMU
- /dev/net/tun # needed for QEMU
- /dev/bus/usb
cap_add:
- NET_ADMIN # needed for QEMU
environment:
- "DISPATCHER_HOSTNAME=--hostname=dispatcher"
- "LOGGER_URL=tcp://server:5555" # url to send logs
- "MASTER_URL=tcp://server:5556" # url of lava master
volumes:
- '/boot:/boot:ro'
- '/lib/modules:/lib/modules:ro'
- '/dev/bus/usb:/dev/bus/usb'
- '/etc/udev/rules.d:/etc/udev/rules.d'"
3. Run the command #docker-compose up
4. Login to lava-dispatcher #docker exec -it <dispatcher-name" bash
#apt-get update;apt-get install android-tools-adb
android-tools-fastboot usbutils
#adb devices
Can some one let me know the steps to detect my host's "adb-devices" in
lava-dispatcher's docker?
Regards,
Koti
Hi,
I am able to boot and run the tests with Provisioned(booted) board using
attached YAML i.e "working_yaml.yaml".
But, I am facing the issue while running the tests on Provisioned (booted)
board with out "-boot" section. (you can see my YAML file as mentioned
below which I have used now)
Please can some one help me for the same?
1. Basically I am facing the connection issue with out "-boot" section.
2. Why this dependency to connect terminal for boot section ? ( I am
able to connect serial port when I use "-boot" section in yaml file)
3. Please can some one provide me right YAML to run my tests with out
"-boot" section. ( to resolve serial connection issue with out "-boot"
section)
"
device_type: beaglebone-black
job_name: begalbone healthcheck
timeouts:
job:
minutes: 30
action:
minutes: 15
connection:
minutes: 5
priority: medium
visibility: public
context:
test_character_delay: 10
actions:
#- boot:
# timeout:
# minutes: 15
# method: minimal
## reset: false
## auto_login:
## login_prompt: '.* login:'
## username: root
# prompts:
# - root@dragonboard-410c:~#
- test:
interactive:
- name: reset
prompts: ["#"]
script:
- name: reset
command: reset
"
Regards,
Koti
Interesting topic, one question:
What will the new LAVA rest api look? a) or b) ? I wish it could b), then we could ease our master's pressure...
a) Django-rest-framework alike, synchronous
b) Tornado alike, asynchronous
-----Original Message-----
From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of lava-users-request(a)lists.lavasoftware.org
Sent: Wednesday, March 11, 2020 8:00 PM
To: lava-users(a)lists.lavasoftware.org
Subject: [EXT] Lava-users Digest, Vol 19, Issue 2
Caution: EXT Email
Send Lava-users mailing list submissions to
lava-users(a)lists.lavasoftware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…
or, via email, send a message with subject or body 'help' to
lava-users-request(a)lists.lavasoftware.org
You can reach the person managing the list at
lava-users-owner(a)lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..."
Today's Topics:
1. LAVA RESTful API feedback and plans (Stevan Radakovi?)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Mar 2020 09:17:00 +0100
From: Stevan Radakovi? <stevan.radakovic(a)linaro.org>
To: "lava-users(a)lists.lavasoftware.org"
<lava-users(a)lists.lavasoftware.org>
Subject: [Lava-users] LAVA RESTful API feedback and plans
Message-ID: <34b9c19d-b0eb-2d85-0c85-a4e536a1812e(a)linaro.org>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello community,
With the LAVA release of 2020.02 we now have a REST API framework that we fell covers all the functionalities of the already existing XMLRPC API.
Since the long-term plan is to drop the XMLRPC support, we now encourage everyone to use REST and we also would like to hear feedback about any additional features that you'd like to see as part of the REST API.
Our plan is to slowly move lavacli
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.lava…> project to use REST API exclusively, after that we will schedule the deprecation of the XMLRPC API.
Cheers,
--
Stevan Radakovi? | LAVA Engineer
Linaro.org <https://eur01.safelinks.protection.outlook.com/?url=www.linaro.org&data…> ? Open source software for ARM SoCs
Hi,
Right now I am trying to run tests on Provisioned(booted) board with out
using physical Power switches .
But, I am seeing below soft reboot lines while using the attached YAML
file,
"
start: 1 minimal-boot (timeout 00:15:00) [common]
start: 1.1 connect-device (timeout 00:15:00) [common]
[common] connect-device Connecting to device using 'telnet ser2net 5001'
end: 1.1 connect-device (duration 00:00:01) [common]
start: 1.2 reset-device (timeout 00:14:59) [common]
start: 1.2.1 send-reboot-commands (timeout 00:14:59) [common]
No soft reboot command defined in the test job. Using defaults.
reboot
reboot
reboot -n
reboot -n
reboot -nf
reboot -nf
"
I want to change my soft reboot command as "reset" instead of
"reboot"/"reboot -n"/"reboot -nf".
Please can some one let me know as how can I change default soft reboot
command to "reset" ?
Regards,
Koti
Hi,
I have successfully booted the Beagelbone board from "
https://github.com/danrue/lava.therub.org" . (corresponding ymal is
https://github.com/danrue/lava.therub.org/blob/master/server-overlay/etc/la…
)
But, now I am trying to run one more scenario (may be new scenario and not
sure is it supported by LAVA lab?) i.e
1. Run the tests on already provisioned (boot) beagelbone board. (Basically
I am skipping the booting mentioned and trying to run on the already
provisioned/boot board)
a) boot the target
b) Connect Board to LAVA lab
c) Just check the login prompt ("#") is available or not?
c) Run the using below test definition file (Basically this test
definition file runs "ls"/"ifconfig" commands in the already
provisioned(boot) board).
"
device_type: beaglebone-black
job_name: beaglebone-black healthcheck
timeouts:
job:
minutes: 10
action:
minutes: 5
priority: high
visibility: public
actions:
- test:
interactive:
- name: ls test
prompts: ["#"]
echo: discard
script:
- name: ls
command: ls
successes:
- message: "ls simple test successes"
failures:
- message: "TIMEOUT"
exception: InfrastructureError
error: "ls command failed"
- name: ifconfig
command: ifconfig
- name: wait for the prompt
command:
"
I have tried to run this. But, my test failed with the error ""Connection
closed"" (Attached screenshot)
Can some one let me know solution to fix this error?
Regards,
koti
Hello community,
With the LAVA release of 2020.02 we now have a REST API framework that
we fell covers all the functionalities of the already existing XMLRPC API.
Since the long-term plan is to drop the XMLRPC support, we now encourage
everyone to use REST and we also would like to hear feedback about any
additional features that you'd like to see as part of the REST API.
Our plan is to slowly move lavacli
<https://docs.lavasoftware.org/lavacli/> project to use REST API
exclusively, after that we will schedule the deprecation of the XMLRPC API.
Cheers,
--
Stevan Radaković | LAVA Engineer
Linaro.org <www.linaro.org> │ Open source software for ARM SoCs
Hi, lava team!
First question:
I'm working with fastboot device, is it possible after test part put device again to fastboot mode, run some fastboot command ( not to flash ), boot again, run test.
job steps:
1. deploy lxc
2. boot lxc
3. test lxc
4. deploy fastboot ( put to fastboot )
5. boot fastboot device
6. run test
7. reboot and put device to fastboot mode
8. run fastboot commands
9. continue run test.
Can you give any advice how to do it?
Better to able reboot device inside test. I tried to reboot device from test part, lava just stuck and wait when reboot action will end. But looks like it does not recognize end.
Second question:
In job have lxc namespace and device namespace, how to run command_action from host os, not lxc?
Best regards,
Ilya Feduisv
Hi, Lava Team!
Want to use user_commands as written here : https://validation.linaro.org/static/docs/v2/actions-command.html
Device dictionary has : {% set user_commands = {'switch_mode' : {'do': './usr/local/scripts/switch_mode.sh'}} %}
Job https://pastebin.com/hhWbC207
I have lxc and custom script to set device flash-mode.
But have error
error_msg: 'common' is a reserved namespace that should not be present with other namespaces
To fix it I added namespace to command:
- command:
namespace: tlxc
name: switch_to_qdl
But error again in validate before submit
Invalid definition: extra keys not allowed @ data['actions'][3]['command']['namespace']
I have fastboot and custom flash methods. pre_power_command in deploy I use for fastboot. Need to use somehow custom script to switch to another mode, that's why I decided to use -command action.
Please help how to fix error with namespaces or suggest another solution.
Best regards,
Ilya Fedusiv
Hi,
I found the solution, we have to mount dispatcher.yaml file from
lava-server in lava-master container as well beacuse lava-master is the one
who communicate with DUT and run the job.
regards
admirer mishra