Skip to content

Navigation Menu

Sign in
Sign up

Questions on Dealing with Multiple Places #1489

Unanswered
Rubusch asked this question in Q&A
Discussion options

Hi, this is probably rather a "discussion" than an "issue"...

Currently I'll have around 8 places. A place consists of a DUT and a RPi with the labgrid-exporter(s) as systemd service, [labgrid v24.1]. Originally I liked to put my 8 RemotePlaces into one target "lab" in the exporter config. Then I used 8 different client environments. Doing it as in the configs down below, I could merge the client environments into one. But now I end up with 8 targets, providing the same name as RemotePlace. I know similar things were described in the documentation, but I could not figure out, neither found examples (this might be the small issue: please provide some .yaml examples with multiple RemotePlaces).

Questions:

  1. What is the difference between a "target" and a "resources/RemotePlace" from a setup point of view?
  2. Isn't there a way to declare a single target "lab" and in the client environment do a list of several "RemotePlace" names? Can you provide a snippet for this case?
  3. Most configs are the same, but some will have the usbsdmux attached, so as below UNIT01. So, how to merge redundant parts of the labgrid-client config, and setting up individually additional features?
  4. I need several NetworkService e.g. on UNIT03 I need a NetworkService on 1.2.3.49 (RPi) and another one 1.2.3.50 (DUT) - how to configure this case for the labgrid-exporter and for the labgrid-client?
  5. Also open for further issue in my configs.. I'd like to implement power control rather as driver, but this will be another issue. Somehow this approach fits me currently.

Labgrid-client Environment (reduced..)

targets:
 UNIT01:
 resources:
 RemotePlace:
 name: 'UNIT01'
 drivers:
 ExternalPowerDriver:
 cmd_on: 'ssh pi@${LG_PLACE} sudo /usr/bin/gpio26.sh start'
 cmd_off: 'ssh pi@${LG_PLACE} sudo /usr/bin/gpio26.sh stop'
 cmd_cycle: 'ssh pi@${LG_PLACE} "sudo /usr/bin/gpio26.sh stop && sleep 1 && sudo /usr/bin/gpio26.sh start"'
 SerialDriver: {}
 SSHDriver:
 keyfile: '~/.ssh/id_ed25519__foo'
 USBSDMuxDriver: {}
 UNIT03:
 resources:
 RemotePlace:
 name: 'UNIT03'
 drivers:
 ExternalPowerDriver:
 cmd_on: 'ssh pi@${LG_PLACE} sudo /usr/bin/gpio26.sh start'
 cmd_off: 'ssh pi@${LG_PLACE} sudo /usr/bin/gpio26.sh stop'
 cmd_cycle: 'ssh pi@${LG_PLACE} "sudo /usr/bin/gpio26.sh stop && sleep 1 && sudo /usr/bin/gpio26.sh start"'
 SerialDriver: {}
 SSHDriver:
 keyfile: '~/.ssh/id_ed25519__foo'
tools:
 usbsdmux: '${BASE}/../../venv/bin/usbsdmux'
options:
 crossbar_url: 'ws://foo:20408/ws'

Labgrid-exporter UNIT01

UNIT01:
 location: UNIT01
 USBSerialPort:
 match:
 ID_PATH: platform-3f980000.usb-usb-0:1.1.3:1.1
 speed: 115200
 NetworkInterface:
 ifname: eth0
 NetworkService:
 address: '1.2.3.17'
 username: 'pi'
 USBSDMuxDevice:
 match:
 ID_SERIAL_SHORT: '000000001197'

Labgrid-exporter UNIT03

UNIT03:
 location: UNIT03
 USBSerialPort:
 match:
 ID_PATH: platform-fd500000.pcie-pci-.&checktime(0000,01,00,':').0-usb-0:1.2:1.1
 speed: 115200
 NetworkInterface:
 ifname: eth0
 NetworkService:
 address: '1.2.3.49'
 username: 'pi'
You must be logged in to vote

Replies: 4 comments 2 replies

Comment options

  1. A target is a combination of resource and driver information while a RemotePlace only encodes resource information.
  2. What do you mean with "single target lab"? The intention is very much to have a environment yaml configuration per target if each target runs it's own testsuite.
  3. See WIP: yaml include #799 for discussions on YAML includes. If you do have the same board multiple times I'd suggest templating outside of labgrid.
  4. Configure multiple NetworkServices with add-named-match and bind to them inside the YAML. Not that within labgrid we explicitly care about interactions with the target and not running arbitrary commands on the exporter. For that a library like paramiko may be better suited.
  5. The Raspberry Pis could export the GPIOs as SysFSGPIO and than the GPIODigitalOutputDriver can use the GPIO and the DigitalOutputPowerDriver can use it for power switching.
You must be logged in to vote
0 replies
Comment options

Thank you for answering!

  1. Ok

  2. Ok, I totally misunderstood the definition of "target"

  3. Ok

  4. Hum, I don't really understand your answer. In my case I have several places. A place setup consists of a RPi and a DUT. On the RPi runs the labgrid-exporter. I tried adding somehow add-named-match in the exporter yaml without success (isn't that actually rule matching?).

I really appreciate having possibilities to do lc ssh in labgrid. I'd like further to have something like lc ssh @dut or lc ssh @rpi. If this does not work, of course I may use external libraries, or stick to the shell as well and ssh to the DUT directly.

So, questions are: do I understand correctly, labgrid is not doing this exactly, then I'd need some external lib, right? And, may I still ask you to provide me some yaml snippet how this add-named-match looks like?

  1. The gpio story... well, the scripts I'm using I was using before labgrid and it was easier to kick them from out of labgrid the same way. I tried with sysfsgpio but unfortunately it never worked for me.

I tried as follows on the labgrid-exporter, using gpio5 - would be gpiochip0 5

$ cat /etc/labgrid/exporter.yaml
lab:
 location: UNIT08
 USBSerialPort:
 match:
 ID_PATH: platform-3f980000.usb-usb-0:1.1.3:1.1
 speed: 115200
 NetworkInterface: # ethernet
 ifname: eth0
 NetworkService:
 address: '1.2.3.129'
 username: 'pi'
 SysfsGPIO:
 index: 5

then starting the exporter, logs show this

...
2024年08月29日T23:55:37 marked as broken: start failed
1970年01月01日T01:00:00 
{'cls': 'NetworkSysfsGPIO', 'params': OrderedDict(), 'acquired': '<broken>', 'avail': False}
2024年08月29日T23:55:37 ExporterSession.onUserError(): "OSError: [Errno 22] Invalid argument"
Traceback (most recent call last):
 File "/opt/labgrid-venv/lib/python3.11/site-packages/txaio/aio.py", line 487, in done
 res = f.result()
 ^^^^^^^^^^
 File "/opt/labgrid-venv/lib/python3.11/site-packages/labgrid/remote/exporter.py", line 797, in acquire
 resource.acquire(place_name)
 File "/opt/labgrid-venv/lib/python3.11/site-packages/labgrid/remote/exporter.py", line 170, in acquire
 self.poll()
 File "/opt/labgrid-venv/lib/python3.11/site-packages/labgrid/remote/exporter.py", line 139, in poll
 self.start()
 File "/opt/labgrid-venv/lib/python3.11/site-packages/labgrid/remote/exporter.py", line 113, in start
 self._start(start_params)
 File "/opt/labgrid-venv/lib/python3.11/site-packages/labgrid/remote/exporter.py", line 615, in _start
 with open(export_sysfs_path, mode='wb') as export:
OSError: [Errno 22] Invalid argument
...

My labgrid-client cannot see any provided GPIOs. Also, in the end I would need to use 4 different gpios. My scripts above worked quite well and are reachable from shell as well. Anyway, I'd rather love to see gpio power switching directly from off labgrid, though. Could you help me? What am I doing wrong in my exporter config?
You must be logged in to vote
2 replies
Comment options

The libgpio gpiochipN and line number mapping to SysFSGpio's index number is not straight forward. Take a look at /sys/class/gpio and you will find something like gpiochip512. The 512 is the index number for pin 1 on a Raspi4. So if you want pin 5, use index 516 (512 + 5 - 1)

SysfsGPIO:
 index: 516

then in your env.yaml file,

 drivers:
 - GpioDigitalOutputDriver:
 - DigitalOutputPowerDriver:

Then in your strategy, bind "power" to PowerProtocol"

If you need active low, you will have to keep using your scripts. If you want active_low integrated into labgrid, please help support getting PR #1609 merged.
Comment options

Thank you so much, for the example! Sorry I saw this answer far too late.

At the time, I did a GPIO script (ab)using systemd as server, such that I could systemctl start GPIOxy and systemctl stop GPIOxy`. Nowadays, I guess GPIOs might be better driven by DBUS directly by the libgpio. The script served me still using the exact same command for development on the hardware in a rather hacky setup. I'd not recommend this approach for general usage.
Comment options

I am also interested in understanding how I can write strategies/pytests which use multiple places. My use case is setting up a mesh network across multiple DUTs. But I also need the ability to use just one DUT to do individual device tests. Therefore each DUT has it's own RemotePlace.

Can you give an example on how to set up the env.yaml to control multiple DUTs, a strategy to set the state of multiple DUTs and lastly pytest examples which work with multiple DUTs?
You must be logged in to vote
0 replies
Comment options

Exactly, this seems like the logical next step for many test setups. Were anyone ever able to do this?
You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet
Converted from issue

This discussion was converted from issue #1488 on August 29, 2024 06:10.

AltStyle によって変換されたページ (->オリジナル) /