On Thu, 25 Jun 2020 at 10:48, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
Stephen,
I think what you want already works (sort of)
On Wed, 24 Jun 2020 at 19:53, Stephen Lawrence stephen.lawrence@renesas.com wrote:
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?
I tried on our staging instance and I hit a bug in schema validation but in general this definition should do what you want: https://hastebin.com/aqegomijez.cs There is however a bug in job validation that will not allow wait_for_prompt key in interactive test. I'll send the patch to fix it in a moment. This is an easy fix so I expect it to be merged soon and available in master branch next week.
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:
- 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
- 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.
- boot: prompts:
timeout: minutes: 15 method: u-boot
- "=>"
Sorry, I was a bit too quick. The proper boot section is:
- boot: prompts: - "=>" timeout: minutes: 15 method: bootloader bootloader: u-boot commands: []
milosz
- test: interactive:
- name: fastboot prompts: ['=> ', '/ # '] script:
- command: fastboot 1 name: fastboot-1 wait_for_prompt: false
This is the part of job definition you need. Let me fix the schema parsing bug and you'll be able to use it.
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?
I also tried this:
- boot: prompts:
timeout: minutes: 15 method: u-boot commands:
- "=>"
- fastboot 1
But it waits for prompt. Since fastboot doesn't exit and return a code lava hangs waiting. So IMHO the 'cleanest' way at this point is with interactive test starting fasboot and test section doing oem commands.
milosz
Regards
Steve
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users