firmware_handler: change state with verify results
Each time stat() is called during verification, it'll check the state of
the verification process. When that process finishes, good or bad, it
updates the overall firmware state and sets the blob flags accordingly.
Note: What happens upon failure is not currently well-defined, as there
isn't a clear path to reset everything yet. Deleting the blobs is
likely the path forward given the design. The state machine diagrams
will be added to the documentation so that host tool software will know
what to do.
Tested: Not yet tested.
Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I7f0008e525920b40895d66a68af091adf3b300e3
diff --git a/firmware_handler.cpp b/firmware_handler.cpp
index a07ddbb..d8ddf8d 100644
--- a/firmware_handler.cpp
+++ b/firmware_handler.cpp
@@ -251,11 +251,6 @@
return false;
}
- /* The blobState here relates to an active sesion, so we should return the
- * flags used to open this session.
- */
- meta->blobState = item->second->flags;
-
/* The size here refers to the size of the file -- of something analagous.
*/
meta->size = (item->second->imageHandler)
@@ -270,12 +265,35 @@
*/
if (item->second->activePath == verifyBlobID)
{
- meta->metadata.push_back(
- static_cast<std::uint8_t>(checkVerificationState()));
+ auto value = checkVerificationState();
- return true;
+ meta->metadata.push_back(static_cast<std::uint8_t>(value));
+
+ /* Change the firmware handler's state and the blob's stat value
+ * depending.
+ */
+ if (value == VerifyCheckResponses::success ||
+ value == VerifyCheckResponses::failed)
+ {
+ state = UpdateState::verificationCompleted;
+ item->second->flags &= ~StateFlags::committing;
+
+ if (value == VerifyCheckResponses::success)
+ {
+ item->second->flags |= StateFlags::committed;
+ }
+ else
+ {
+ item->second->flags |= StateFlags::commit_error;
+ }
+ }
}
+ /* The blobState here relates to an active sesion, so we should return the
+ * flags used to open this session.
+ */
+ meta->blobState = item->second->flags;
+
/* The metadata blob returned comes from the data handler... it's used for
* instance, in P2A bridging to get required information about the mapping,
* and is the "opposite" of the lpc writemeta requirement.