docs/designs/firmware-update-via-blobs.md

66 Sending the firmware image over the BLOB protocol will be done via routing the
80 The BLOB protocol allows a handler to specify a list of blob ids. This list will
83 identify the mechanism selected by the client-side. The stat command will return
86 The blob ids for the mechanisms will be as follows:
94 The flash handler will determine what commands it should expect to receive and
95 responses it will return given the blob opened, based on the flags provided to
98 The flash handler will only allow one of the above blobs to be opened for a
109 The flash handler will only allow one open file at a time, such that if the host
113 There is only one hash "file" mechanism. The exact hash used will only be
114 important to your verification service. The value provided will be written to a
124 the BmcBlobOpen command will fail until both the hash and image file are closed.
160 BMC. The cleanup blob will delete a list of files. The cleanup blob has no state
162 process. The host tool will only use it on failure cases. Any other tool
176 Similarly to the OEM IPMI Flash protocol, the flash image will be staged in a
184 The update mechanism will expect a specific sequence of commands depending on
249 closing, the cache will be flushed and any staged pieces deleted.
251 The image itself, in legacy (static layout) mode will be placed and named in
252 such a way that it will disappear if the BMC reboots. In the UBI case, the file
253 will be stored in `/tmp` and deleted accordingly.
260 The update mechanism will implement the Blob primitives as follows.
288 Once opened a new file will appear in the blob_id list (for both the image and
289 hash) indicating they are in progress. The name will be `flash/active/image` and
292 will.
299 This will initially not perform any function and will return success with 0
304 The write command's contents will depend on the transport mechanism. This
338 will happen at present. It will return a no-op success.
340 If this command is called on the session for the hash image, nothing will happen
341 at present. It will return a no-op success.
348 When this is started, only the BmcBlobSessionStat command will respond. Details
356 If the `verify_image.service` returned success, closing the verify file will
360 staging position. A BMC warm reset command will initiate the firmware update
363 If the image verification fails, it will automatically delete any files
366 **_Note:_** During development testing, a developer will want to upload files
367 that are not signed. Therefore, an additional bit will be added to the flags to
382 Blob stat on a blob_id (not SessionStat) will return the capabilities of the
388     /* This will have the bits set from the FirmwareUpdateFlags enum. */
474 The write meta command's blob will be this structure:
500 Where possible (nearly everywhere), mockable interfaces will be used such that
510 verification step will return failure and the files will be deleted from the BMC
516 a valid signature. The expected result is that the verification step will return