Hi Tom,
On Wed, 30 Oct 2024 at 00:53, Tom Rini trini@konsulko.com wrote:
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 sjg@chromium.org
I _may_ see this myself sometimes, but I'm not sure.
OK, but it isn't really necessary for you to see it yourself. I've described above the repeatable problems I have with this approach.
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.
Yes, that's a use case that needs special support. If a board is booted from USB, then resets, it will run whatever it can find, perhaps just hang. Labgrid doesn't know the board is resetting and cannot therefore ensure that it sends the firmware over USB a second time (or sets the recovery line on the board). Resetting a board works OK using SDwire and some other cases, but will fail on quite a few of my boards.
Regards, Simon