Hi All,
My board is configured at 55000 baud for serial communication. Can work
only at this baud, Can we use lava with this configuration to get console
prints in test method. Default lava is supporting telnet with standard baud
rates. Is there a way to make 55000 baud for uart and get prints on lava.
Regards
Nagendra S
Hi,
In a previous thread where I was getting help to do a serial connection, I also needed help with the deploy action towards the end, so I'm just continuing that here.
I have been trying to do a deploy action for a couple of days now, and have been unsuccessful thus far. The obvious first hurdle is the image URLs for the various things needed for a tftp deploy action. I have compiled a u-boot kernel, and a DTB came with it, and I managed to sort the few errors I got with those (for now at least). I'm not sure modules are necessary, but I can figure that out later. The biggest issue I'm having is with the ramdisk.
There are many resources online for creating a ramdisk, but it is just a space in the ram for things to be stored temporarily (which I don't mind). But this does not work for lava, as it seems to require a file. I have tried compressing the directory created, and passing that, but because it is still just a directory lava won't accept it after I start the job.
So I'm assuming I have to acquire some kind of image somehow, how can I do this? Is there an online source I can download from? Or if I have to make it, how?
Best regards,
Michael
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.
Hey all,
I am currently trying to add a raspberry pi device to my lava installation however it keeps saying that I have an invalid device configuration.
This is the device dictionary
{% extends 'bcm2711-rpi-4-b.jinja2' %}
{% set connection_list = ['uart0']%}
{% set connnection_commands = {'uart0': 'telnet 10.60.2.209 7002'}%}
{% set connection_tags = {'uart0': ['primary','telnet']}%}
{% set power_off_command = 'python /hbus_power.py off' %}
{% set hard_reset_command = 'python /hbus_power reboot' %}
{% set power_on_command = 'python /hbus_power on' %}
Is there anything I'm doing wrong with this? or any other ideas as to what could be wrong?
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
Hi all,
Recently I updated device dictionary for my devices in lava server machine.
I added {% set user_commands = {'start_tpm': {'do': 'cmd1',
'undo': 'cmd2' }%}
in the following file /etc/lava-server/dispatcher-config/devices/qemu-01.jinja2
After updating I was successfully able to use these user defined commands in my job definitions using command action where ever i needed them.
But a strange thing is happening after I made the above mentioned changes is I am unable to start the job where it is throwing Infrastructure error: Cannot find command '' in $PATH` when I use minimal boot action in my job.
I cross checked this in 2 ways,
1. I removed my user command device dictionary related changes from my lava server and my job is starting and is completed successfully even if i have minimal boot action in my job.
2. I changed my boot action from ( method: minimal ) to (method: qemu , media: tmpfs ), and i retained user command device dictionary changes in my device template.. In this case also the job started and is completed successfully.
So is there some conflict between adding commands to device dictionary and using minimal boot action in our job ?
I am not sure how these two are related. My use-case badly requires minimal boot actions in my job as well as some user defined commands in device template. Please have a look at my job definition and run log https://lava.ciplatform.org/scheduler/job/1089996. I needed minimal boot action to finish the boot action only if i get a particular shutdown-message or else I want it to timeout and be incomplete.
Can anyone please help me how to resolve this issue ?
Hi All
I am trying to sort out using queries to make charts and I am running into two problems.
1. Even after adding conditions I can not run queries as the button is disabled. I can get around this by changing it to a live query but I would prefer to be able to use the actual button.
2. I can't view a chart.
When I try to do this I just get a loading screen that won't end. According to the Console, the error is either undefined properties or functions not existing.
My query selects all jobs with a test suite with a name equal to 0_smoke-tests and then my graph is Type: pass/fail, Representation: bar, X-axis attribute: none.
I am wondering if these are bugs or if I am doing something wrong.
If anyone can help that would be greatly appreciated
Thanks
Daniel
Hi,
As stated in the subject, I was wondering if it is at all possible to use a repo on Azure DevOps instead of a GitHub one.
I have been using a GitHub repo thus far, and it works just fine, but I need to move my files over to DevOps.
According to the docs here: https://docs.lavasoftware.org/lava/actions-test.html only git is supported at the moment, with URL and tar planned for. Would URL work for this if support came in at any point? Or would azure need its own support?
Or should git work and there is something wrong with the repo URL I am using? Because the particular error I get is that the password could not be read (I'm using a PAT in the link, like I did for GitHub)
Best Regards.
Michael
Hello Team,
I was trying to flash a binary on the device and run the tests on the
device by using lava overlay.
Board flashes successfully but while booting the device in the boot log
there is a word "*** Invalid partition 3 ***" lava catches the key word
and throws an error message.
For the other devices it is not catching this error with the same boot log.
Only on one device I'm observing this issue.
Please let me know How to ignore the keyword and move on to run the tests.
matched a bootloader error message: 'Invalid partition' (17)
boot log:
*U-Boot SPL 2022.04 (Nov 30 2023 - 20:10:15
+0000)power_bd71837_initDDRINFO: start DRAM initDDRINFO: DRAM rate
1600MTSDDRINFO:ddrphy calibration doneDDRINFO: ddrmix config doneNormal
BootTrying to boot from MMC1hab fuse not enabledAuthenticate image from DDR
location 0x401fcdc0...NOTICE: BL31:
v2.6(release):lf-5.15.32-2.0.0-0-gc6a19b1a3-dirtyNOTICE: BL31: Built :
06:37:22, Jun 7 2022U-Boot 2022.04 (Nov 30 2023 - 20:10:15 +0000)CPU:
i.MX8MMD rev1.0 1600 MHz (running at 1200 MHz)CPU: Industrial temperature
grade (-40C to 105C) at 44CReset cause: PORModel: DRAM: 224
MiBboard_initCore: 61 devices, 21 uclasses, devicetree: separateMMC:
FSL_SDHC: 0Loading Environment from nowhere... OKIn: serialOut:
serialErr: serialSEC0: RNG instantiated BuildInfo: - ATF c6a19b1facmod
value is 1!pulse number is 0�flash target is MMC:0Fastboot: NormalNormal
BootHit any key to stop autoboot: 2 end: 3.4.2 bootloader-interrupt
(duration 00:00:05) [common]start: 3.4.3 bootloader-commands (timeout
00:02:52) [common]Setting prompt string to ['=>']bootloader-commands: Wait
for prompt ['=>'] (timeout 00:02:52) 0 Setting prompt string to
['=>']Sending with 5 millisecond of delaysetenv factorymode 1u-boot=>
setenv factorymode 1bootloader-commands: Wait for prompt ['=>'] (timeout
00:02:51)setenv factorymode 1Sending with 5 millisecond of
delaybootu-boot=> bootboot** Invalid partition 3 **Couldn't find partition
mmc 0:3Can't set block deviceuEnv not found in mmcpart3, checking
mmcpart1Failed to load '/boot/system/uEnv'uEnv not found in mmcpart 1
either!Booting from mmc ...## Error: \"w\" not definedmatched a bootloader
error message: 'Invalid partition' (17)end: 3.4.3 bootloader-commands
(duration 00:00:02) [common]case: bootloader-commandscase_id:
204071definition: lavaduration: 1.52extra: ...level: 3.4.3namespace:
commonresult: fail*
Best Regards
Pavan Kumar
Hello everyone,
I am trying to implement a test case scenario in which I need to confirm partition scheme, environment variables after the reboot which is triggered by the watchdog I am using. So basically I need to be able to successfully login to the image after the reboot triggered by the watchdog.
It feels like the link between the test Job and the Linux image is lost after the reboot done by the watchdog. Whatever actions present after that reboot ( boot or test actions ) are not working.
Below is the template of my Job definition:
job details...
device_type: qemu
#### (timeouts)
###(priority)
##(notify, context etc.)
actions
- deploy
images: ###
firmware: ###
- boot
auto_login:
login_prompt: "###"
username: "##"
password_prompt: "###"
password: "##"
- test:
definitions: ###
repository: ####
metadata: ###
run:
steps:
- swupdate -i ####
- reboot
-------------------------------------------------
At this stage I introduced a service which causes kernel panic during the reboot (by the command explicitly given by me above in the job). So after 'X' seconds of watchdog timeout , a second reboot is triggered by the watchdog. During that reboot done by watchdog, the kernel booted successfully, all the services were set up fine, but the test stopped at the login stage.
I think it did not get the "login_prompt" and ''password_prompt" from the boot action I wrote after the above test action ( i.e after reboot done by watchdog ).
- boot
auto_login:
login_prompt: "###"
username: "##"
password_prompt: "###"
password: "##"
So Is there a way to add boot and test actions in such a way that the test job can be continued after reboot is done by a watchdog ?
Note: When I explicitly provide "reboot" in steps section in test action, then the link did not break and I was able to reboot, login and run test action steps successfully no matter how many times I wanted.
This query is specifically for cases in which reboot happened out of test writer's scope. (i.e like reboot triggered by a watchdog)