Hello, I am new to LAVA, I want to boot up my hardware(NET-I System)which is a x86_64 and install debian bookworm image over it and execute test cases. My h/w is connected to my LAVA server via a serial device.Below is the high level job that I am planning to use. But where should I specify the serial device information and other information?Could please share any example job and device .jija2 that I can refer regarding what all information needs to be provided for LAVA server to properly connect to H/W and also is u-boot correct for my usecase? or if there is any other suggestions :
device_type: your_device_type job_name: debian_boot_test timeouts: job: minutes: 15 action: minutes: 5 connection: minutes: 2
actions: - deploy: timeout: minutes: 10 to: tftp images: rootfs: url: <Debian Image>
- boot: method: u-boot commands: your_device_boot_commands prompts: - 'login:' parameters: boot_options: root=/dev/ram0
- test: timeout: minutes: 5 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: debian-check-test description: "Test to verify Debian OS" os: - debian run: steps: - echo 'Checking if OS is Debian' - 'if [ "$(lsb_release -is)" = "Debian" ]; then echo "OS is Debian"; else echo "OS is not Debian"; fi' from: inline name: debian-check-test path: inline/debian-check-test.yaml
What I have probably won't 100% work for you, as I have mine tailored to my needs and solve issues only I seem to have, but my device dictionary (the device.jinja2) looks something like this: {% extends 'custom.jinja2' %}
{% set power_off_command = 'python /power.py 12 off' %} # Call on worker to custom python script to control power off {% set soft_reboot_command = 'reboot'%} # Command on device to reboot, does not completely power off device though {% set hard_reset_command = 'python /power.py 12 reboot' %} # Full reboot, power off and on {% set power_on_command = 'python /power.py 12 on' %} # Power on through same power control script {% set connection_list = ['uart0'] %} # Not completely sure on the purpose of this, copied it from somewhere else {% set connection_commands = {'uart0': 'minicom -w -o --term=linux-c-nc --device /dev/ttyUSB0'} %} # My command to connect to my DUT through # serial, though officially it is recommended to use telnet through the ser2net service installed with LAVA (look through the docs and the mailing list) {% set connection_tags = {'uart0': ['primary', 'minicom']} %} # Tags, though minicom isn't a valid tag {% set pre_power_command = "python /power.py 12 off 60" %} # A custom command for if/when the version of the device image is updated {% set bootm_kernel_addr = '/kernel.img' %} # For the deploy config bootloader_prompt: "# $" # From when I used to use telnet, to help prevent run-on commands
And here is my test job definition (with some omissions and modifications for privacy and security purposes): device_type: custom job_name: a cool job name context: lava_test_results_dir: /tmp/lava-%s timeouts: job: minutes: 25 action: minutes: 20 connection: minutes: 5 priority: medium visibility: public actions: - deploy: timeout: minutes: 5 to: tftp kernel: url: file:///kernel.img type: uimage ramdisk: url: file:///ramdisk.gz compression: gz dtb: url: file:///u-boot.dtb - boot: transfer_overlay: transfer_method: http download_command: cd / ; tar -C /tmp/ -xzf /data/wgetcurl.tar.gz ; cd /tmp/ ; ./wgetcurl/wget -nv unpack_command: tar -C /tmp -xzf timeout: minutes: 5 method: minimal prompts: ["# $"] auto_login: login_prompt: "login:" username: root - test: timeout: minutes: 10 definitions: - repository: https://<PAT>@github.com/MichaelPed/lava-tests.git from: git path: some-pathB/test-set-B.yaml name: test-set-B history: False - boot: transfer_overlay: transfer_method: http download_command: cd / ; tar -C /tmp/ -xzf /data/wgetcurl.tar.gz ; cd /tmp/ ; ./wgetcurl/wget -nv unpack_command: tar -C /tmp -xzf pre_power_command: true timeout: minutes: 5 method: minimal prompts: ["# $"] auto_login: login_prompt: "login:" username: root - test: timeout: minutes: 10 definitions: - repository: https://<PAT>@github.com/MichaelPed/lava-tests.git from: git path: some-pathA/test-set-A.yaml name: test-set-A history: False
This test job will get a script from a repo, which has some lines to download the image version I want to install on my device, then runs a command to do so, and as this "test" ends, the pre_power command for the next boot and test actions is run to do a total reboot of the device and let the image actually be applied. It probably won't help to share that script as it uses some proprietary commands for the custom image, that would likely prove useless to you. But if connection via serial, and updating and testing in one test is what you need, then this should be enough.
There were some specific decisions behind using a tftp deploy and then doing a transfer_overlay to the DUT that I won't get into, but whether you copy this set up or not I can't provide advice on whether that is a good idea or not, so proceed at your own discretion.
I hope this helps, and apologies if it has come too late or is not useful at all.
Hello Michael,
Thanks for providing these details. Its helpful for my configuration.
What I am planning to do is the following:
* Power on my hardware connected via serial connection to LAVA. (Trying to figure out power on command via ser2net) * Go to Bios menu to select USB as a boot option. (USB with Live Debian image will be connected to my h/w beforehand) * Once system boot up it will get a login and IP. (Need to figure out how to get the ip ) * I will execute basic test cases via ssh
This my plan so far, still trying to figure out how much LAVA will support.
Thanks, Sweta ________________________________ From: Michael Peddie michael.peddie@gallagher.com Sent: Tuesday, July 23, 2024 2:21 AM To: lava-users@lists.lavasoftware.org lava-users@lists.lavasoftware.org Subject: [lava-users] Re: bootup a server and deploy debian bookworm over serial connection
[Email from a non-Nagarro source: please exercise caution with links and attachments]
What I have probably won't 100% work for you, as I have mine tailored to my needs and solve issues only I seem to have, but my device dictionary (the device.jinja2) looks something like this: {% extends 'custom.jinja2' %}
{% set power_off_command = 'python /power.py 12 off' %} # Call on worker to custom python script to control power off {% set soft_reboot_command = 'reboot'%} # Command on device to reboot, does not completely power off device though {% set hard_reset_command = 'python /power.py 12 reboot' %} # Full reboot, power off and on {% set power_on_command = 'python /power.py 12 on' %} # Power on through same power control script {% set connection_list = ['uart0'] %} # Not completely sure on the purpose of this, copied it from somewhere else {% set connection_commands = {'uart0': 'minicom -w -o --term=linux-c-nc --device /dev/ttyUSB0'} %} # My command to connect to my DUT through # serial, though officially it is recommended to use telnet through the ser2net service installed with LAVA (look through the docs and the mailing list) {% set connection_tags = {'uart0': ['primary', 'minicom']} %} # Tags, though minicom isn't a valid tag {% set pre_power_command = "python /power.py 12 off 60" %} # A custom command for if/when the version of the device image is updated {% set bootm_kernel_addr = '/kernel.img' %} # For the deploy config bootloader_prompt: "# $" # From when I used to use telnet, to help prevent run-on commands
And here is my test job definition (with some omissions and modifications for privacy and security purposes): device_type: custom job_name: a cool job name context: lava_test_results_dir: /tmp/lava-%s timeouts: job: minutes: 25 action: minutes: 20 connection: minutes: 5 priority: medium visibility: public actions: - deploy: timeout: minutes: 5 to: tftp kernel: url: file:///kernel.img type: uimage ramdisk: url: file:///ramdisk.gz compression: gz dtb: url: file:///u-boot.dtb - boot: transfer_overlay: transfer_method: http download_command: cd / ; tar -C /tmp/ -xzf /data/wgetcurl.tar.gz ; cd /tmp/ ; ./wgetcurl/wget -nv unpack_command: tar -C /tmp -xzf timeout: minutes: 5 method: minimal prompts: ["# $"] auto_login: login_prompt: "login:" username: root - test: timeout: minutes: 10 definitions: - repository: https://<PAT>@github.com/MichaelPed/lava-tests.git from: git path: some-pathB/test-set-B.yaml name: test-set-B history: False - boot: transfer_overlay: transfer_method: http download_command: cd / ; tar -C /tmp/ -xzf /data/wgetcurl.tar.gz ; cd /tmp/ ; ./wgetcurl/wget -nv unpack_command: tar -C /tmp -xzf pre_power_command: true timeout: minutes: 5 method: minimal prompts: ["# $"] auto_login: login_prompt: "login:" username: root - test: timeout: minutes: 10 definitions: - repository: https://<PAT>@github.com/MichaelPed/lava-tests.git from: git path: some-pathA/test-set-A.yaml name: test-set-A history: False
This test job will get a script from a repo, which has some lines to download the image version I want to install on my device, then runs a command to do so, and as this "test" ends, the pre_power command for the next boot and test actions is run to do a total reboot of the device and let the image actually be applied. It probably won't help to share that script as it uses some proprietary commands for the custom image, that would likely prove useless to you. But if connection via serial, and updating and testing in one test is what you need, then this should be enough.
There were some specific decisions behind using a tftp deploy and then doing a transfer_overlay to the DUT that I won't get into, but whether you copy this set up or not I can't provide advice on whether that is a good idea or not, so proceed at your own discretion.
I hope this helps, and apologies if it has come too late or is not useful at all. _______________________________________________ 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 -
Sweta Ghosh -
sweta.ghosh＠nagarro.com