On Wed, Oct 09, 2024 at 07:51:35PM -0600, Simon Glass wrote: > When Labgrid is used, it can get U-Boot ready for running tests. It > prints a message when it has done so. > > Add logic to detect this message and accept it. > > Note that this does not change pytest, which still (also) looks for the > U-Boot banner. This change merely makes it possible for pytest to > believe Labgrid when it says that the board is ready for use. > > In several cases, the board starts up and Labgrid receives some initial > output, then pytest starts and misses some of that output, because it > came in while Labgrid had the console open. Then pytest fails because > it doesn't see the expected banners. > > With this change, Labgrid handles getting U-Boot to a prompt, in a > fully reliable manner. Then pytest starts up and can simply start > running its tests. > > But, again, this does not prevent pytest from handling a banner if one > is provided (e.g. if not using the Labgrid integration). > > Signed-off-by: Simon Glass <s...@chromium.org>
I _may_ see this myself sometimes, but I'm not sure. But I'm not sure where the bug would be between us and labgrid. Looking at test/py/u_boot_console_exec_attach.py we grab the console and then reset the target. If the spawn hasn't completed, especially before the power cycle has completed (which in labgrid defaults to 2 seconds) we perhaps need our own delay. But as I'll point out further on, NOT counting the banners means we aren't able to verify other functionality. Even if they are tests that I think you don't like because they verify the functionality of resetting the device. -- Tom
signature.asc
Description: PGP signature
