Hey Michael,
yeah, documentation is not good in this detail - also took me some time to figure it out.
Additional to what Milosz said: If worker and ser2net run on the same host, I would restrict the ser2net device to localhost for security reasons.
this is my ser2net.yaml: %YAML 1.1
define: &banner \r\nser2net port \p device \d [\B] (Debian GNU/Linux)\r\n\r\n
connection: &MyDevice accepter: tcp,127.0.0.1,7001 enable: on options: banner: *banner kickolduser: true telnet-brk-on-sync: true connector: serialdev, /dev/ttyMyDevice, 115200n81,local
Best regards, Stefan
On 2/7/2024 10:18 AM, Milosz Wasilewski wrote:
On Wed, Feb 7, 2024 at 2:10 AM Michael Peddie michael.peddie@gallagher.com wrote:
Hi, I have started trying to connect my DUT and run tests via serial. I'm not sure if it's a me issue, or a documentation issue, but I can't seem to puzzle it together. My DUT is connected to my worker via serial, and I've configured my ser2net.yaml file (docs say it's a .config, but I found no such thing) with both the provided example and something based on what was already in there. The problems arise in the job definition, and device dictionary. I've made a (pretty much) blank device template which extends base-uboot, and does nothing else. The device dictionary defines power_off_command, power_on_command, soft_reboot, and the connection_(list, commands, and tags). There is also the baud rate and console device However, I've also seen some device templates use a root device instead or alongside console device, what's the difference? Whenever I use my worker IP for the telnet command, I get connection refused, but if I use the DUT IP the connection times out after 2 minutes. I can connect to the device using minicom, so I don't think the serial connection is bad, and I have no problems using SSH on the device and other systems connected to my network.
The only information I have on the device is that it's ARMv5TEJ, it has a custom kernel and runs on otherwise custom hardware.
Below is my device dict:
{% extends 'test-template.jinja2' %} {% set power_off_command = 'python /power.py off' %} {% set soft_reboot_command = 'reboot' %} {% set power_on_command = 'python /power.py on' %} {% set connection_list = ['uart0'] %} {% set connection_commands = {'uart0': 'telnet dispatcher01 7001'} %} {% set connection_tags = {'uart0': ['primary', 'telnet']} %} {% set console_device = 'ttyUSB0' %} {% set baud_rate = 115200 %}
you're missing hard_reset_command. It's used in a few actions in LAVA. hard_reset is basically power_off + power_on with some delay in the middle.
My questions are:
- Difference between root_device and console_device in device dictionary/template?
I don't think any of these are used in your case
- Do I set the telnet command to use my worker IP or my DUT IP?
your device dict looks OK. You should definitely use your worker's IP/name.
- Is there something other than telnet I'm meant to or can use?
- How am I actually meant to configure the ser2net.yaml?
My example /etc/ser2net.yaml below. ser2net should be running on the worker/host that has physical connection to your DUT. In this example you should change connection name (1st line), path to the serial device (/dev/serial...) and banner. The rest can stay the same.
connection: &imx8mm-01 accepter: telnet(rfc2217),tcp,7001 connector: serialdev, /dev/serial/by-id/usb-FTDI_Dual_RS232-if01-port0, 115200n81,local options: banner: \r\niMX8MM 01\r\n\r\n max-connections: 3
Once you have ser2net running you should be able to connect to it (without LAVA) using telnet as in the connection_commands. Taken from your device dict: telnet dispatcher01 7001 If this doesn't work, LAVA won't be able to connect to the device either. You can replace dispatcher01 with IP address of the worker. It can be 'localhost' if ser2net and lava worker run on the same host.
- How do I define the test job for serial to execute commands on the DUT?
There isn't anything special in the job definition. LAVA will use the 1st item from connection_list. The best way of thinking about LAVA is that it simply runs a set of commands over serial (sends characters on the console) and reads the results back. After that it parses the results line by line looking for patterns defined either in your test script or in the LAVA code (there are a few assumptions about running linux, etc).
Hope this helps.
Best Regards, Milosz
Regards, Michael _______________________________________________ lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
lava-users mailing list -- lava-users@lists.lavasoftware.org To unsubscribe send an email to lava-users-leave@lists.lavasoftware.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s