bootloader: detect boot

[jremmet]

The boot_expression feature for u-boot was deprecated to sync barebox with features and to allow to connect to a running bootloader.

Readd the feature for both bootloaders and use the check only to set the boot_detected flag.
So after getting a prompt we can check if the bootloader runs trough a reboot.
Show this in the 'reset' method.

Checklist

• Documentation for the feature
• Tests for the feature

• The arguments and description in doc/configuration.rst have been updated

• Add a section on how to use the feature to doc/usage.rst

• Add a section on how to use the feature to doc/development.rst

• PR has been tested on uboot
• PR has been tested on barebox

• Man pages have been regenerated

[codecov]

Codecov Report

Attention: Patch coverage is 88.88889% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 62.3%. Comparing base (d8835d5) to head (226b3eb).
Report is 12 commits behind head on master.

Files	Patch %	Lines
labgrid/driver/bareboxdriver.py	88.8%	1 Missing ⚠️
labgrid/driver/ubootdriver.py	88.8%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           master   #1191     +/-   ##
========================================
- Coverage    62.7%   62.3%   -0.5%     
========================================
  Files         163     164      +1     
  Lines       12025   12203    +178     
========================================
+ Hits         7550    7611     +61     
- Misses       4475    4592    +117     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jremmet]

@Bastian-Krause We want to do some Watchdog tests and rely on the bootloader driver to detect the reboot. We could do this in the test but we like the idea of having this beside the other bootloader configs like the prompt.
A 2nd use case is that we have switchable powersupply which has a manual overwrite for always on. So it happens that we don't power on the board via labgrid. Before the deprecation this runs into a bootloader timeout. Now it starts the tests.

So short having the feature back and only disable the check if we force a state would be good for out use cases. Not sure If this acceptable for the project. This PR tries to solve it without changing too much. (Without addressing accidentally running boards)

[Bastian-Krause]

I'd probably implement the self.console.expect() directly in reset() and drop self.check_boot altogether.

I'm torn between having boot_expression as a driver attribute and passing it as a kwarg to reset() (or await_boot()?): I think boot_expression does not make it clear that it's only used on reset(). Then there's the previous functionality (before #259), then the deprecation (#965) and now we reintroduce it with a subtly different meaning, that's not ideal. I am unsure if a driver argument is justified for this very specific use case.
If we allow passing it as a kwarg to reset() or await_boot(), we'd need to change the LinuxBootProtocol.

@Emantor What do you think?

[jremmet]

We also have trouble if we accidentally connect to a running bootloader. Before deprecation we run into a timeout in this case. (Our power switch has a manual "always on" overwrite...)

Would this a acceptable solution?:
Like the old behavior check the boot_expression in _await_prompt as default, but add a flag to skip it for the "force" from the strategies

[Emantor]

The decision to remove this support was to let drivers be deactivated and activated even if the bootloader is already running, which is necessary to support reusing the current state of the board within a labgrid client state transition.

In my opionion testing a watchdog reset belongs to the testcase and using labgrid functionality for this is not the correct approach. What you want to do for watchdog testing anway is to set a global variable inside the bootloader, deactivate the driver, wait for the watchdog reset and reactivate the driver. Than the test can check whether the variable is not there any longer and this is a new running instance of the bootloader and even check the reset reason if this is possible with the board.

I don't have a solution for the case where you have a manual override on the power switch. Can this be queried by software? I think this is more of an organizational problem than something that can be solved with a technical solution inside of labgrid.

[jremmet]

The decision to remove this support was to let drivers be deactivated and activated even if the bootloader is already running, which is necessary to support reusing the current state of the board within a labgrid client state transition.

In my opionion testing a watchdog reset belongs to the testcase and using labgrid functionality for this is not the correct approach. What you want to do for watchdog testing anway is to set a global variable inside the bootloader, deactivate the driver, wait for the watchdog reset and reactivate the driver. Than the test can check whether the variable is not there any longer and this is a new running instance of the bootloader and even check the reset reason if this is possible with the board.

I don't have a solution for the case where you have a manual override on the power switch. Can this be queried by software? I think this is more of an organizational problem than something that can be solved with a technical solution inside of labgrid.

Yes I agree. Would adding "boot_expression" to the driver again and adding a check for it to

labgrid/labgrid/driver/bareboxdriver.py

Lines 147 to 187 in ed4e12e

	expectations = [self.prompt, self.autoboot, "Password: ", TIMEOUT]
	while True:
	index, before, _, _ = self.console.expect(
	expectations,
	timeout=2
	)
	if index == 0:
	# we got a prompt. no need for any further action to activate
	# this driver.
	self._status = 1
	break
	elif index == 1:
	# we need to interrupt autoboot
	self.console.write(self.interrupt.encode('ASCII'))
	elif index == 2:
	# we need to enter the password
	if not self.password:
	raise Exception("Password entry needed but no password set")
	if password_entered:
	# we already sent the password, but got the pw prompt again
	raise Exception("Password was not correct")
	self.console.sendline(self.password)
	password_entered = True
	elif index == 3:
	# expect hit a timeout while waiting for a match
	if before == last_before:
	# we did not receive anything during the previous expect cycle
	# let's assume the target is idle and we can safely issue a
	# newline to check the state
	self.console.sendline("")
	if timeout.expired:
	raise TIMEOUT(
	f"Timeout of {self.login_timeout} seconds exceeded during waiting for login"
	)
	last_before = before

ok?
We can set the "boot_detected" flag there and use it in strategies and tests.

[jremmet]

@Emantor I added the flag to driver as discussed.

[Emantor]

please use an attr.ib for this as well.

[jremmet]

Ok, sure here because it makes this also an Argument. Added it and a note to configuration.rst

[Emantor]

please use an attr.ib for this as well.