prettier: re-format
Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.
Change-Id: I5a9a4baad65867173cddcd86872e33ab5fb29128
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
diff --git a/README.md b/README.md
index 35a69eb..7b2da0b 100644
--- a/README.md
+++ b/README.md
@@ -3,7 +3,8 @@
This document describes the OpenBmc software implementing the secure flash
update mechanism.
-The primary details are [here](https://github.com/openbmc/docs/blob/master/designs/firmware-update-via-blobs.md).
+The primary details are
+[here](https://github.com/openbmc/docs/blob/master/designs/firmware-update-via-blobs.md).
## Building and using the host-tool
@@ -16,7 +17,8 @@
#### Building libpciaccess
-Check out the [xorg-macros source](https://gitlab.freedesktop.org/xorg/util/macros).
+Check out the
+[xorg-macros source](https://gitlab.freedesktop.org/xorg/util/macros).
Then run these commands in the source directory.
@@ -25,7 +27,8 @@
make install
```
-Check out the [libpciaccess source](https://gitlab.freedesktop.org/xorg/lib/libpciaccess).
+Check out the
+[libpciaccess source](https://gitlab.freedesktop.org/xorg/lib/libpciaccess).
Then run these commands in the source directory.
@@ -37,7 +40,8 @@
#### Building ipmi-blob-tool
-Check out the [ipmi-blob-tool source](https://github.com/openbmc/ipmi-blob-tool).
+Check out the
+[ipmi-blob-tool source](https://github.com/openbmc/ipmi-blob-tool).
Then run these commands in the source directory.
@@ -88,7 +92,8 @@
#### Building burn_my_bmc (the host-tool)
-Check out the [phosphor-ipmi-flash source](https://github.com/openbmc/phosphor-ipmi-flash).
+Check out the
+[phosphor-ipmi-flash source](https://github.com/openbmc/phosphor-ipmi-flash).
Then run these commands in the source directory.
@@ -99,7 +104,7 @@
make install
```
-*NOTE:* When building from the OpenBMC SDK your configuration call will be:
+_NOTE:_ When building from the OpenBMC SDK your configuration call will be:
```
./configure --enable-oe-sdk --host "$(uname -m)" --disable-build-bmc-blob-handler AR=x86_64-openbmc-linux-gcc-ar RANLIB=x86_64-openbmc-linux-gcc-ranlib
@@ -111,16 +116,16 @@
The required parameters are:
- Parameter | Options | Meaning
------------ | -------- | -------
-`command` | `update` | The tool should try to update the BMC firmware.
-`interface` | `ipmibt`, `ipmilpc`, `ipmipci`, `ipminet`, `ipmipci-skip-bridge-disable` | The data transport mechanism, typically `ipmilpc`. The `ipmipci-skip-bridge-disable` is `ipmipci` but does not disable the bridge after.
-`image` | path | The BMC firmware image file (or tarball)
-`sig` | path | The path to a signature file to send to the BMC along with the image file.
-`type` | blob ending | The ending of the blob id. For instance `/flash/image` becomes a type of `image`.
+| Parameter | Options | Meaning |
+| ----------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| `command` | `update` | The tool should try to update the BMC firmware. |
+| `interface` | `ipmibt`, `ipmilpc`, `ipmipci`, `ipminet`, `ipmipci-skip-bridge-disable` | The data transport mechanism, typically `ipmilpc`. The `ipmipci-skip-bridge-disable` is `ipmipci` but does not disable the bridge after. |
+| `image` | path | The BMC firmware image file (or tarball) |
+| `sig` | path | The path to a signature file to send to the BMC along with the image file. |
+| `type` | blob ending | The ending of the blob id. For instance `/flash/image` becomes a type of `image`. |
If you're using an LPC data transfer mechanism, you'll need two additional
-parameters: `address` and `length`. These values indicate where on the host
+parameters: `address` and `length`. These values indicate where on the host
you've reserved memory to be used for the transfer window.
If you're using a net data transfer mechanism, you'll also need two additional
@@ -131,17 +136,16 @@
## Introduction
This supports three methods of providing the image to stage. You can send the
-file over IPMI packets, which is a very slow process. A 32-MiB image can take
-~3 hours to send via this method. This can be done in <1 minutes via the PCI or
-net bridge, or just a few minutes via LPC depending on the size of the mapped
-area.
+file over IPMI packets, which is a very slow process. A 32-MiB image can take ~3
+hours to send via this method. This can be done in <1 minutes via the PCI or net
+bridge, or just a few minutes via LPC depending on the size of the mapped area.
This is implemented as a phosphor blob handler.
The image must be signed via the production or development keys, the former
being required for production builds. The image itself and the image signature
-are separately sent to the BMC for verification. The verification package
-source is beyond the scope of this design.
+are separately sent to the BMC for verification. The verification package source
+is beyond the scope of this design.
Basically the IPMI OEM handler receives the image in one fashion or another and
then triggers the `verify_image` service. Then, the user polls until the result
@@ -159,126 +163,128 @@
### Using UBI
-The staging file path can be controlled via software configuration. The image
-is assumed to be the tarball contents and is written into `/tmp/{tarball_name}.gz`
+The staging file path can be controlled via software configuration. The image is
+assumed to be the tarball contents and is written into `/tmp/{tarball_name}.gz`
TODO: Flesh out the UBI approach.
## Configuration
-To use `phosphor-ipmi-flash` a platform must provide a configuration. A
-platform can configure multiple interfaces, such as both lpc and pci. However,
-a platform should only configure either static layout updates, or ubi. If
-enabling lpc, the platform must specify either aspeed or nuvoton. The system
-also supports receiving BIOS updates.
+To use `phosphor-ipmi-flash` a platform must provide a configuration. A platform
+can configure multiple interfaces, such as both lpc and pci. However, a platform
+should only configure either static layout updates, or ubi. If enabling lpc, the
+platform must specify either aspeed or nuvoton. The system also supports
+receiving BIOS updates.
The following are the two primary configuration options, which control how the
update is treated.
-Option | Meaning
------------------------- | -------
-`--enable-static-layout` | Enable treating the update as a static layout update.
-`--enable-tarball-ubi` | Enable treating the update as a tarball for UBI update.
-`--enable-host-bios` | Enable receiving the update for a host bios update.
+| Option | Meaning |
+| ------------------------ | ------------------------------------------------------- |
+| `--enable-static-layout` | Enable treating the update as a static layout update. |
+| `--enable-tarball-ubi` | Enable treating the update as a tarball for UBI update. |
+| `--enable-host-bios` | Enable receiving the update for a host bios update. |
The following are configuration options for how the host and BMC are meant to
-transfer the data. By default, the data-in-IPMI mechanism is enabled.
+transfer the data. By default, the data-in-IPMI mechanism is enabled.
There are three configurable data transport mechanisms, either staging the bytes
via the LPC memory region, the PCI-to-AHB memory region, or sending over a
-network connection. Because there is only one `MAPPED_ADDRESS` variable at
-present, a platform should not configure LPC and P2A at the same time. The
+network connection. Because there is only one `MAPPED_ADDRESS` variable at
+present, a platform should not configure LPC and P2A at the same time. The
platform's device-tree may have the region locked to a specific driver
(lpc-aspeed-ctrl), preventing the region from other use.
-***NOTE:*** It will likely be possible to configure both LPC and P2A in the near
+**_NOTE:_** It will likely be possible to configure both LPC and P2A in the near
future.
-Variable | Default | Meaning
---------------------- | ------- | -------
-`MAPPED_ADDRESS` | 0 | The address used for mapping P2A or LPC into the BMC's memory-space.
+| Variable | Default | Meaning |
+| ---------------- | ------- | -------------------------------------------------------------------- |
+| `MAPPED_ADDRESS` | 0 | The address used for mapping P2A or LPC into the BMC's memory-space. |
If a platform enables p2a as the transport mechanism, a specific vendor must be
-selected via the following configuration option. Currently, only one is
+selected via the following configuration option. Currently, only one is
supported.
-Option | Meaning
------------------------| -------
-`--enable-aspeed-p2a` | Use with ASPEED parts.
+| Option | Meaning |
+| --------------------- | ---------------------- |
+| `--enable-aspeed-p2a` | Use with ASPEED parts. |
If a platform enables lpc as the transport mechanism, a specific vendor must be
-selected via the following configuration option. Currently, only two are
+selected via the following configuration option. Currently, only two are
supported.
-Option | Meaning
----------------------- | -------
-`--enable-aspeed-lpc` | Use with ASPEED parts.
-`--enable-nuvoton-lpc` | Use with Nuvoton parts.
+| Option | Meaning |
+| ---------------------- | ----------------------- |
+| `--enable-aspeed-lpc` | Use with ASPEED parts. |
+| `--enable-nuvoton-lpc` | Use with Nuvoton parts. |
A platform may also enable the network transport mechanism.
NOTE: This mechanism is only intended to be used in-band and not exposed
externally, as it doesn't implement any encryption or integrity verification.
-Option | Meaning
-----------------------| -------
-`--enable-net-bridge` | Enable net transport bridge
+| Option | Meaning |
+| --------------------- | --------------------------- |
+| `--enable-net-bridge` | Enable net transport bridge |
There are also options to control an optional clean up mechanism.
-Option | Meaning
-------------------------- | -------
-`--enable-cleanup-delete` | Provide a simple blob id that deletes artifacts.
+| Option | Meaning |
+| ------------------------- | ------------------------------------------------ |
+| `--enable-cleanup-delete` | Provide a simple blob id that deletes artifacts. |
If the update mechanism desired is simply a BMC reboot, a platform can just
enable that directly.
-Option | Meaning
------------------------- | -------
-`--enable-reboot-update` | Enable use of reboot update mechanism.
+| Option | Meaning |
+| ------------------------ | -------------------------------------- |
+| `--enable-reboot-update` | Enable use of reboot update mechanism. |
If you would like the update status to be tracked with a status file, this
option can be enabled. Note that `--enable-update-status` option and the above
`--enable-reboot-update` option cannot be enabled at the same time.
-Option | Meaning
------------------------- | -------
-`--enable-update-status` | Enable use of update status file.
+| Option | Meaning |
+| ------------------------ | --------------------------------- |
+| `--enable-update-status` | Enable use of update status file. |
-If you would like to use host memory access to update on a PPC platform, this configuration option needs to be enabled.
+If you would like to use host memory access to update on a PPC platform, this
+configuration option needs to be enabled.
-Option | Meaning
---------------- | -------
-`--enable-ppc` | Enable PPC host memory access.
+| Option | Meaning |
+| -------------- | ------------------------------ |
+| `--enable-ppc` | Enable PPC host memory access. |
### Internal Configuration Details
The following variables can be set to whatever you wish, however they have
usable default values.
-Variable | Default | Meaning
------------------------------ | -------------------------- | -------------------------------------------------------------------------
-`STATIC_HANDLER_STAGED_NAME` | `/run/initramfs/bmc-image` | The filename where to write the staged firmware image for static updates.
-`TARBALL_STAGED_NAME` | `/tmp/image-update.tar` | The filename where to write the UBI update tarball.
-`HASH_FILENAME` | `/tmp/bmc.sig` | The file to use for the hash provided.
-`PREPARATION_DBUS_SERVICE` | `phosphor-ipmi-flash-bmc-prepare.target` | The systemd target started when the host starts to send an update.
-`VERIFY_STATUS_FILENAME` | `/tmp/bmc.verify` | The file checked for the verification status.
-`VERIFY_DBUS_SERVICE` | `phosphor-ipmi-flash-bmc-verify.target` | The systemd target started for verification.
-`UPDATE_DBUS_SERVICE` | `phosphor-ipmi-flash-bmc-update.target` | The systemd target started for updating the BMC.
-`UPDATE_STATUS_FILENAME` | `/tmp/bmc.update` | The file checked for the update status.
-`BIOS_STAGED_NAME` | `/tmp/bios-image` | The file to use for staging the bios firmware update.
-`BIOS_VERIFY_STATUS_FILENAME` | `/tmp/bios.verify` | The file checked for the verification status.
-`PREPARATION_BIOS_TARGET` | `phosphor-ipmi-flash-bios-prepare.target` | The systemd target when the host starts to send an update.
-`VERIFY_BIOS_TARGET` | `phosphor-ipmi-flash-bios-verify.target` | The systemd target started for verification.
-`UPDATE_BIOS_TARGET` | `phosphor-ipmi-flash-bios-update.target` | The systemd target started for updating the BIOS.
+| Variable | Default | Meaning |
+| ----------------------------- | ----------------------------------------- | ------------------------------------------------------------------------- |
+| `STATIC_HANDLER_STAGED_NAME` | `/run/initramfs/bmc-image` | The filename where to write the staged firmware image for static updates. |
+| `TARBALL_STAGED_NAME` | `/tmp/image-update.tar` | The filename where to write the UBI update tarball. |
+| `HASH_FILENAME` | `/tmp/bmc.sig` | The file to use for the hash provided. |
+| `PREPARATION_DBUS_SERVICE` | `phosphor-ipmi-flash-bmc-prepare.target` | The systemd target started when the host starts to send an update. |
+| `VERIFY_STATUS_FILENAME` | `/tmp/bmc.verify` | The file checked for the verification status. |
+| `VERIFY_DBUS_SERVICE` | `phosphor-ipmi-flash-bmc-verify.target` | The systemd target started for verification. |
+| `UPDATE_DBUS_SERVICE` | `phosphor-ipmi-flash-bmc-update.target` | The systemd target started for updating the BMC. |
+| `UPDATE_STATUS_FILENAME` | `/tmp/bmc.update` | The file checked for the update status. |
+| `BIOS_STAGED_NAME` | `/tmp/bios-image` | The file to use for staging the bios firmware update. |
+| `BIOS_VERIFY_STATUS_FILENAME` | `/tmp/bios.verify` | The file checked for the verification status. |
+| `PREPARATION_BIOS_TARGET` | `phosphor-ipmi-flash-bios-prepare.target` | The systemd target when the host starts to send an update. |
+| `VERIFY_BIOS_TARGET` | `phosphor-ipmi-flash-bios-verify.target` | The systemd target started for verification. |
+| `UPDATE_BIOS_TARGET` | `phosphor-ipmi-flash-bios-update.target` | The systemd target started for updating the BIOS. |
## JSON Configuration
-Read the [details](bmc_json_config.md) of the json configuration. The json configurations are used to configure the BMC's flash handler behaviors.
+Read the [details](bmc_json_config.md) of the json configuration. The json
+configurations are used to configure the BMC's flash handler behaviors.
## Flash State Machine Details
[This document](ipmi_flash.md) describes the details of the state machine
-implemented and how different interactions with it will respond. This also
+implemented and how different interactions with it will respond. This also
describes how a host-side tool is expected to talk to it (triggering different
states and actions).
diff --git a/bmc/README.md b/bmc/README.md
index 261b539..4fbc49d 100644
--- a/bmc/README.md
+++ b/bmc/README.md
@@ -1,10 +1,12 @@
# Format of Config file
-This document gives details about the format of the config file useed by log, version and firmware handler. The config file is a .json file.
+This document gives details about the format of the config file useed by log,
+version and firmware handler. The config file is a .json file.
### Parameters
There are 3 important parameters in this config file
+
1. blob
2. handler
3. actions
@@ -35,13 +37,21 @@
```
#### blob
-This parameter defines the unique name of the blob. This parameter must be defined for each blob.
+
+This parameter defines the unique name of the blob. This parameter must be
+defined for each blob.
#### handler
-A blob must have a handler with a type. Currently only "file" type is supported. With file type, a path of the handler file must be provided.
+
+A blob must have a handler with a type. Currently only "file" type is supported.
+With file type, a path of the handler file must be provided.
#### actions
-"actions" define various steps to be performed and are required for each blob. These actions can be triggered from ipmi-blob commands. Currently there are 2 types of actions supported: `systemd` to invoke a systemd service, or `skip` to not perform any action.
+
+"actions" define various steps to be performed and are required for each blob.
+These actions can be triggered from ipmi-blob commands. Currently there are 2
+types of actions supported: `systemd` to invoke a systemd service, or `skip` to
+not perform any action.
### Workflow of log handler
@@ -65,10 +75,17 @@
}
```
-In this example the blob handler is the log file that will store the blackbox data from adm1266 and will be returned on BmcBlobRead.
+In this example the blob handler is the log file that will store the blackbox
+data from adm1266 and will be returned on BmcBlobRead.
-Here log_blob supports 2 actions. These actions are performed on the handler file.
+Here log_blob supports 2 actions. These actions are performed on the handler
+file.
-1. `open` : adm1266-read-blackbox-log@sink0.service gets launched on BmcBlobOpen command. This service should read the blackbox data from adm1266 and place the into blob handler file. This also enables BmcBlobSessionStat command to indicate that the blob is ready to read.
+1. `open` : adm1266-read-blackbox-log@sink0.service gets launched on BmcBlobOpen
+ command. This service should read the blackbox data from adm1266 and place
+ the into blob handler file. This also enables BmcBlobSessionStat command to
+ indicate that the blob is ready to read.
-2. `delete` : adm1266-clear-blackbox-data@sink0.service gets launched on BmcBlobDelete command. This service should delete the cached blackbox data in the handler file and erase the blackbox data from adm1266.
+2. `delete` : adm1266-clear-blackbox-data@sink0.service gets launched on
+ BmcBlobDelete command. This service should delete the cached blackbox data in
+ the handler file and erase the blackbox data from adm1266.
diff --git a/bmc_json_config.md b/bmc_json_config.md
index 31529ea..2c85638 100644
--- a/bmc_json_config.md
+++ b/bmc_json_config.md
@@ -6,9 +6,9 @@
There are three json configurations available by default:
-* config-bios.json
-* config-static-bmc-reboot.json
-* config-static-bmc.json
+- config-bios.json
+- config-static-bmc-reboot.json
+- config-static-bmc.json
Let's break them down, what they contain and what it means, and then how to
write your own. It's helpful to start here.
@@ -49,9 +49,9 @@
Beyond this, the flash handler configuration is a dictionary or object with
three fields.
-* `blob`
-* `handler`
-* `actions`
+- `blob`
+- `handler`
+- `actions`
### `blob`
@@ -67,7 +67,7 @@
The `handler` field expects to hold a dictionary or object with at least one
field.
-* `type`
+- `type`
The `type` field expects a string and will control what other parameters are
required. The type here refers to the handler for the incoming data associated
@@ -89,9 +89,9 @@
The actions are split into three fields:
-* `preparation`
-* `verification`
-* `update`
+- `preparation`
+- `verification`
+- `update`
The `preparation`, `verification`, and `update` fields expect a `type` field,
similarly to the `handler` field. This dictates what other parameters may be
@@ -196,7 +196,7 @@
The `file` handler type writes the bytes to a file path specified by the
required parameter `path`.
-* `path` - full file system path to where to write bytes.
+- `path` - full file system path to where to write bytes.
### Action Types
@@ -214,9 +214,9 @@
target. For verification and update operations this will track the status of the
systemd service to determine success or failure.
-* `unit` - required - string - the systemd unit to start.
-* `mode` - optional - string - default: replace - the mode for starting the
- service.
+- `unit` - required - string - the systemd unit to start.
+- `mode` - optional - string - default: replace - the mode for starting the
+ service.
#### `fileSystemdVerify` & `fileSystemdUpdate`
@@ -226,11 +226,11 @@
performing the action will want to update that file. NOTE: Now that the systemd
type action tracks unit status, that action is now preferred.
-* `path` - required - string - the full file system path to where one finds
- the status.
-* `unit` - required - string - the systemd unit to start
-* `mode` - optional - string - default: replace - the mode for starting the
- service.
+- `path` - required - string - the full file system path to where one finds the
+ status.
+- `unit` - required - string - the systemd unit to start
+- `mode` - optional - string - default: replace - the mode for starting the
+ service.
#### `reboot`
@@ -251,10 +251,10 @@
Your handler must implement:
-* `bool open(const std::string& path)`
-* `void close()`
-* `bool write(std::uint32_t offset, const std::vector<std::uint8_t>& data)`
-* `int getSize()`
+- `bool open(const std::string& path)`
+- `void close()`
+- `bool write(std::uint32_t offset, const std::vector<std::uint8_t>& data)`
+- `int getSize()`
The handler is meant to receive the bytes, and write the bytes.
@@ -269,9 +269,9 @@
Your action must implement:
-* `bool trigger()`
-* `void abort()`
-* `ActionStatus status()`
+- `bool trigger()`
+- `void abort()`
+- `ActionStatus status()`
The abort method is not a guarantee.
diff --git a/ipmi_flash.md b/ipmi_flash.md
index ef982d1..717404a 100644
--- a/ipmi_flash.md
+++ b/ipmi_flash.md
@@ -1,6 +1,6 @@
# BMC-side state machine details
-***ONLY ONE BLOB IS ALLOWED OPEN AT A TIME***
+**_ONLY ONE BLOB IS ALLOWED OPEN AT A TIME_**
To avoid excessive complications, there is a restriction that only one blob
within the firmware handler can be open at a time.
@@ -12,8 +12,8 @@
Opening the active image or hash always fails:
-* `open(/flash/active/image)` returns false -- file cannot be opened.
-* `open(/flash/active/hash)` returns false -- file cannot be opened.
+- `open(/flash/active/image)` returns false -- file cannot be opened.
+- `open(/flash/active/hash)` returns false -- file cannot be opened.
The two files are only present once their corresponding blob has been opened.
@@ -22,16 +22,16 @@
You can only open one file at a time, and some of the states exist only when a
file is open.
-State | fileOpen()
-:---------------------- | :---------
-`notYetStarted` | `false`
-`uploadInProgress` | `true`
-`verificationPending` | `false`
-`verificationStarted` | `true`
-`verificationCompleted` | `true`
-`updatePending` | `false`
-`updateStarted` | `true`
-`updatedCompleted` | `true`
+| State | fileOpen() |
+| :---------------------- | :--------- |
+| `notYetStarted` | `false` |
+| `uploadInProgress` | `true` |
+| `verificationPending` | `false` |
+| `verificationStarted` | `true` |
+| `verificationCompleted` | `true` |
+| `updatePending` | `false` |
+| `updateStarted` | `true` |
+| `updatedCompleted` | `true` |
# The states in the Firmware Handler State Machine
@@ -39,53 +39,53 @@
**The starting state.**
-* `open(/flash/image)`
-* `open(/flash/tarball)`
-* `open(/flash/hash)`
-* `open(/flash/verify)`
-* `open(/flash/update)`
+- `open(/flash/image)`
+- `open(/flash/tarball)`
+- `open(/flash/hash)`
+- `open(/flash/verify)`
+- `open(/flash/update)`
## `uploadInProgress`
**The BMC is expecting to receive bytes.**
-* `open(/flash/*)` returns false because `fileOpen() == true`
+- `open(/flash/*)` returns false because `fileOpen() == true`
-* `close(/flash/*)` triggers `state -> verificationPending`
+- `close(/flash/*)` triggers `state -> verificationPending`
-* `commit(/flash/*)` returns false
+- `commit(/flash/*)` returns false
## `verificationPending`
**The BMC is ready for verification or more bytes.**
-* `open(/flash/image)` triggers `state -> uploadInProgress`
-* `open(/flash/tarball)` triggers `state -> uploadInProgress`
-* `open(/flash/hash)` triggers `state -> uploadInProgress`
+- `open(/flash/image)` triggers `state -> uploadInProgress`
+- `open(/flash/tarball)` triggers `state -> uploadInProgress`
+- `open(/flash/hash)` triggers `state -> uploadInProgress`
-* `open(/flash/verify)`
+- `open(/flash/verify)`
-* `open(/flash/update)`
+- `open(/flash/update)`
-* `commit(/flash/verify)` `state -> verificationStarted`
+- `commit(/flash/verify)` `state -> verificationStarted`
## `verificationStarted`
**The verification process has started, no more writes allowed.**
-* `open(/flash/*)` returns false because `state == verificationStarted`
+- `open(/flash/*)` returns false because `state == verificationStarted`
-* `close(/flash/verify)` `state -> verificationCompleted`
+- `close(/flash/verify)` `state -> verificationCompleted`
## `verificationCompleted`
**The verification process has completed.**
-* `open(/flash/image)`
-* `open(/flash/tarball)`
-* `open(/flash/hash)`
-* `open(/flash/verify)`
-* `open(/flash/update)`
+- `open(/flash/image)`
+- `open(/flash/tarball)`
+- `open(/flash/hash)`
+- `open(/flash/verify)`
+- `open(/flash/update)`
## `updatePending`
@@ -95,7 +95,7 @@
**The update process has started.**
-* `open(/flash/*)`r eturns false because `fileOpen() == true`
+- `open(/flash/*)`r eturns false because `fileOpen() == true`
## `updatedCompleted`
@@ -109,23 +109,23 @@
by running the `stat()` command on their open session (either their session with
the `verifyBlobId` or the `updateBlobId`.
-Action | Before | After
-:------------------------- | :----: | :----------------:
-1. `getBlobList()` | NYS | NYS
-2. `stat(/flash/image)` | NYS | NYS
-3. `open(/flash/image)` | NYS | UIP
-4. `write(...)` | UIP | UIP
-5. `close(/flash/image)` | UIP | VP
-6. `open(/flash/hash)` | VP | UIP
-7. `write(...)` | UIP | UIP
-8. `close(/flash/hash)` | UIP | VP
-9. `open(/flash/verify)` | VP | VP
-10. `commit(...)` | VP | VS
-11. `sessionStat(...)` | VS | VS (if !completed)
-11. `sessionStat(...)` | VS | VC (if completed)
-12. `close(/flash/verify)` | VC | UP
-13. `open(/flash/update)` | UP | UP
-14. `commit(...)` | UP | US
-15. `sessionStat(...)` | US | US (if !completed)
-15. `sessionStat(...)` | US | UC (if completed)
-16. `close(/flash/update)` | UC | NYS
+| Action | Before | After |
+| :------------------------- | :----: | :----------------: |
+| 1. `getBlobList()` | NYS | NYS |
+| 2. `stat(/flash/image)` | NYS | NYS |
+| 3. `open(/flash/image)` | NYS | UIP |
+| 4. `write(...)` | UIP | UIP |
+| 5. `close(/flash/image)` | UIP | VP |
+| 6. `open(/flash/hash)` | VP | UIP |
+| 7. `write(...)` | UIP | UIP |
+| 8. `close(/flash/hash)` | UIP | VP |
+| 9. `open(/flash/verify)` | VP | VP |
+| 10. `commit(...)` | VP | VS |
+| 11. `sessionStat(...)` | VS | VS (if !completed) |
+| 11. `sessionStat(...)` | VS | VC (if completed) |
+| 12. `close(/flash/verify)` | VC | UP |
+| 13. `open(/flash/update)` | UP | UP |
+| 14. `commit(...)` | UP | US |
+| 15. `sessionStat(...)` | US | US (if !completed) |
+| 15. `sessionStat(...)` | US | UC (if completed) |
+| 16. `close(/flash/update)` | UC | NYS |