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 missing coverage. Please review.

Project coverage is 55.9%. Comparing base (02fa1ef) to head (670e0ca).

✅ All tests successful. No failed tests found.

Files with missing lines	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    55.8%   55.9%   +0.1%     
========================================
  Files         170     170             
  Lines       13377   13389     +12     
========================================
+ Hits         7469    7496     +27     
+ Misses       5908    5893     -15     

Flag	Coverage Δ
3.10	55.9% <88.8%> (+0.1%)	⬆️
3.11	55.9% <88.8%> (+0.1%)	⬆️
3.12	55.9% <88.8%> (+0.1%)	⬆️
3.13	55.9% <88.8%> (+0.1%)	⬆️
3.9	56.0% <88.8%> (+0.1%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

[jremmet]

@Emantor gently ping

[Emantor]

This should be instance_of(bool). We also probably want to set this to on_setattr=None, so users can't change this attribute.

There seems to be no way to protect this from external modification vs internal modification with the on_setattr() call.

[jremmet]

I fixed the type.
With attr I also found no way to protect it. Not sure if it worth _boot_detected and get_boot_detected like done with _status