search

ARMmbed / mbed-tools

⚠️ Beta Status: New command line tooling for Mbed OS
Apache License 2.0
45 stars 30 forks source link

mbed-tool detect doesn't detect mbed devices inside docker #308

Closed saheerb closed 3 years ago

saheerb commented 3 years ago

Describe the bug docker environment will become the common method to execute tests against mbed devices, especially when H/W testing is moved to LAVA in CI. A linux host machine will run docker, and mbed devices will be passed through to docker as explained here

Though the detection of devices work in mbed-cli-v1 (mbedls), mbed-tools detect doesn't list any device.

To Reproduce Steps to reproduce the behavior:

  1. In Linux host machine (USB pass through will work only in Linux host): install docker if not already present. Connect an mbed device, for example, K64F.

  2. In Linux host machine, run docker container: docker run -it --privileged -v /dev/disk/by-id:/dev/disk/by-id -v /dev/serial/by-id:/dev/serial/by-id ghcr.io/armmbed/mbed-os-env:master-latest

  3. mount usb device and execute mbed-ls mount /dev/sdb /mnt

# mbedls
| platform_name | platform_name_unique | mount_point | serial_port  | target_id                                        | interface_version |
|---------------|----------------------|-------------|--------------|--------------------------------------------------|-------------------|
| K64F          | K64F[0]              | /mnt        | /dev/ttyACM0 | 0240000048824e450041700fdedd003598d1000097969900 | 0253
  1. run mbed-tools detecte
# mbed-tools detect  
No connected Mbed devices found.

Expected behavior mbed-tools detect the mbed device.

Desktop (please complete the following information): Any linux host that can run docker

Mbed (please complete the following information):

# mbed-tools --version
7.31.0

Additional context Add any other context about the problem here.

LDong-Arm commented 3 years ago

@ARMmbed/mbed-os-core A difference between container and host is the USB mount (from which we extract device info) is mounted to a user specified destination? Could it be that mbed-tools's detection algorithm makes certain assumptions on path to mount point? (Just my suspicion - I'm not familiar with this part of mbed-tools).

rwalton-arm commented 3 years ago

The problem seems to be that udevd isn't running inside the container, and mbedtools tries to query properties udevd generates after being sent a connection event by the kernel. Specifically the ID_BUS property is not available in this container setup, which mbedtools uses.

mbedls greps disk/by-id directly to discover disk IDs, then tries to find a corresponding USB block device in sysfs. This is re-implementing part of what udevd would usually do. The mbedls approach is more robust in this particular instance because we pass the disk/by-id paths to the container. However those disk/by-id paths are actually created by udev, so any "non-container" host would be running udevd if those paths exist. So, I don't think re-implementing the mbedls approach in mbedtools is worth the added code complexity, when udev is generally always available in Linux distros.

A workaround here would be to mount /run/udev in the container, then we shouldn't need to run the udev daemon inside the container itself. When I tested thismbedtools detect worked as expected.

LDong-Arm commented 3 years ago

@saheerb Did the suggestion above fix the problem? Can we close this issue?

saheerb commented 3 years ago

Yes, mbed-tools detect works if /run/udev is mounted on to the docker image. Ran ctests too inside docker image. All good.

Step to run (for reference):