- lava-users - op-lists.linaro.org

by Larry Shen

Hi, all, I want to do a job search with owner, E.g. in https://validation.linaro.org/scheduler/alljobs 's search box, I input next: owner_query=qa-reports-bot But, it return nothing to me, all jobs filtered out. I wonder what's the correct input in this search box for "Custom query text"? Regards, Larry

5 years, 2 months

2
2
0 0

Adding new device issue

by Koturappa, Hemanth

Hello Lava-Users, When we try to add new device we are facing the error 500 Internal Server Error maximum recursion depth exceeded in comparison Oops, something has gone wrong! Recently we had updated the LAVA instance server to Debian10. The LAVA server version presently running on the instance is lava_admin@svr-ies-ce-lava:~$ dpkg -l | grep lava ii lava 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture metapackage ii lava-common 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture common ii lava-coordinator 2020.07.0002.g44e83009c+10+buster all LAVA coordinator daemon ii lava-dev 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture developer support ii lava-dispatcher 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture dispatcher ii lava-dispatcher-host 2020.07.0002.g44e83009c+10+buster all LAVA dispatcher host tools ii lava-server 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture server ii lava-server-doc 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture documentation ii lavacli 0.9.5-1 all LAVA XML-RPC command line interface As specified in https://stackoverflow.com/questions/3323001/what-is-the-maximum-recursion-d… should we try to increase python recursion limit to overcome this? Thanks, Hemanth.

5 years, 2 months

2
6
0 0

lavapdu-client throwing error

by P T, Sarath

Hi，Team, I want to control device power on/off/reboot by lavapdu ,but when I run “/usr/bin/pduclient --daemon 134.86.60.229 --hostname 134.86.254.45 --command reboot --port 10” Error sending command, wrong daemon hostname? Can you help me solve this problem? Pdudaemon run on the lava-server. Below giving the configuration file for pduclient. { "daemon": { "hostname": "0.0.0.0", "port": 16421, "dbhost": "127.0.0.1", "dbuser": "pdudaemon", "dbpass": "pdudaemon", "dbname": "lavapdu", "retries": 5, "logging_level": "INFO" }, "pdus": { "192.168.10.2": { "driver": "apc9210" }, "192.168.10.3": { "driver": "apc7952", "telnetport": 5023 }, "192.168.10.4": { "driver": "apc7952" }, "192.168.10.5": { "driver": "apc8959", "this": "that", "something": "else" }, "192.168.25.52": { "driver": "apc7952" } } } Regards Sarath P T

5 years, 2 months

2
1
0 0

Error encounterd while using u-boot-ums deploy method

by DAS, BHARGAV

Hi Lava users, I am trying to use the u-boot-ums deploy method. I have taken reference from this job : https://staging.validation.linaro.org/scheduler/job/277518/definition While submitting the job I am getting the following error: Job error: 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" downloads: "to" parameter is not "downloads" qemu-nfs: "nfs" is not in the device configuration deploy methods images: "to" parameter is not "tmpfs" iso: "to" was not in parameters, or "to" was not "iso-installer" fastboot: "to" parameter is not "fastboot" flasher: 'flasher' not in the device configuration deploy methods fvp: 'to' was not fvp lxc: "to" parameter is not "lxc" nbd: "to" parameter is not "nbd" nfs: "to" parameter is not "nfs" removable: "media" was not "sata", "sd", or "usb" vemsd: "to" parameter is not "vemsd" mps: "mps" was not in the device configuration deploy methods musca: "musca" was not in the device configuration deploy methods ssh: "to" parameter is not "ssh" tftp: "to" parameter is not "tftp" uboot-ums: "u-boot-ums" was not in the device configuration deploy methods" recovery-mode: 'recovery' not in the device configuration deploy methods uuu: "to" parameter is not "uuu" Please check the attached yaml file (u-boot-ums-def.yaml). ? Regards, Bhargav

5 years, 2 months

3
5
0 0

is LAVA supports "Appium (http://appium.io/docs/en/about-appium/intro/) ?

by koti koti

Hi, Is LAVA Test Framework supports Appium? ( http://appium.io/docs/en/about-appium/intro/)? Like how the Robot Test framework supports Appium ? ( https://www.youtube.com/watch?v=_Z2QMrUA2cg) [image: image.png] Regards, Koti

5 years, 2 months

2
2
0 0

About --init in docker library.

by Larry Shen

Hi, I saw this change "docker: run containers with an init system": https://git.lavasoftware.org/lava/lava/-/commit/e0bfef019992f9032d87e9edf9f… This makes UUU container function which directly mount "/dev" won't work, see this: https://github.com/moby/moby/issues/37645 If possible this could be a optional one? You know, user don't need it if he just run one process in one container & set that process as PID1. Furthermore, even user start multiple process in one container, he still could use some like next to fix in its dockerfile. ENV TINI_VERSION v0.18.0 ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini RUN chmod +x /tini ENTRYPOINT ["/tini", "--"] CMD ["/root/entrypoint.sh"]

5 years, 2 months

1
2
0 0

Ask plan for docker test shell.

by Larry Shen

Hi, I saw something like "LAVA_HARD_RESET_COMMAND" was added to environment. Yes, the test action could use this command to reboot the device now, it's useful. But, after the command sent, the code in container still need to handle something like next: "Expect press any key to continue" "Press any key" "Expect login prompt" "Login" Etc...... But, this exactly the same code what lava have do in a lots of python files located in "lava_dispatcher/actions/boot". My question is: do you think it's possible for user code in "docker-test-shell" action directly send any command or use any protocol to tell lava code(maybe a listener or something else) to help to do these things, then after done, the user code in docker test shell continue to execute its own stuff? You know, this could reuse existed lava code as much as possible. I just want to know if you have plan for this? Thanks.

5 years, 2 months

2
2
0 0

fastboot in docker support

by Stephen Lawrence

Hi, I have some questions about the fastboot/adb in docker support I hope you can help with. Use case is for android 10 aosp testing with LAVA 2020.05. Thanks to Antonio's presentation and draft documentation I have simple fastboot host to DUT communication working for a u-boot based arm64 board. I am now trying to apply an existing flash process, which uses a script on the host to send fastboot cmds, into a LAVA job. I can see how fastboot --set-active, reboot and flash commands all have equivalent controls in a 'deploy to fastboot docker' LAVA job section. Do equivalents exist for the fastboot oem format, oem erase, format and erase commands or is there a way to insert them in the deploy? Expecting that will take some engineering work, in parallel I wanted as a stop gap to try running the flash script from a LAVA job. So people could work on the testing side whilst I resolved the deploy section. Antonio suggested trying to do that from the test section I recall. To do that I face two issues: 1) The build artifacts are on a local volume rather than an artifact server so I need to get them into the docker container in an automated way. Is there a way to either mount a local volume or file list into the container without asking LAVA to deploy them? As an experiment I tried using the docker image manipulation added in 2020.04 to do this. There I hit a problem with the current implementation. It seems the 'deploy to downloads' implementation does not check for a local image first, as the other docker support does, before trying to pull the image. So I get an error when the pull fails: https://lava.genivi.org/scheduler/job/961#L24 2) The job needs to be able to boot the DUT, interrupt u-boot and start fastboot so the host has something to communicate with once the test section is reached. I can achieve that in a horrible hacky way by having a deploy section with a simple single flash image (dtbo say) and using the reboot controls to get the board to reboot into fastboot to await the flash script being run from the test section, but I expect there is a better way. Any ideas? Regards Steve

5 years, 2 months

4
38
0 0

tee support breaking job with Bug error: 'tee'

by Stephen Lawrence

Hi, Taking the current master branch head (0f6e89e3) I find my health checks that use u-boot tftboot support are now failing with the following: start: 2.2 bootloader-overlay (timeout 00:05:00) [common] Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lava_dispatcher/action.py", line 245, in run_actions new_connection = action.run(connection, action_max_end_time) File "/usr/lib/python3/dist-packages/lava_dispatcher/actions/boot/__init__.py", line 454, in run tee_addr = self.job.device["parameters"][self.bootcommand]["tee"] KeyError: 'tee' Example job: https://lava.genivi.org/scheduler/job/1160 I've not combed through the code in detail but it looks like it is related to the recent tee merge: https://git.lavasoftware.org/lava/lava/-/commit/f18ca091e61da31159cd72a0030… That appeared to introduce an optional feature which my jobs do not make use. Am I missing something? Regards Steve

5 years, 3 months

2
2
0 0

settings.conf not available in /etc/lava-server

by Koturappa, Hemanth

Hello Lava-Users, When we trying to setup new instance of LAVA server(2020.07) facing the issue of settings.conf file not available after installation at /etc/lava-server/ . Following the steps mentioned as in https://docs.lavasoftware.org/lava/installing_on_debian.html .Request on guidance If I am missing something. Package Installation Log : https://pastebin.com/B7K0gXBp hemanth@hemanth:~$ dpkg -l | grep lava ii lava-common 2020.07+10+buster all Linaro Automated Validation Architecture common ii lava-coordinator 2020.07+10+buster all LAVA coordinator daemon ii lava-dispatcher 2020.07+10+buster all Linaro Automated Validation Architecture dispatcher ii lava-dispatcher-host 2020.07+10+buster all LAVA dispatcher host tools ii lava-server 2020.07+10+buster all Linaro Automated Validation Architecture server ii lava-server-doc 2020.07+10+buster all Linaro Automated Validation Architecture documentation hemanth@hemanth:~$ ls -la /etc/lava-server/ total 44 drwxr-xr-x 5 root root 4096 Jul 22 10:30 . drwxr-xr-x 148 root root 12288 Jul 22 10:30 .. drwxr-xr-x 5 lavaserver lavaserver 4096 Jul 22 10:30 dispatcher-config drwxr-xr-x 2 lavaserver lavaserver 4096 Jul 9 21:03 dispatcher.d -rw-r--r-- 1 root root 900 Jul 9 20:28 env.yaml -rw-r--r-- 1 root root 589 Jul 9 20:28 lava-logs -rw-r--r-- 1 root root 719 Jul 9 20:28 lava-master -rw-r--r-- 1 root root 496 Jul 9 20:28 lava-server-gunicorn drwxr-xr-x 2 root root 4096 Jul 22 10:30 settings.d Installing on Debian 10 Buster Host hemanth@hemanth:~/mentor-lava-sources/mentor-lava$ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL=https://bugs.debian.org/ Thanks, Hemanth.

5 years, 3 months

3
5
0 0

LTP and some other tests in QEMU

by 黄璐

5 years, 3 months

1
0
0 0

Run shell commands in a docker job

by baptiste.billard＠e.email

Dear lava-users, I'm intern at /e/ foundation and working on using LAVA to test our OS updates. We are trying to configure our system in order to use the recent feature allowing the use of docker instead of LXC containers. On this point we are grateful to the developpers for adding this possibility because we were having problems with LXC. Now we are having issues because we can't flash our OS through fastboot, we have to use adb sideload with .zip archives. By the way, we can't do it through the classic deploy section. We came with the idea of just flashing a twrp recovery partition via the deploy section using fastboot, and then trying to run shell commands in the test section to be able to use adb sideload and install our ROM. For the moment as you can see in the job we didn't add all the shell commands because we already have some problems with this simple try. The objective would be to pass this booting into recovery step and then try to continue with adb sideload. I've also joined the logs and the device and device type dictionaries. I would like to have your opinion and advices on what we are trying to achieve. Best regards, Baptiste and the /e/ team

5 years, 3 months

1
0
0 0

Execute u-boot pytest with LAVA

by Philippe BEGNIC

Hello everyone, I would like to integrate the u-boot tests suite (pytest) in lava. ( https://github.com/u-boot/u-boot/tree/master/test/py) We are now executing the test suite manually, using a host machine and the DUT. The u-boot tests suite is installed on a host computer and the DUT is "stopped" in uboot environment. The host computer execute the "u-boot pytest" framework, commands are sent to the DUT and tests results are collected to the host computer. It is a "semi automatic" tests and I would like to do a full automation using LAVA. I plan to use multinode jobs, one job instances for the DUT and another one for the remote host computer. So, I would like to know if such tests have already been craeted in LAVA, and if someone could give me advice on this tests implementation. My Lava version is: 2020.06 Best regards Philippe Begnic STMicroelectronics

5 years, 3 months

2
2
0 0

lxc errors after updating from 2019.12 to 2020.01

by Alexander Moore

Hello, We are wanting to update to a more recent LAVA docker release, we've been at 2019.12 since it was released. Our configuration relies on lxc, and after moving to 2020.01 all of our test jobs hit the error "lxc container 'lxc-test-17071' already exists" very early on (17071 is the test job number). I've pasted our device configuration, test job, and log output in the below pastebin. What should we do to keep our LAVA jobs working with the 2020.01 release and beyond? https://pastebin.com/UQixc6RS Thanks, Alex This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 3 months

3
7
0 0

Tee support for armv7?

by Larry Shen

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?

5 years, 4 months

1
1
0 0

Re: [Lava-users] [EXT] Re: docker shell cannot handle adbd.

by Larry Shen

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…

5 years, 4 months

3
8
0 0

minimal boot and mutiple deploy

by Koturappa, Hemanth

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.

5 years, 4 months

1
0
0 0

Docker in Docker support, again

by Paul Sokolovsky

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/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

5 years, 4 months

2
3
0 0

Upgrading LAVA while preserving database

by Vincent Wan

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

5 years, 4 months

2
3
0 0

docker shell cannot handle adbd.

by Larry Shen

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.

5 years, 5 months

3
5
0 0

Unable to run commands on U-boot on Renesas board Using LAVA

by Nagendra Singamsetti

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

5 years, 5 months

3
3
0 0

Request : Code Flow

by Nagendra Singamsetti

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

5 years, 5 months

2
1
0 0

Unable to execute login command while booting with LAVA

by Nagendra Singamsetti

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

5 years, 5 months

2
2
0 0

UART connection issue with LAVA

by Nagendra Singamsetti

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

5 years, 5 months

2
2
0 0

Fwd: [EXT] Test jobs to boot the targets through trace32

by Nagendra Singamsetti

---------- 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 >> >>

5 years, 5 months

1
0
0 0

About pdu script.

by Peter Lucas

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?

5 years, 6 months

2
3
0 0

Test jobs to boot the targets through trace32

by Nagendra Singamsetti

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

5 years, 6 months

4
10
0 0

Question about serial.

by Peter Lucas

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*

5 years, 6 months

2
6
0 0

Docker device basic setup

by Saheer Babu

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.

5 years, 6 months

2
2
0 0

(no subject)

by Peter Lucas

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?

5 years, 6 months

1
0
0 0

Need help for 2020.05 release.

by Larry Shen

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

5 years, 6 months

1
2
0 0

docker-compose: how to administrate a LAVA master from this?

by Philippe Mazet (OSS)

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

5 years, 6 months

3
3
0 0

test

by Remi Duraffort

Hello, please skip this message. -- Rémi Duraffort LAVA Architect Linaro

5 years, 6 months

1
0
0 0

LTP included rootfs.cpio file for Qualcomm Snapdragon (arm64) series

by koti koti

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

5 years, 6 months

3
4
0 0

Re: [Lava-users] Evaluating return value of user_commands

by Tim Jaacks

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

5 years, 6 months

2
1
0 0

Evaluating return value of user_commands

by Tim Jaacks

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

5 years, 6 months

1
0
0 0

Unable to register IRC channel for #linaro-lava

by Nagendra Singamsetti

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

5 years, 6 months

2
2
0 0

/etc/qemu-ifup: no bridge for guest interface found

by Nagendra Singamsetti

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

5 years, 6 months

2
4
0 0

Support for lauterbach-trace32 debugger

by Nagendra Singamsetti

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

5 years, 6 months

2
3
0 0

Default lava-slave went offline

by Nagendra Singamsetti

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

5 years, 6 months

1
0
0 0

Question about Docker feature for Android testing.

by Larry Shen

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

5 years, 6 months

2
6
0 0

Question about uboot action retry and timeout?

by Larry Shen

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?

5 years, 6 months

2
4
0 0

v2020.02: job definition for fastboot on the host via docker

by Stephen Lawrence

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

5 years, 7 months

2
1
0 0

job error with new fastboot in docker support

by Stephen Lawrence

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

5 years, 7 months

2
4
0 0

Lava Server setup Issue

by Nagendra Singamsetti

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

5 years, 7 months

3
3
0 0

Lava-Lab "Master" and "Dispatcher" servers configuration details

by koti koti

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

5 years, 7 months

2
3
0 0

Audit log for user action?

by Larry Shen

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

5 years, 7 months

2
5
0 0

Question about send delay for serial.

by Larry Shen

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.

5 years, 7 months

2
2
0 0

About health check behavior?

by Larry Shen

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

5 years, 7 months

2
4
0 0

"Where're my failed tests, dudes?"

by Paul Sokolovsky

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/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

5 years, 7 months

4
15
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users