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