The process I expect is: 1. test board restart 2. catch the bootup log by serial port 3. deploy the test suit (test script) by ssh 4. run test case by ssh or uart (ssh is better) 5. These are concentrated in one yaml and all logs are captured.
Now I try to restart the test board by below code, it works, board reboot successfully
device: actions: deploy: methods: {% if flasher_reset_commands %} flasher: commands: {{ flasher_reset_commands }} {% endif %}
test yaml - deploy: timeout: minutes: 30 to: flasher images: kernel: url: http://10.19.207.190/static/docs/v2/contents.html#contents-first-steps-using
But if I add ssh to deploy in the device file, the yaml remains unchanged and I will be prompted with device BAD. device as blow: {# device_type: orinnew #} {% extends 'base.jinja2' %}
{% block body %}
actions: deploy: methods: {% if flasher_reset_commands %} flasher: commands: {{ flasher_reset_commands }} {% endif %} ssh: options: {{ ssh_options }} # primary connections get this from the device dictionary. # secondary connections get this from the lava-multinode protocol support. host: "{{ ssh_host|default('') }}" port: {{ ssh_port|default(22) }} user: "{{ ssh_user|default('root') }}" identity_file: "{{ ssh_identity_file }}"
boot: connections: serial: methods: ssh: minimal:
{% endblock body %}
1. Where did I go wrong to cause this problem? 2. Every time you paste code, there will be formatting problems. How to paste code in this mail list? It has an effect similar to markdown.
Found during debugging, the error message of the "BAD" as below: When primary connection is used, power control commands (power_off, power_on, hard_reset) should not be specified.
when I remove the following part from device-type, it will be ok. ssh: options: {{ ssh_options }} # primary connections get this from the device dictionary. # secondary connections get this from the lava-multinode protocol support. host: "{{ ssh_host|default('') }}" port: {{ ssh_port|default(22) }} user: "{{ ssh_user|default('root') }}" identity_file: "{{ ssh_identity_file }}"
it seems that the deploy flasher conflicts with ssh. So if I want to deploy the test program through flasher (burn and restart board) and deploy test program through ssh, what should I do?
I think you might have an issue with indentation in your device dict. There is a script that can help debug that: # /usr/share/lava-common/lava-schema.py device /etc/lava-server/dispatcher-config/devices/<your_device_name>.jinja2
I'm assuming you're using default paths for LAVA installation.
Best Regards, Milosz
On Mon, Jan 8, 2024 at 7:54 AM irreallich@126.com wrote:
Found during debugging, the error message of the "BAD" as below: When primary connection is used, power control commands (power_off, power_on, hard_reset) should not be specified.
when I remove the following part from device-type, it will be ok. ssh: options: {{ ssh_options }} # primary connections get this from the device dictionary. # secondary connections get this from the lava-multinode protocol support. host: "{{ ssh_host|default('') }}" port: {{ ssh_port|default(22) }} user: "{{ ssh_user|default('root') }}" identity_file: "{{ ssh_identity_file }}"
it seems that the deploy flasher conflicts with ssh. So if I want to deploy the test program through flasher (burn and restart board) and deploy test program through ssh, what should I do? _______________________________________________ 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, sorry for late and thank you for your reply. There is no problem with my indentation, because I don't know how to send the code to the mail system of lists.lavasoftware.org correctly, I can only copy the code through the web page, which causes the indentation to look wrong. I now want to implement a test pipeline: 1. I use deploy -> methods flasher to run the command on the worker to restart the board, it is ok. 2. I use boot -> methods minimal to log in to the board by uart and run cmd to start ssh server, it is ok. 3. I hope to deploy my test tools to the board by scp and run it by ssh , I guest lava-multinode or namespace it work for it, but I don't know how to do . could you please give me suggestion for this ?
By the way, I couldn't open my git client, How can I insert code into this maillist, just like markdown?
thank you
On Sun, Feb 4, 2024 at 3:34 AM irreallich@126.com wrote:
Hi, Milosz, sorry for late and thank you for your reply. There is no problem with my indentation, because I don't know how to send the code to the mail system of lists.lavasoftware.org correctly, I can only copy the code through the web page, which causes the indentation to look wrong. I now want to implement a test pipeline:
- I use deploy -> methods flasher to run the command on the worker to restart the board, it is ok.
- I use boot -> methods minimal to log in to the board by uart and run cmd to start ssh server, it is ok.
- I hope to deploy my test tools to the board by scp and run it by ssh , I guest lava-multinode or namespace it work for it, but I don't know how to do .
could you please give me suggestion for this ?
tbh I've never used ssh in LAVA so I've no idea how this works. There are some scp methods in the code so it might work as you describe. I don't think you need a namespace or multinode for a single ssh deployment. It should work similarly to downloading overlay over http.
By the way, I couldn't open my git client, How can I insert code into this maillist, just like markdown?
I would either post a link to some pastebin or attach a small text file.
Best Regards, Milosz
thank you _______________________________________________ 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, the test pipeline on my side as below, the test device is power on by default. 1. download the flash packet (include kernel, bootloader and some firmware of other mcu) 2. power off the board , change bootup pin to flash mode, power on the board 3. flash 4. power off the board, change bootup pin to normal mode, power on the board 5. get log by uart and download the debug overlay by shell cmd(scp, http, git are all ok) 6. login 3 or 4 ssh clent , why we need login with ssh, we need to start other terminals to monitor the MCU firmware log. These MCUs are part of the chip, we are a HSA system 7. start the test by uart or ssh 8. power off -> power on -> step 5,6,7 -> power off -> power on -> step 5,6,7 -> power off -> .....
How do I implement this kind of testing?
On Tue, Feb 6, 2024 at 2:34 AM irreallich@126.com wrote:
Hi Milosz, the test pipeline on my side as below, the test device is power on by default.
- download the flash packet (include kernel, bootloader and some firmware of other mcu)
- power off the board , change bootup pin to flash mode, power on the board
- flash
- power off the board, change bootup pin to normal mode, power on the board
- get log by uart and download the debug overlay by shell cmd(scp, http, git are all ok)
if you can download from the board using wget/curl, then you only need to add transfer_overlay to your boot section. Example: transfer_overlay: download_command: cd /home ; wget unpack_command: tar -C /home/ -xzf
You'll need to experiment with unpack_command and context/lava_test_results_dir to get the overlay to a proper directory. In the example above the following setting should work context: lava_test_results_dir: /home/lava-%s
- login 3 or 4 ssh clent , why we need login with ssh, we need to start other terminals to monitor the MCU firmware log. These MCUs are part of the chip, we are a HSA system
https://docs.lavasoftware.org/lava/connections.html
I've never done this, so the docs are the only resource I can help with.
- start the test by uart or ssh
- power off -> power on -> step 5,6,7 -> power off -> power on -> step 5,6,7 -> power off -> .....
I would strongly suggest running just one sequence in one test job. If you want to run more, you'll need to have a separate namespace for each deploy/boot/test section. Without it LAVA starts overwriting overlays and your job executes wrong tests (or more likely fails altogether). At this point the setup gets really complicated and hard to maintain. It can be done, but it's good to think about running it long term.
Best Regards, Milosz
How do I implement this kind of testing? _______________________________________________ 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, Thank you for your help ,I will try it and update soon, I think it should be work. we need Another questions: 1. Why don't you recommend using scp to deploy, because deploying using scp looks very beautiful. 2. Is there a way to add worker to lava-server through worker? since our test device is limited and in the hands of different engineers, I hope to be able to add these devices to lava-server when the device is free, i want to make a docker on the engineer's pc, the docker is lava-dispatcher, when a run the docker, how to add it to lava-server on lava-dispatcher?
On Sun, Feb 18, 2024 at 10:02 AM irreallich@126.com wrote:
Hi, Milosz, Thank you for your help ,I will try it and update soon, I think it should be work. we need Another questions:
- Why don't you recommend using scp to deploy, because deploying using scp looks very beautiful.
I've never used it and I don't know how/if it works. You might be lucky though :)
- Is there a way to add worker to lava-server through worker? since our test device is limited and in the hands of different engineers, I hope to be able to add these devices to lava-server when the device is free, i want to make a docker on the engineer's pc, the docker is lava-dispatcher, when a run the docker, how to add it to lava-server on lava-dispatcher?
You need to setup worker as 'auto-registration'. This is done by creating a user with proper privileges to create auth tokens and workers. Then lava-worker script accepts the parameters --username and --password. You need to send the username and password to people who are going to run the dispatcher. Sadly I didn't find this in the docs, so I can't point you to any examples. Alternatively you just generate workers (with tokens) in the admin interface and send them (tokens) out to your colleagues. Both methods do pretty much the same thing.
Best Regards, Milosz
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
Thanks Milosz, about 'auto-registration', Can you give me some suggestions on how to get more detailed help? Is it on another maillist? Sorry, I'm not very familiar with the use of maillists. It's best to get examples
On Tue, Feb 20, 2024 at 2:59 AM irreallich@126.com wrote:
Thanks Milosz, about 'auto-registration', Can you give me some suggestions on how to get more detailed help? Is it on another maillist? Sorry, I'm not very familiar with the use of maillists. It's best to get examples
start worker with username: lava-worker --username XXXX --password XXXX
Best Regards, MIlosz
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
-
irreallich＠126.com -
Milosz Wasilewski