On Wed, 3 Oct 2018 at 08:41, Denis HUMEAU denis.humeau@st.com wrote:

Dear users,

I’m looking for a way to detect a possible watchdog in u-boot during a test session.

It happened that on one our test platforms a watchdog was triggered, u-boot restarted, and eventually the test session started. Unless we take a look at every trace of every job, there is a big chance to leave this type of errors undetected.

Unless your build of U-Boot contains a watchdog which always emits a unique string, there is no reliable way to detect this - it could happen at any point in the test job, not just during boot. Sadly, many bootloaders / firmware builds generate these resets without declaring what is happening and LAVA cannot always be watching for an unexpected reboot because the extra pattern matching strings would add too much overhead. As it is, LAVA only watches for bootloader error messages during the boot action.

Do you have any idea on a possible way to handle this in Lava, maybe via device dictionary?

Not via device dictionary, no. However, we already have support for two (common?) watchdog messages as this occurred during device integration of one of the early U-Boot devices:

https://git.lavasoftware.org/lava/lava/blob/master/lava_scheduler_app/tests/...

- 'Resetting CPU' - 'Must RESET board to recover'

- these messages are only monitored *during the boot action*.

At other points, you should ensure that the device does not automatically reboot into anything. Once reset and if the "Hit any key to stop autoboot" is not interrupted, it should halt at the bootloader prompt, especially if you are getting issues with a watchdog being triggered. This comes down to U-Boot environment settings. Every expected boot in a LAVA test job should be managed by LAVA (with the exception of a small number of devices which combine U-Boot with fastboot).

Thanks in advance,

Denis _______________________________________________ Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users