Hi Antonio,
We are really close to having this working now. We just seem to have a problem with udev on board restart. Details below.
-----Original Message----- From: Antonio Terceiro antonio.terceiro@linaro.org Sent: 15 July 2020 14:46 To: Stephen Lawrence stephen.lawrence@renesas.com Cc: lava-users@lists.lavasoftware.org; gandersson@genivi.org Subject: Re: [Lava-users] fastboot in docker support
[snip]
Yes, they work a bit differently.
For flashing lava itself just waits for the device to be available via udev, and since you have /run/udev mounted (and I assume also /dev) in the container it works because the device node is passed excplitily in the docker run call.
For the docker test action, first the docker container running your tests is spawned. we can't just pass the device node in the docker run call, because your tests can e.g. reboot the device, and we need it to become available again after rebooting, getting a new device number etc.
Therefor, for this case the device is shared dynamically with the container by lava-dispatcher-host, which is triggered from the udev daemon. Thus you need lava-dispatcher-host and its udev rules in the host operating system.
This job closely represents our use case: https://lava.genivi.org/scheduler/job/1149
The new udev code finds the device and shares it into the test docker: https://lava.genivi.org/scheduler/job/1149#L529
The test docker can successfully list the fastboot devices so we know the test docker can communicate with the DUT so the new mechanism is working up to this point: https://lava.genivi.org/scheduler/job/1149#L584
However when the flash script executes 'fastboot reboot-bootloader' the host sits there waiting for comms to be restored and ultimately times out: https://lava.genivi.org/scheduler/job/1149#L626
It looks as if the test docker is not seeing the device when it reappears.
I simplified the test case to a simple boot and 'test with docker' job that is just sending some fastboot commands to check comms. It reboots into the bootloader and then sends a set-active command so it will wait if the device is not available: https://lava.genivi.org/scheduler/job/1154/definition
Submitting the job the fastboot device is successfully found and passed into the test docker as dev /001/074/: https://lava.genivi.org/scheduler/job/1154#L190
We have DUT comms and can reboot the board: https://lava.genivi.org/scheduler/job/1154#L232
However when we then do the fastboot set-active it waits: https://lava.genivi.org/scheduler/job/1154#L238
On the worker I can see that lsusb reports a Google device at /001/075. So the DUT appears to have successfully rebooted into fastboot. All be it with a different device number. If I connect to the device I can break into u-boot.
So it appears LAVA has not re-hooked the device on reboot. In your description you mention dev numbers changing so I assume that is in the design.
Do you have any suggestions as to what might be wrong or how I could debug this further?
Worker is running LAVA at the point of your 1268 PR on Debian stretch. lava-dispatcher-host is installed.
Best Wishes,
Steve