Hi Tom,
On Wed, 30 Oct 2024 at 00:53, Tom Rini trini@konsulko.com wrote:
On Wed, Oct 09, 2024 at 07:51:39PM -0600, Simon Glass wrote:
There is quite a bit of code in pytest to try to start up U-Boot on a board, with timeouts, expects, etc.
This is tedious to maintain and is peripheral to the test system's purpose. It seems better to put this logic in the lab itself, where is can provide such support.
With Labgrid we can use the UbootStrategy class to get the board into a useful state, however it needs to do it. Then it can report to pytest by writing a suitable string along with the U-Boot version it detected.
Add support for detecting 'lab mode' and simply assume that all is well in that case. Collect the version string when Labgrid says it is ready.
Signed-off-by: Simon Glass sjg@chromium.org
First, I worry that this kind of change will make verifying boards can reset harder, not easier. But second, taking the "tedious" part and putting in another project's config file instead makes it no less "tedious". If I follow the labgrid code right, it's got the same kind of "check for a string" that we have, except it's not caring about the correct number / order of banner prints. Which I find worrisome and a problem because of the times I've caught "oops, didn't actually test the right stuff" because that was wrong.
I am not asking you to use this Labgrid integration., though Please feel free to do things as you currently do. For me, this works very well and avoids the persistent failures I was otherwise seeing.
Regards, Simon