Hi Tom, On Wed, 30 Oct 2024 at 00:53, Tom Rini <tr...@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 <s...@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
