On Tue, Jan 20, 2026 at 8:58 AM pawanKumar pawan4749@gmail.com wrote:
Hi Milosz, Thanks for your response! I ran the test manually outside of LAVA, and it runs as expected without any delay. I have identified that the issue is that the automation is interrupting at the first U-Boot instance instead of the second. I have other boards which have only a single U-Boot and are working fine. Because LAVA interrupts at the first U-Boot, the board is failing to enter the correct Factory Mode. As a result, background services remain active during the test, causing the delays and failures I am seeing. I need help configuring LAVA to ignore the first U-Boot prompt and only interrupt during the second U-Boot. Here are the differences in the boot logs: First U-Boot (Ignore this):
Reset cause: POR DRAM: 256 MiB ... Hit any key to stop autoboot: 0
Second U-Boot (Interrupt here):
Reset cause: WDOG DRAM: 512 MiB ... Hit any key to stop autoboot: 0
In my Jinja2 device configuration, I have tried using a regex to anchor the interrupt to the second boot's unique strings, but LAVA still triggers on the very first "Hit any key" it sees in the serial buffer: jinja2
{% set uboot_autoboot_prompt = '(?s)Reset cause: WDOG.*Hit any key to stop autoboot' %} {% set uboot_interrupt_character = ' ' %} {% set uboot_interrupt_newline = False %} {% set bootloader_prompt = '=>' %}
1st issue with your regex is that it tries to match a single line. The text comes in multiple lines.
With a better regex it might work. This is what I tried: ^Reset cause:\s*WDOG[\s\S]*?Hit any key to stop autoboot:\s*0$
This is the site I use for prototyping regexes: https://regex101.com/
I'm not sure it works in LAVA, but it's worth to give it a try.
Best Regards, Milosz