designs: firmware_update_via_blobs: style tweak for blobs

Wrap all blob ids in ticks to make them monospace consistently
throughout the design.

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I93ce11ff710a229278025cdfd6030dffe663f84e
diff --git a/designs/firmware_update_via_blobs.md b/designs/firmware_update_via_blobs.md
index c49a716..c7cc9ea 100644
--- a/designs/firmware_update_via_blobs.md
+++ b/designs/firmware_update_via_blobs.md
@@ -88,10 +88,10 @@
 
 The blob ids for the mechanisms will be as follows:
 
-Flash Blob Id  | Type
--------------- | -------------
-/flash/image   | Static Layout
-/flash/tarball | UBI
+Flash Blob Id    | Type
+---------------- | -------------
+`/flash/image`   | Static Layout
+`/flash/tarball` | UBI
 
 The flash handler will determine what commands it should expect to receive and
 responses it will return given the blob opened, based on the flags provided to
@@ -99,9 +99,9 @@
 
 The following blob ids are defined for storing the hash for the image:
 
-Hash Blob   | Id Mechanism
------------ | --------------------
-/flash/hash | Static Layout or UBI
+Hash Blob     | Id Mechanism
+------------- | --------------------
+`/flash/hash` | Static Layout or UBI
 
 The flash handler will only allow one open file at a time, such that if the host
 attempts to send a firmware image down over IPMI BlockTransfer, it won't allow
@@ -121,9 +121,9 @@
 the BmcBlobOpen command will fail until both the hash and image file are closed.
 Further on the ideal command sequence below.
 
-Trigger Blob  | Note
-------------- | ------------------------
-/flash/verify | Verify Trigger Mechanism
+Trigger Blob    | Note
+--------------- | ------------------------
+`/flash/verify` | Verify Trigger Mechanism
 
 When the verification file is closed, if verification was completed
 successfully, it'll add an update blob id, defined below.
@@ -132,16 +132,16 @@
 
 #### Update Blob
 
-The update blob id is available once /flash/verify is closed with a valid image
+The update blob id is available once `/flash/verify` is closed with a valid image
 or tarball. The update blob needs to be opened and commit() called on that blob
 id to trigger the update mechanism.
 
 The update process can be checked periodically by calling stat() on the update
 blob id.
 
-Update Blob   | Note
-------------- | ------------------------
-/flash/update | Trigger Update Mechanism
+Update Blob     | Note
+--------------- | ------------------------
+`/flash/update` | Trigger Update Mechanism
 
 The update process used is not defined by this design.
 
@@ -163,14 +163,14 @@
 1.  Open (for Image or tarball)
 1.  Write
 1.  Close
-1.  Open (/flash/hash)
+1.  Open (`/flash/hash`)
 1.  Write
 1.  Close
-1.  Open (/flash/verify)
+1.  Open (`/flash/verify`)
 1.  Commit
 1.  SessionStat (to read back verification status)
 1.  Close
-1.  Open (/flash/update)
+1.  Open (`/flash/update`)
 1.  Commit
 1.  SessionStat (to read back update status)
 1.  Close
@@ -181,15 +181,15 @@
 1.  SessionStat (P2A Region for P2A mapping)
 1.  Write
 1.  Close
-1.  Open (/flash/hash)
+1.  Open (`/flash/hash`)
 1.  SessionStat (P2A Region)
 1.  Write
 1.  Close
-1.  Open (/flash/verify)
+1.  Open (`/flash/verify`)
 1.  Commit
 1.  SessionStat (to read back verification status)
 1.  Close
-1.  Open (/flash/update)
+1.  Open (`/flash/update`)
 1.  Commit
 1.  SessionStat (to read back update status)
 1.  Close
@@ -201,16 +201,16 @@
 1.  SessionStat (verify the contents from the above)
 1.  Write
 1.  Close
-1.  Open (/flash/hash)
+1.  Open (`/flash/hash`)
 1.  WriteMeta (LPC Region)
 1.  SessionStat (verify LPC config)
 1.  Write
 1.  Close
-1.  Open (/flash/verify)
+1.  Open (`/flash/verify`)
 1.  Commit
 1.  SessionStat (to read back verification status)
 1.  Close
-1.  Open (/flash/update)
+1.  Open (`/flash/update`)
 1.  Commit
 1.  SessionStat (to read back update status)
 1.  Close