Hi,
Your scenario is possible, but will require a bit of creativity.
On Wed, Sep 20, 2023 at 7:37 AM irreallich@126.com wrote:
Hi, There are mcu and soc on my board, two serial port for them( ttyusb0:mcu, ttyusb1:soc), the hostpc ( it is used for lava worker) connected to the two serial ports, and reboot soc cmd is echo "soc boot" > /dev/ttyUSB0 . then we can see boot log at ttyUSB1. We want to use lava to test soc system, it is arm64 with linux , without uboot . and we hope to add build action in the device. So the deploy and boot steps should be:
- run build.sh on hostpc (it should be lava worker) and check the result (failed and pass)
I would advise against it. LAVA is meant to automate software/firmware deployment and testing. Building inside lava job is possible but it's not a good idea.
- run echo "soc burn" > /dev/ttyUSB0 on hostpc to change the soc to burn mode, and check the result (failed and pass)
- run burn.sh on hostpc to burn to soc , and check the result (failed and pass)
steps above are part of "deployment" in LAVA naming convention. There is no method that can do that out of the box. You'll probably need to use "flasher" deployment and write these steps in your script. Lava will execute the script for you.
- run echo "soc boot" > /dev/ttyUSB0 to reboot soc , and check the result (failed and pass)
This looks like "power on" action. Although I'm not 100% sure. LAVA will require you to provide "power on", "power off" and "reset" actions. These are used throughout the job in various places.
- connect to /dev/ttyUSB1 to get soc boot log, and check the result (failed and pass)
This looks like "boot" step in LAVA convention. The only thing you need to do for this to work is to define a serial connection. ttyusb1 should be the serial in your case.
- ssh to the linux of soc.
I would avoid that if possible. To ssh into the DUT you'll need something on the other end of the connection. This usually implies either "secondary connection" or "multinode" in LAVA convention. IMHO both are a bit too advanced for this scenario. By default LAVA uses serial to interact with the DUT.
What I want to know is:
- Is the above design feasible on lava?
yes, see above.
- What do I need to do for this? Are there any device type templets that I can refer to?
A bit of creativity for sure :) I have similar devices setup in my LAB. They require switching to "download" mode with HW switches. If you replace HW switches with your serial commands to ttyusb0, it looks fairly similar. Here is example device dictionary: https://lava.infra.foundries.io/scheduler/device/imx8mm-evk-01/devicedict example health check job: https://lava.infra.foundries.io/scheduler/job/28279/definition
In theory you can perform your build in the "postprocess" step, but as I mentioned above I would avoid that and use some external builders (github, jenkins, etc.) When deploying to flasher flasher_deploy_commands is called. You can place almost anything there. Some variables in curly brackets can be replaced with proper values on the worker.
Best Regards, Milosz
The following is my lava system, I can run the test job with qemu device now.
~/work/src/lava $ dpkg -l |grep lava ii lava 2022.11.1+10+buster all Linaro Automated Validation Architecture metapackage ii lava-common 2022.11.1+10+buster all Linaro Automated Validation Architecture common ii lava-coordinator 2022.11.1+10+buster all LAVA coordinator daemon ii lava-dev 2022.11.1+10+buster all Linaro Automated Validation Architecture developer support ii lava-dispatcher 2022.11.1+10+buster all Linaro Automated Validation Architecture dispatcher ii lava-dispatcher-host 2022.11.1+10+buster all LAVA dispatcher host tools ii lava-server 2022.11.1+10+buster all Linaro Automated Validation Architecture server ii lava-server-doc 2022.11.1+10+buster all Linaro Automated Validation Architecture documentation ii lava-tool 0.25-2 all deprecated command line utility for LAVA ii lavacli 0.9.7+buster all LAVA XML-RPC command line interface ~/work/src/lava $ _______________________________________________ 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