Files
OpenCellular/chip
Mary Ruthven 7a756993ea g: use reset_count to determine system_rollback_detected
Use the reset count to determine if there was a rollback in
system_rollback_detected. Before system.c was checking if the inactive
header was newer than active one to determine if the system rolled back.
This wasn't accurate. Cr50 rollback isn't the only reason why a newer
image may be rejected. The image may have been rejected because it
wasn't signed correctly or it's corrupted, so we shouldn't be using the
newer header as a sign that there was a rollback.

The reset count is cleared when the AP boots. This means the rollback
state will be lost the first deep sleep resume after the AP has booted.

BUG=none
BRANCH=cr50
TEST=manual
	flash a dbg image with version 4.0 that has two infomap bits
	erased.

	Check sysinfo to see that it doesn't think cr50 rolledback

	flash a dbg image with version 4.4 that has one infomap bit
	erased.

	Make sure that 4.4 image is rejected and cr50 is still running
	4.0

	Check sysinfo to see that it doesn't think cr50 rolledback

	flash a dbg image with version 4.4 that has two infomap bits
	erased.

	Make sure cr50 jumps to that image

	rollback to the 4.0 image

	Make sure sysinfo shows there was a rollback.

	Boot the system

	Make sure sysinfo shows there was a rollback.

Change-Id: I85f2e001ffed9e2185a276dfa916e9b0a05ff7bf
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/985029
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2018-03-30 16:53:00 -07:00
..
2018-01-31 05:58:03 -08:00
2018-03-26 17:03:27 -07:00
2018-03-26 17:03:27 -07:00
2017-09-07 15:01:05 -07:00