usb_updater: move to protocol version 4

Trying to use usb_updater in the upstart script made its shortcomings
very obvious: it is difficult to tell if the cr50 needs to have both
RO and RW updated, and if so - if it is even capable of updating RW.

Also, it is not clear that the target should erase its backup sections
as soon as it receives the transfer originating PDU. It is not known
in advance if the host has a newer RW section, of if the host is even
going to transfer the RO section.

These issues are addressed by version 4 of the image transfer
protocol.

The target now reports versions of its currently active RO and RW
sections back to the host. The host compares versions running on the
target with the versions retrieved from the image prepared for the
update and decides which sections, if any, need to be transferred.

The host also takes into account protocol version currently running by
the target's RW: versions below 3 do not allow RO updates.

In the development environment USB transfer ends with the target
reset. This is not desirable when the update is happening on a
Chromebook running production code. Also, in the development
environment there could exist multiple versions of the image with the
same signer header version fields, with only difference in the
timestamp. We want to be able to update using these images in
development environment, but in production we want to rely to the
header version fields.

These two mode (dev versus production) are now controlled by the
-u/--upstart command line flag.

The updater now can return four different exit values:

  - 0 means that the update was not required, the device is already
    running the current code.

  - 1 means update was completed, the target must be reset for the
    update to kick in.

  - 2 means that the RW transfer was completed, but the RO transfer
    could bot be attempted, because the target is running an early
    protocol version and is not capable of the RO updates.

    This exit value is the indicator that the utility needs to be run
    again after target restated, so that the new RW version can accept
    an RO update.

  - 3 means the update failed due to some internal error.

BRANCH=none
BUG=chrome-os-partner:49954
TEST=updates of targets running earlier protocol version still work
     fine.

Change-Id: Ia56f63072eaf88dcdefebf621b7341535748c7d7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374759
Reviewed-by: Bill Richardson <wfrichar@chromium.org>

2 files changed, 28 insertions, 13 deletions

diff --git a/chip/g/upgrade_fw.c b/chip/g/upgrade_fw.c
index 299c355e79..714db3abf5 100644
--- a/chip/g/upgrade_fw.c
+++ b/chip/g/upgrade_fw.c
@@ -170,10 +170,10 @@ void fw_upgrade_command_handler(void *body,
 			return;
 		}
 
-		rpdu->vers3.backup_ro_offset =
+		rpdu->backup_ro_offset =
 			htobe32(valid_sections.ro_base_offset);
 
-		rpdu->vers3.backup_rw_offset =
+		rpdu->backup_rw_offset =
 			htobe32(valid_sections.rw_base_offset);
 
 		return;
diff --git a/chip/g/upgrade_fw.h b/chip/g/upgrade_fw.h
index 19aa5d9e5c..8eca3761b6 100644
--- a/chip/g/upgrade_fw.h
+++ b/chip/g/upgrade_fw.h
@@ -28,13 +28,11 @@
  * contains no data and is destined to offset 0. Receiving such a frame
  * signals the CR50 that the host intends to transfer a new image.
  *
- * Version 3 connection establishment response is 16 bytes in size, all values
- * in network byte order. The first 4 bytes are the error code (if any), the
- * second 4 bytes are the protocol version (set to 3) and then 4 byte offset
- * of the RO section followed by the 4 byte offset of the RW section.
+ * The connection establishment response is described by the
+ * first_response_pdu structure below.
  */
 
-#define UPGRADE_PROTOCOL_VERSION 3
+#define UPGRADE_PROTOCOL_VERSION 4
 
 /* This is the format of the update frame header. */
 struct upgrade_command {
@@ -63,6 +61,19 @@ struct update_frame_header {
 };
 
 /*
+ * A convenience structure which allows to group together various revision
+ * fields of the header created by the signer.
+ *
+ * These fields are compared when deciding if versions of two images are the
+ * same or when deciding which one of the available images to run.
+ */
+struct signed_header_version {
+	uint32_t minor;
+	uint32_t major;
+	uint32_t epoch;
+};
+
+/*
  * Response to the connection establishment request.
  *
  * When responding to the very first packet of the upgrade sequence, the
@@ -84,13 +95,17 @@ struct update_frame_header {
  */
 struct first_response_pdu {
 	uint32_t return_value;
+
+	/* The below fields are present in versions 2 and up. */
 	uint32_t protocol_version;
-	union {
-		struct {
-			uint32_t  backup_ro_offset;
-			uint32_t  backup_rw_offset;
-		} vers3;
-	};
+
+	/* The below fields are present in versions 3 and up. */
+	uint32_t  backup_ro_offset;
+	uint32_t  backup_rw_offset;
+
+	/* The below fields are present in versions 4 and up. */
+	/* Versions of the currently active RO and RW sections. */
+	struct signed_header_version shv[2];
 };
 
 /* TODO: Handle this in upgrade_fw.c, not usb_upgrade.c */