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 %}
My questions are: - Difference between root_device and console_device in device dictionary/template? - Do I set the telnet command to use my worker IP or my DUT IP? - Is there something other than telnet I'm meant to or can use? - How am I actually meant to configure the ser2net.yaml? - How do I define the test job for serial to execute commands on the DUT?
Regards, Michael
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
Hi Milosz,
This helped greatly, thank you! Turns out my main issue was that I had tab spacings in my definition, and I didn't find out until checking the status of ser2net with systemd.
But another problem has come up, regarding actually running tests (I was just doing the boot action until now). I need both the deploy and test action to run tests, which leads to the following section: For my question about the test definition, I forgot to mention in the original, but the file system is read-only, and I don't want to have any overlays from deploy (a requirement I'm pretty sure), from my research into deploy (looking at the deploy action reference https://validation.linaro.org/static/docs/v2/actions-deploy.html), and I can't seem to find anything to work.
Is there anything I'm perhaps missing? Or will I need to try get a custom deploy method?
Best regards, Michael
Hi again,
Just a quick follow-up to this. I did some re-reading (paying a little more attention to make sure I didn't miss anything), and still don't think there is a to: for the deploy action that I can use for my purposes. As stated previously, the file system is read-only, so is there a deploy that goes to the dispatcher and runs the commands over serial from there? From your explanation about the test job, that seems possible, but I'm not sure because (at least to me) the documentation on the deploy action is unclear.
Best regards, Michael
Michael,
I'm not sure I understand your problem here. Deploy action is meant to deliver software to your hardware. Do you mean that the software doesn't change on your board?
If you change the software, but there is no way to write anything (ro filesystem) you have 2 options: - interactive test: https://validation.linaro.org/static/docs/v2/actions-test.html#index-1 IIRC it doesn't create any overlay on the DUT
- monitor test: https://validation.linaro.org/static/docs/v2/actions-test.html#index-2 This one only listens to what the DUT produces on the console and tries to match the pattern (that you can define) to fish out your test results
Last alternative is to let the tests run and then postprocess the results yourself.
Best Regards, Milosz
On Wed, Feb 7, 2024 at 11:11 PM Michael Peddie michael.peddie@gallagher.com wrote:
Hi again,
Just a quick follow-up to this. I did some re-reading (paying a little more attention to make sure I didn't miss anything), and still don't think there is a to: for the deploy action that I can use for my purposes. As stated previously, the file system is read-only, so is there a deploy that goes to the dispatcher and runs the commands over serial from there? From your explanation about the test job, that seems possible, but I'm not sure because (at least to me) the documentation on the deploy action is unclear.
Best 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
Hi Michael,
yeah, same questions as Milosz - what do you want to test, if not the deployed new software?
For U-Boot based devices, it's possible to load the image to a ramdisk and boot from there. So you can test new software, but don't have to modify the read-only filesystem on your device. That's how we test, saves the flash some write cycles ;)
Best regards
Stefan
On 2/8/2024 12:11 AM, Michael Peddie wrote:
Hi again,
Just a quick follow-up to this. I did some re-reading (paying a little more attention to make sure I didn't miss anything), and still don't think there is a to: for the deploy action that I can use for my purposes. As stated previously, the file system is read-only, so is there a deploy that goes to the dispatcher and runs the commands over serial from there? From your explanation about the test job, that seems possible, but I'm not sure because (at least to me) the documentation on the deploy action is unclear.
Best 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
Hi, apologies for the late response,
Yes I want to test the software. I am now wondering how the overlay works? I'm still quite new to LAVA, and if I'm honest not particularly experienced with the DUT and its system (both are custom, but I do know u-boot is in there somewhere).
Using LAVA, how would you load the image to a ramdisk and boot from it? I might be able to put together how to do it through the manual process, but I don't have a clue where to start with LAVA.
Apologies for any confusion and trouble, and thank you very much!
Best regards, Michael
On Sun, Feb 11, 2024 at 11:16 PM Michael Peddie michael.peddie@gallagher.com wrote:
Hi, apologies for the late response,
Yes I want to test the software. I am now wondering how the overlay works? I'm still quite new to LAVA, and if I'm honest not particularly experienced with the DUT and its system (both are custom, but I do know u-boot is in there somewhere).
Using LAVA, how would you load the image to a ramdisk and boot from it? I might be able to put together how to do it through the manual process, but I don't have a clue where to start with LAVA.
If your u-boot supports tftp download you can use it in LAVA job: https://validation.linaro.org/static/docs/v2/actions-deploy.html#to-tftp
IIRC LAVA will create a local tftp server and then drive u-boot cmdline to download binaries from the server.
Best Regards, Milosz
Apologies for any confusion and trouble, and thank you very much!
Best 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
I have tried uuu for deplo, and I kept getting the following error: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error Or it would simply get stuck and load for a while before I cancelled the job (with an error message before that saying /lava-x/bin/lavatest couldn't be found) So I think if I'm going to do an overlay, regardless of the read-only nature of the fs, I need to get an image that is compatible. Unless it can be booted on a device other than the DUT (virtual or no) and the tests run over serial. I have tried starting a QEMU device on the worker and running over serial from there (kind of ridiculous I know), but that has it's limits with telnet and exiting cleanly.
I have tried the interactive tests you sent before, and those are great for smoke tests, but I'm unsure about their use for longer or more complex tests that may be better run with scripts. Unless it's possible to run scripts stored locally on the worker through it, or downloaded from a git repo? (the latter I know isn't strictly possible, as Lava Test Def 1.0 tests are for that purpose). Which is why I'm back trying to get deploy working, so I can write a Lava Test Def 1.0 job and run it.
I will try tftp, though I will probably spend more time looking for those urls then writing and waiting for the job to run. Thank you very much.
Best regards, Michael
On Mon, Feb 12, 2024 at 9:16 PM Michael Peddie michael.peddie@gallagher.com wrote:
I have tried uuu for deplo, and I kept getting the following error: wrong fs type, bad option, bad superblock on /dev/sda, missing codepage or helper program, or other error Or it would simply get stuck and load for a while before I cancelled the job (with an error message before that saying /lava-x/bin/lavatest couldn't be found)
uuu is for NXP boards: https://github.com/nxp-imx/mfgtools Looking at the source, uuu deployment adds an overlay. So if you're on the NXP board and you don't have any signature verification this should work OK. I've never done it though.
So I think if I'm going to do an overlay, regardless of the read-only nature of the fs, I need to get an image that is compatible. Unless it can be booted on a device other than the DUT (virtual or no) and the tests run over serial. I have tried starting a QEMU device on the worker and running over serial from there (kind of ridiculous I know), but that has it's limits with telnet and exiting cleanly.
qemu is good to start with.
For the overlay part it consists of a few scripts that are part of LAVA source code: https://gitlab.com/lava/lava/-/tree/master/lava_dispatcher/lava_test_shell?r... On top of that there will be a set of test-definitions (if you include them in the test job). Some deployments methods modify the software you're delivering to the board beforehand, so once you have the software running on your HW the overlay is already there. There will still be some limitations coming from read-only fs, but you should be able to run more complex tests. Here is the source: https://gitlab.com/lava/lava/-/blob/master/lava_dispatcher/actions/deploy/ap... This won't work if you have any boot signing process in place as LAVA will attempt to modify images and this will invalidate their signatures.
I have tried the interactive tests you sent before, and those are great for smoke tests, but I'm unsure about their use for longer or more complex tests that may be better run with scripts. Unless it's possible to run scripts stored locally on the worker through it, or downloaded from a git repo? (the latter I know isn't strictly possible, as Lava Test Def 1.0 tests are for that purpose). Which is why I'm back trying to get deploy working, so I can write a Lava Test Def 1.0 job and run it.
Interactive tests are meant for the environments where you don't have a POSIX compliant shell (like u-boot shell). I guess they can also be used to overcome the read-only filesystem. But for complex cases where you need scripting it won't be a viable replacement.
I will try tftp, though I will probably spend more time looking for those urls then writing and waiting for the job to run. Thank you very much.
learning curve is steep here :/
Best Regards, Milosz
Best 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
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
lava-users@lists.lavasoftware.org
-
Michael Peddie -
Milosz Wasilewski -
Stefan