On Wed, Sep 25, 2024 at 02:49:56PM +0200, Simon Glass wrote:
Hi Tom,
On Mon, 23 Sept 2024 at 22:35, Tom Rini trini@konsulko.com wrote:
On Fri, Sep 20, 2024 at 08:01:36AM +0200, 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.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
test/py/u_boot_console_base.py | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
What happens is that labgrid can also be told to look for and then interrupt autoboot, just like our pytests can do, and the system is at the prompt. But this is also what it's like for a system with autoboot disabled. Do we actually need this patch to achieve the functionality you want? Doesn't that already just happen?
The point of this patch is actually to remove code in pytest, by allowing it to skip all the banner-detection stuff. It does not affect things in Labgrid, since it still needs to watch for banners, etc.
But you can't remove code from pytest, people can and will run the suite outside of labgrid.
Without this patch, we have to tell Labgrid's U-Boot driver to do nothing, so that pytest does it. But that is not a good idea, since Labgrid has a lot more info about the board than pytest has. For example, look at all the SPL-banner-count stuff.
Why do you have to tell it to do nothing? The pytest suite works fine, today, if the board stops at the prompt automatically. To be clear, the labgrid yaml file I'm using with my scripts has the information to stop autoboot in it and it's not causing a problem.
Basically, without this patch we cannot use '-s uboot' to tell the Labgrid strategy to take us to a U-Boot prompt. We must just use a raw console with no strategy, relying on pytest to do all the work.
I hope that helps explain the problem?
I think I see what you're saying, and it's based on the assumption that we'll make everyone either use labgrid?