diff --git a/Documentation/mbox_protocol.md b/Documentation/mbox_protocol.md
deleted file mode 100644
index b60f336..0000000
--- a/Documentation/mbox_protocol.md
+++ /dev/null
@@ -1,780 +0,0 @@
-Copyright 2017,2018 IBM
-
-Licensed under the Apache License, Version 2.0 (the "License");
-you may not use this file except in compliance with the License.
-You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-
-## Intro
-
-This document describes a protocol for host to BMC communication via the
-mailbox registers present on the Aspeed 2400 and 2500 chips.
-This protocol is specifically designed to allow a host to request and manage
-access to a flash device(s) with the specifics of how the host is required to
-control this described below.
-
-## Version
-
-Version specific protocol functionalities are represented by the version number
-in brackets next to the definition of the functionality. (e.g. (V2) for version
-2 specific funtionality). All version specific functionality must also be
-implemented by proceeding versions up to and not including the version a command
-was removed.
-
-## Problem Overview
-
-"mbox" is the name we use to represent a protocol we have established between
-the host and the BMC via the Aspeed mailbox registers. This protocol is used
-for the host to control access to the flash device(s).
-
-Prior to the mbox protocol, the host uses a backdoor into the BMC address space
-(the iLPC-to-AHB bridge) to directly manipulate the BMCs own flash controller.
-
-This is not sustainable for a number of reasons. The main ones are:
-
-1. Every piece of the host software stack that needs flash access (HostBoot,
-   OCC, OPAL, ...) has to have a complete driver for the flash controller,
-   update it on each BMC generation, have all the quirks for all the flash
-   chips supported etc... We have 3 copies on the host already in addition to
-   the one in the BMC itself.
-
-2. There are serious issues of access conflicts to that controller between the
-   host and the BMC.
-
-3. It's very hard to support "BMC reboots" when doing that
-
-4. It's slow
-
-5. Last but probably most important, having that backdoor open is a security
-   risk. It means the host can access any address on the BMC internal bus and
-   implant malware in the BMC itself. So if the host is a "bare metal" shared
-   system in some kind of data center, not only the host flash needs to be
-   reflashed when switching from one customer to another, but the entire BMC
-   flash too as nothing can be trusted. So we want to disable it.
-
-To address all these, we have implemented a new mechanism that we call mbox.
-
-When using this mechanism, the BMC is solely responsible for directly accessing
-the flash controller. All flash erase and write operations are performed by the
-BMC and the BMC only. (We can allow direct reads from flash under some
-circumstances but we tend to prefer going via memory).
-
-The host uses the mailbox registers to send "commands" to the BMC, which
-responds via the same mechanism. Those commands allow the host to control a
-"window" (which is the LPC -> AHB FW space mapping) that is either a read
-window or a write window onto the flash.
-
-When set for writing, the BMC makes the window point to a chunk of RAM instead.
-When the host "commits" a change (via MBOX), then the BMC can perform the
-actual flashing from the data in the RAM window.
-
-The idea is to have the LPC FW space be routed to an active "window".  That
-window can be a read or a write window. The commands allow to control which
-window and which offset into the flash it maps.
-
-* A read window can be a direct window to the flash controller space (ie.
-  0x3000\_0000) or it can be a window to a RAM image of a flash. It doesn't have
-  to be the full size of the flash per protocol (commands can be used to "slide"
-  it to various parts of the flash) but if it's set to map the actual flash
-  controller space at 0x3000\_0000, it's probably simpler to make it the full
-  flash. The host makes no assumption, it's your choice what to provide. The
-  simplest implementation is to just route to the flash read/only.
-
-* A write window has to be a chunk of BMC memory. The minimum size is not
-  defined in the spec, but it should be at least one block (4k for now but it
-  should support larger block sizes in the future). When the BMC receive the
-  command to map the write window at a given offset of the flash, the BMC should
-  copy that portion of the flash into a reserved memory buffer, and modify the
-  LPC mapping to point to that buffer.
-
-The host can then write to that window directly (updating the BMC memory) and
-send a command to "commit" those updates to flash.
-
-Finally, there is a `RESET_STATE`. It's the state in which the bootloader in the
-SEEPROM of the POWER9 chip will find what it needs to load HostBoot. The
-details are still being ironed out: either mapping the full flash read only or
-reset to a "window" that is either at the bottom or top of the flash. The
-current implementation resets to point to the full flash.
-
-## Where is the code?
-
-The mbox userspace is available [on GitHub](https://github.com/openbmc/mboxbridge)
-This is Apache licensed but we are keen to see any enhancements you may have.
-
-The kernel driver is still in the process of being upstreamed but can be found
-in the OpenBMC Linux kernel staging tree:
-
-https://github.com/openbmc/linux/commit/85770a7d1caa6a1fa1a291c33dfe46e05755a2ef
-
-## Building
-
-The Autotools of this requires the autoconf-archive package for your
-system
-
-## The Hardware
-
-The Aspeed mailbox consists of 16 (8 bit) data registers see Layout for their
-use. Mailbox interrupt enabling, masking and triggering is done using a pair
-of control registers, one accessible by the host the other by the BMC.
-Interrupts can also be raised per write to each data register, for BMC and
-host. Write triggered interrupts are configured using two 8 bit registers where
-each bit represents a data register and if an interrupt should fire on write.
-Two 8 bit registers are present to act as a mask for write triggered
-interrupts.
-
-### Layout
-
-```
-Byte 0: COMMAND
-Byte 1: Sequence
-Byte 2-12: Arguments
-Byte 13: Response code
-Byte 14: Host controlled status reg
-Byte 15: BMC controlled status reg
-```
-
-Note: when the BMC is writing a response to the mbox registers (as described
-above), the "Response Code" (Register 13) must be the last register written to.
-Writing register 13 will trigger an interrupt to the host indicating a complete
-response has been written. Triggering the interrupt by writing register 13
-prior to completing the response may lead to a data race, and must, therefore,
-be avoided.
-
-## Low Level Protocol Flow
-
-What we essentially have is a set of registers which either the host or BMC can
-write to in order to communicate to the other which will respond in some way.
-There are 3 basic types of communication.
-
-1. Commands sent from the Host to the BMC
-2. Responses sent from the BMC to the Host in response to commands
-3. Asynchronous events raised by the BMC
-
-### General Use
-
-Messages usually originate from the host to the BMC. There are special
-cases for a back channel for the BMC to pass new information to the
-host which will be discussed later.
-
-To initiate a request the host must set a command code (see Commands) into
-mailbox data register 0, and generate a sequence number (see Sequence Numbers)
-to write to mailbox register data 1. After these two values, any
-command-specific data should be written (see Layout). The host must then
-generate an interrupt to the BMC by using bit 0 of its control register and
-wait for an interrupt on the response register.  Generating an interrupt
-automatically sets bit 7 of the corresponding control register. This bit can be
-used to poll for messages.
-
-On receiving an interrupt (or polling on bit 7 of its Control
-Register) the BMC should read the message from the general registers
-of the mailbox and perform the necessary action before responding. On
-responding the BMC must ensure that the sequence number is the same as
-the one in the request from the host. The BMC must also ensure that
-mailbox data register 13 is a valid response code (see Responses). The
-BMC should then use its control register to generate an interrupt for
-the host to notify it of a response.
-
-### Asynchronous BMC to Host Events
-
-BMC to host communication is also possible for notification of events
-from the BMC. This requires that the host have interrupts enabled on
-mailbox data register 15 (or otherwise poll on bit 7 of mailbox status
-register 1). On receiving such a notification the host should read
-mailbox data register 15 to determine the event code which was set by the
-BMC (see BMC Event notifications in Commands for detail). Events which are
-defined as being able to be acknowledged by the host must be with a
-BMC_EVENT_ACK command.
-
-## High Level Protocol Flow
-
-When a host wants to communicate with the BMC via the mbox protocol the first
-thing it should do it call MBOX_GET_INFO in order to establish the protocol
-version which each understands. Before this, the only other commands which are
-allowed are RESET_STATE and BMC_EVENT_ACK.
-
-After this, the host can open and close windows with the CREATE_READ_WINDOW,
-CREATE_WRITE_WINDOW and CLOSE_WINDOW commands. Creating a window is how the
-host requests access to a section of flash. It is worth noting that the host
-can only ever have one window that it is accessing at a time - hence forth
-referred to as the active window.
-
-When the active window is a write window the host can perform MARK_WRITE_DIRTY,
-MARK_WRITE_ERASED and WRITE_FLUSH commands to identify changed blocks and
-control when the changed blocks are written to flash.
-
-Independently, and at any point not during an existing mbox command
-transaction, the BMC may raise asynchronous events with the host to
-communicate a change in state.
-
-### Version Negotiation
-
-Given that a majority of command and response arguments are specified as a
-multiple of block size it is necessary for the host and BMC to agree on a
-protocol version as this determines the block size. In V1 it is hard coded at
-4K, in V2 the BMC chooses and in V3 the host is allowed to request a specific
-block size with the actual size chosen communicated back to the host as a
-response argument to `MBOX_GET_INFO`. Thus the host must always call
-`MBOX_GET_INFO` before any other command which specifies an argument in block
-size.
-
-When invoking `MBOX_GET_INFO` the host must provide the BMC its highest
-supported version of the protocol. The BMC must respond with a protocol version
-less than or equal to that requested by the host, or in the event that there is
-no such value, an error code. In the event that an error is returned the host
-must not continue to communicate with the BMC. Otherwise, the protocol version
-returned by the BMC is the agreed protocol version for all further
-communication. The host may at a future point request a change in protocol
-version by issuing a subsequent `MBOX_GET_INFO` command.
-
-### Window Management
-
-In order to access flash contents, the host must request a window be opened at
-the flash offset it would like to access with the CREATE_{READ,WRITE}_WINDOW
-commands. The host may give a hint as to how much data it would like to access
-or otherwise set this argument to zero. The BMC must respond with the LPC bus
-address to access this window and the window size. The host must not access
-past the end of the active window. On returning success to either of the create
-window commands the BMC must guarantee that the window provided contains data
-which correctly represents the state of flash at the time the response is given.
-
-There is only ever one active window which is the window created by the most
-recent CREATE_READ_WINDOW or CREATE_WRITE_WINDOW call which succeeded. Even
-though there are two types of windows there can still only be one active window
-irrespective of type. A host must not write to a read window. A host may read
-from a write window and the BMC must guarantee that the window reflects what
-the host has written there.
-
-A window can be closed by calling CLOSE_WINDOW in which case there is no active
-window and the host must not access the LPC window after it has been closed.
-If the host closes an active write window then the BMC must perform an
-implicit flush. If the host tries to open a new window with an already active
-window then the active window is closed (and implicitly flushed if it was a
-write window). If the new window is successfully opened then it is the new
-active window, if the command fails then there is no active window and the
-previously active window must no longer be accessed.
-
-The host must not access an LPC address other than that which is contained by
-the active window. The host must not use write management functions (see below)
-if the active window is a read window or if there is no active window.
-
-### Write Management
-
-The BMC has no method for intercepting writes that occur over the LPC bus. Thus
-the host must explicitly notify the BMC of where and when a write has
-occurred. The host must use the MARK_WRITE_DIRTY command to tell the BMC where
-within the write window it has modified. The host may also use the
-MARK_WRITE_ERASED command to erase large parts of the active window without the
-need to write 0xFF. The BMC must ensure that if the host
-reads from an area it has erased that the read values are 0xFF. Any part of the
-active window marked dirty/erased is only marked for the lifetime of the current
-active write window and does not persist if the active window is closed either
-implicitly or explicitly by the host or the BMC. The BMC may at any time
-or must on a call to WRITE_FLUSH flush the changes which it has been notified
-of back to the flash, at which point the dirty or erased marking is cleared
-for the active window. The host must not assume that any changes have been
-written to flash unless an explicit flush call was successful, a close of an
-active write window was successful or a create window command with an active
-write window was successful - otherwise consistency between the flash and memory
-contents cannot be guaranteed.
-
-The host is not required to perform an erase before a write command and the
-BMC must ensure that a write performs as expected - that is if an erase is
-required before a write then the BMC must perform this itself (unless the
-no_erase flag is set in the MARK_WRITE_DIRTY command in which case the BMC will
-blindly write without a prior erase (V3)).
-
-The host may lock an area of flash using the MARK_LOCKED command. Any attempt
-to mark dirty or erased this area of flash must fail with the LOCKED_ERROR
-response code. The host may open a write window which contains a locked area
-of flash however changes to a locked area of flash must never be written back
-to the backing data source (i.e. that area of flash must be treated as read
-only with respect to the backing store at all times). An attempt to lock an area
-of flash which is not clean in the current window must fail with PARAM_ERROR.
-Locked flash regions must persist across a BMC reboot or daemon restart. It is
-only possible to clear the lock state through a clear_locked dbus command. (V3)
-
-### BMC Events
-
-The BMC can raise events with the host asynchronously to communicate to the
-host a change in state which it should take notice of. The host must (if
-possible for the given event) acknowledge it to inform the BMC it has been
-received.
-
-If the BMC raises a BMC Reboot event then the host must renegotiate the
-protocol version so that both the BMC and the host agree on the block size.
-A BMC Reboot event implies a BMC Windows Reset event.
-If the BMC raises a BMC Windows Reset event then the host must
-assume that there is no longer an active window - that is if there was an
-active window it has been closed by the BMC and if it was a write window
-then the host must not assume that it was flushed unless a previous explicit
-flush call was successful.
-
-The BMC may at some points require access to the flash and the BMC daemon must
-set the BMC Flash Control Lost event when the BMC is accessing the flash behind
-the BMC daemons back. When this event is set the host must assume that the
-contents of the active window could be inconsistent with the contents of flash.
-
-## Protocol Definition
-
-### Commands
-
-```
-RESET_STATE          0x01
-GET_MBOX_INFO        0x02
-GET_FLASH_INFO       0x03
-CREATE_READ_WINDOW   0x04
-CLOSE_WINDOW         0x05
-CREATE_WRITE_WINDOW  0x06
-MARK_WRITE_DIRTY     0x07
-WRITE_FLUSH          0x08
-BMC_EVENT_ACK        0x09
-MARK_WRITE_ERASED    0x0a	(V2)
-GET_FLASH_NAME       0x0b	(V3)
-MARK_LOCKED          0x0c	(V3)
-```
-
-### Responses
-
-```
-SUCCESS		1
-PARAM_ERROR	2
-WRITE_ERROR	3
-SYSTEM_ERROR	4
-TIMEOUT		5
-BUSY		6	(V2)
-WINDOW_ERROR	7	(V2)
-SEQ_ERROR	8	(V2)
-LOCKED_ERROR	9	(V3)
-```
-
-### Sequence Numbers
-
-Sequence numbers are included in messages for correlation of commands and
-responses. V1, V2 and V3 of the protocol permit either zero or one commands to
-be in progress (yet to receive a response).
-
-For generality, the host must generate a sequence number that is unique with
-respect to the previous command (one that has received a response) and any
-in-progress commands. Sequence numbers meeting this requirement are considered
-valid. The BMC's response to a command must contain the same sequence number
-issued by the host as found in the relevant command.
-
-Sequence numbers may be reused in accordance with the constraints outlined
-above. However, it is not an error if the BMC receives a `GET_MBOX_INFO` with an
-invalid sequence number. For all other cases, the BMC must respond with
-`SEQ_ERROR` if the constraints are violated. If the host receives a `SEQ_ERROR`
-response it must consider any in-progress commands to have failed. The host may
-retry the affected command(s) after generating a suitable sequence number.
-
-#### Description:
-
-SUCCESS		- Command completed successfully
-
-PARAM_ERROR	- Error with parameters supplied or command invalid
-
-WRITE_ERROR	- Error writing to the backing file system
-
-SYSTEM_ERROR	- Error in BMC performing system action
-
-TIMEOUT		- Timeout in performing action
-
-BUSY		- Daemon in suspended state (currently unable to access flash)
-		- Retry again later
-
-WINDOW_ERROR	- Command not valid for active window or no active window
-		- Try opening an appropriate window and retrying the command
-
-SEQ_ERROR	- Invalid sequence number supplied with command
-
-LOCKED_ERROR	- Tried to mark dirty or erased locked area of flash
-
-### Information
-- All multibyte messages are LSB first (little endian)
-- All responses must have a valid return code in byte 13
-
-
-### Commands in detail
-
-Block size refers to an agreed value which is used as a unit for the
-arguments of various commands and responses. Having a block size multiplier
-allows us to specify larger values with fewer command and response fields.
-
-In V1 block size is hard coded to 4K.
-In V2 it is variable and must be queried with the GET_MBOX_INFO command.
-In V3 the host can request a given block size however it is ultimately up to
-the daemon to choose a block size which is returned as part of the GET_MBOX_INFO
-command response. The host must respect the daemons choice. The ability for the
-host to request a block size is provided such that it can choose an appropriate
-size to be able to utilise commands which only operate at the block level.
-
-Note that for simplicity block size must always be a power-of-2.
-Block size must also be greater than or equal to 4K. This is due to the
-fact that we have a 28-bit LPC address space and commands which return an
-LPC address do so in 16 bits, thus we need at least a 12-bit unit to ensure
-that we can specify the entire address space. This additionally allows us
-to specify flash addresses of at least 256MB.
-
-Sizes and addresses are specified in either bytes - (bytes)
-					 or blocks - (blocks)
-Sizes and addresses specified in blocks must be converted to bytes by
-multiplying by the block size.
-```
-Command:
-	RESET_STATE
-	Added in:	V1
-	Arguments:
-		-
-	Response:
-		-
-	Notes:
-		This command is designed to inform the BMC that it should put
-		host LPC mapping back in a state where the SBE will be able to
-		use it. Currently, this means pointing back to BMC flash
-		pre mailbox protocol. Final behavior is still TBD.
-
-Command:
-	GET_MBOX_INFO
-	Added in:	V1
-	Arguments:
-		V1:
-		Args 0: API version
-
-		V2:
-		Args 0: API version
-
-		V3:
-		Args 0: API version
-		Args 1: Requested block size (shift)
-
-	Response:
-		V1:
-		Args 0: API version
-		Args 1-2: default read window size (blocks)
-		Args 3-4: default write window size (blocks)
-
-		V2:
-		Args 0: API version
-		Args 1-2: reserved
-		Args 3-4: reserved
-		Args 5: Block size as power of two (encoded as a shift)
-		Args 6-7: Suggested Timeout (seconds)
-
-		V3:
-		Args 0: API version
-		Args 1-2: reserved
-		Args 3-4: reserved
-		Args 5: Block size as power of two (encoded as a shift)
-		Args 6-7: Suggested Timeout (seconds)
-		Args 8: Num Allocated Flash IDs
-	Notes:
-		The suggested timeout is a hint to the host as to how long
-		it should wait after issuing a command to the BMC before it
-		times out waiting for a response. This is the maximum time
-		which the BMC thinks it could take to service any command which
-		the host could issue. This may be set to zero to indicate that
-		the BMC	does not wish to provide a hint in which case the host
-		must choose some reasonable value.
-
-		The host may desire a specific block size and thus can request
-		this by giving a hint to the daemon (may be zero). The daemon
-		may use this to select the block size which it will use however
-		is free to ignore it. The value in the response is the block
-		size which must be used for all further requests until a new
-		size is	negotiated by another call to GET_MBOX_INFO. (V3)
-
-Command:
-	GET_FLASH_INFO
-	Added in:	V1
-	Arguments:
-		V1, V2:
-		-
-
-		V3:
-		Args 0: Flash ID
-	Response:
-		V1:
-		Args 0-3: Flash size (bytes)
-		Args 4-7: Erase granule (bytes)
-
-		V2, V3:
-		Args 0-1: Flash size (blocks)
-		Args 2-3: Erase granule (blocks)
-
-Command:
-	CREATE_{READ/WRITE}_WINDOW
-	Added in:	V1
-	Arguments:
-		V1:
-		Args 0-1: Requested flash offset (blocks)
-
-		V2:
-		Args 0-1: Requested flash offset (blocks)
-		Args 2-3: Requested flash size to access (blocks)
-
-		V3:
-		Args 0-1: Requested flash offset (blocks)
-		Args 2-3: Requested flash size to access (blocks)
-		Args 4: Flash ID
-	Response:
-		V1:
-		Args 0-1: LPC bus address of window (blocks)
-
-		V2, V3:
-		Args 0-1: LPC bus address of window (blocks)
-		Args 2-3: Window size (blocks)
-		Args 4-5: Flash offset mapped by window (blocks)
-	Notes:
-		The flash offset which the host requests access to is always
-		taken from the start of flash - that is it is an absolute
-		offset into flash.
-
-		LPC bus address is always given from the start of the LPC
-		address space - that is it is an absolute address.
-
-		The requested access size is only a hint. The response
-		indicates the actual size of the window. The BMC may
-		want to use the requested size to pre-load the remainder
-		of the request. The host must not access past the end of the
-		active window.
-
-		The flash offset mapped by the window is an absolute flash
-		offset and must be less than or equal to the flash offset
-		requested by the host. It is the responsibility of the host
-		to use this information to access any offset which is required.
-
-		The requested window size may be zero. In this case the
-		BMC is free to create any sized window but it must contain
-		atleast the first block of data requested by the host. A large
-		window is of course preferred and should correspond to
-		the default size returned in the GET_MBOX_INFO command.
-
-		If this command returns successfully then the created window
-		is the active window. If it fails then there is no active
-		window.
-
-Command:
-	CLOSE_WINDOW
-	Added in:	V1
-	Arguments:
-		V1:
-		-
-
-		V2:
-		Args 0: Flags
-	Response:
-		-
-	Notes:
-		Closes the active window. Any further access to the LPC bus
-		address specified to address the previously active window will
-		have undefined effects. If the active window is a
-		write window then the BMC must perform an implicit flush.
-
-		The Flags argument allows the host to provide some
-		hints to the BMC. Defined Values:
-			0x01 - Short Lifetime:
-				The window is unlikely to be accessed
-				anytime again in the near future. The effect of
-				this will depend on BMC implementation. In
-				the event that the BMC performs some caching
-				the BMC daemon could mark data contained in a
-				window closed with this flag as first to be
-				evicted from the cache.
-
-Command:
-	MARK_WRITE_DIRTY
-	Added in:	V1
-	Arguments:
-		V1:
-		Args 0-1: Flash offset to mark from base of flash (blocks)
-		Args 2-5: Number to mark dirty at offset (bytes)
-
-		V2:
-		Args 0-1: Window offset to mark (blocks)
-		Args 2-3: Number to mark dirty at offset (blocks)
-		Args 4  : Don't Erase Before Write (V3)
-
-	Response:
-		-
-	Notes:
-		The BMC has no method for intercepting writes that
-		occur over the LPC bus. The host must explicitly notify
-		the daemon of where and when a write has occurred so it
-		can be flushed to backing storage.
-
-		Offsets are given as an absolute (either into flash (V1) or the
-		active window (V2)) and a zero offset refers to the first
-		block. If the offset + number exceeds the size of the active
-		window then the command must not succeed.
-
-		The host can give a hint to the daemon that is doesn't have to
-		erase a flash area before writing to it by setting ARG[4]. This
-		means that the daemon will blindly perform a write to that area
-		and will not try to erase it before hand. This can be used if
-		the host knows that a large area has already been erased for
-		example but then wants to perform many small writes.
-
-Command
-	WRITE_FLUSH
-	Added in:	V1
-	Arguments:
-		V1:
-		Args 0-1: Flash offset to mark from base of flash (blocks)
-		Args 2-5: Number to mark dirty at offset (bytes)
-
-		V2:
-		-
-
-	Response:
-		-
-	Notes:
-		Flushes any dirty/erased blocks in the active window to
-		the backing storage.
-
-		In V1 this can also be used to mark parts of the flash
-		dirty and flush in a single command. In V2 the explicit
-		mark dirty command must be used before a call to flush
-		since there are no longer any arguments. If the offset + number
-		exceeds the size of the active window then the command must not
-		succeed.
-
-
-Command:
-	BMC_EVENT_ACK
-	Added in:	V1
-	Arguments:
-		Args 0:	Bits in the BMC status byte (mailbox data
-			register 15) to ack
-	Response:
-		*clears the bits in mailbox data register 15*
-	Notes:
-		The host should use this command to acknowledge BMC events
-		supplied in mailbox register 15.
-
-Command:
-	MARK_WRITE_ERASED
-	Added in:	V2
-	Arguments:
-		V2:
-		Args 0-1: Window offset to erase (blocks)
-		Args 2-3: Number to erase at offset (blocks)
-	Response:
-		-
-	Notes:
-		This command allows the host to erase a large area
-		without the need to individually write 0xFF
-		repetitively.
-
-		Offset is the offset within the active window to start erasing
-		from (zero refers to the first block of the active window) and
-		number is the number of blocks of the active window to erase
-		starting at offset. If the offset + number exceeds the size of
-		the active window then the command must not succeed.
-
-Command:
-	GET_FLASH_NAME
-	Added in:	V3
-	Arguments:
-		Args 0: Flash ID
-	Response:
-		Args 0   : Flash Name Length (bytes)
-		Args 1-10: Flash Name / UID
-	Notes:
-		Describes a flash with some kind of identifier useful to the
-		host system. This is typically a null-padded string.
-
-		The length in the response is the number of response arguments
-		as part of the flash name field which the host should expect to
-		have been populated.
-
-Command:
-	MARK_LOCKED
-	Added in:	V3
-	Arguments:
-		Args 0-1: Flash offset to lock (blocks)
-		Args 2-3: Number to lock at offset (blocks)
-		Args 4: Flash ID
-	Response:
-		-
-	Notes:
-		Lock an area of flash so that the host can't mark it dirty or
-		erased. If the requested area is within the current window and
-		that area is currently marked dirty or erased then this command
-		must fail with PARAM_ERROR.
-
-```
-
-### BMC Events in Detail:
-
-If the BMC needs to tell the host something then it simply
-writes to Byte 15. The host should have interrupts enabled
-on that register, or otherwise be polling it.
-
-#### Bit Definitions:
-
-Events which must be ACKed:
-```
-0x01: BMC Reboot
-0x02: BMC Windows Reset (V2)
-```
-
-Events which cannot be ACKed (BMC will clear when no longer
-applicable):
-```
-0x40: BMC Flash Control Lost (V2)
-0x80: BMC MBOX Daemon Ready (V2)
-```
-
-#### Event Description:
-
-Events which must be ACKed:
-The host should acknowledge these events with BMC_EVENT_ACK to
-let the BMC know that they have been received and understood.
-```
-0x01 - BMC Reboot:
-	Used to inform the host that a BMC reboot has occurred.
-	The host must perform protocol version negotiation again and
-	must assume it has no active window. The host must not assume
-	that any commands which didn't respond as such succeeded.
-0x02 - BMC Windows Reset: (V2)
-	The host must assume that its active window has been closed and
-	that it no longer has an active window. The host is not
-	required to perform protocol version negotiation again. The
-	host must not assume that any commands which didn't respond as such
-	succeeded.
-```
-
-Events which cannot be ACKed:
-These events cannot be acknowledged by the host and a call to
-BMC_EVENT_ACK with these bits set will have no effect. The BMC
-will clear these bits when they are no longer applicable.
-```
-0x40 - BMC Flash Control Lost: (V2)
-	The BMC daemon has been suspended and thus no longer
-	controls access to the flash (most likely because some
-	other process on the BMC required direct access to the
-	flash and has suspended the BMC daemon to preclude
-	concurrent access).
-	The BMC daemon must clear this bit itself when it regains
-	control of the flash (the host isn't able to clear it
-	through an acknowledge command).
-	The host must not assume that the contents of the active window
-	correctly reflect the contents of flash while this bit is set.
-0x80 - BMC MBOX Daemon Ready: (V2)
-	Used to inform the host that the BMC daemon is ready to
-	accept command requests. The host isn't able to clear
-	this bit through an acknowledge command, the BMC daemon must
-	clear it before it terminates (assuming it didn't
-	terminate unexpectedly).
-	The host should not expect a response while this bit is
-	not set.
-	Note that this bit being set is not a guarantee that the BMC daemon
-	will respond as it or the BMC may have crashed without clearing
-	it.
-```
diff --git a/Documentation/protocol.md b/Documentation/protocol.md
new file mode 100644
index 0000000..5f06973
--- /dev/null
+++ b/Documentation/protocol.md
@@ -0,0 +1,1463 @@
+Copyright 2018 IBM
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+
+# Introduction
+
+This document defines a protocol and several transports for flash access
+mediation between the host and the Baseboard Management Controller (BMC).
+
+The driving motivation for the protocol is to expose flash devices owned by the
+BMC to the host. Usually, the flash device of interest is the host's firmware
+flash device - in some platform designs this is owned by the BMC to enable
+lights-out updates of the host firmware.
+
+As the flash is owned by the BMC, access by the host to its firmware must be
+abstracted and mediated. Abstraction and mediation alleviates several problems:
+
+1. Proliferation of flash controller driver implementations throughout firmware
+2. Conflict of access between the host and the BMC to the flash controller
+3. In some circumstances, mitigates security concerns.
+
+The protocol introduced in this document addresses each of these issues.
+Specifically, the document addresses defining a control mechanism for exposing
+flash data in the LPC firmware space, communicated via functions in the LPC IO
+space.
+
+# Scope
+
+The scope of the document is limited to defining the protocol and its
+transports, and does not cover the content or structure of the data read or
+written to the flash by the host firmware.
+
+The definition of transport-specific parameters, for example selection of IPMI
+`(NetFn, Command)` pairs, is also beyond the scope of the document.
+
+# Background, Design and Constraints
+
+The protocol was developed to meet requirements on OpenPOWER systems based
+around the ASPEED BMC System-on-Chips such as the AST2400 and AST2500.
+The ASPEED BMCs have properties and features that need to be taken into account:
+
+1. A read-only mapping of the SPI flash devices onto the ARM core's AHB
+2. Remapping of LPC Firmware cycles onto the AHB (LPC2AHB bridge)
+3. A reasonable but not significant amount of attached DRAM
+
+Prior to the development of the protocol described below flash reads were
+serviced by pointing the LPC2AHB bridge at the read-only flash mapping, and
+writes were serviced by a separate bridge that suffers significant performance
+and security issues.
+
+Point 3 serves to justify some of the design decisions embodied in the
+protocol, mainly the complexity required by the flexibility to absorb as much
+or as little reserved memory as desired via the concept of BMC-controlled
+windowing.
+
+The core concept of the protocol moves access away from the naive routing of
+LPC firmware cycles onto the host firmware SPI flash AHB mapping, and
+concentrates on servicing the LPC firmware cycles from reserved system memory.
+As the memory backing the LPC2AHB mapping is now writable the protocol meets
+the host's write requirements by defining commands to open, dirty and flush an
+in-memory window representing the state of the flash. The mechanism to read the
+flash becomes same as write, just that the dirty and flush commands are not
+legal on such windows.
+
+## Historic and Future Naming
+
+The original transport for the protocol was the ASPEED BMC LPC mailbox
+interface, and previous revisions of the protocol documentation referred to the
+protocol as the "mailbox" or "mbox" protocol. This naming is now deprecated, as
+the protocol has grown further transports and naming the protocol by its
+transport rather than its intent was, on reflection, misguided.
+
+The protocol has been tentatively renamed to the "Host I/O Mapping Protocol" or
+"hiomap". This is a reflection of its true purpose - to control the host's view
+of data exposed from the BMC.
+
+# Protocol Overview
+
+The primary flow of the protocol is for the host to send requests to the BMC,
+which adjusts the mapping of the LPC firmware space as requested and returns a
+status response to the host. These interactions are labelled "commands".
+However, as there is now an active software component on the BMC consuming
+access requests, the BMC must occasionally indicate state changes to the host.
+Such interactions are labelled "events". For example, if a user or other system
+software on the BMC suspends the host's access to its flash device, the
+BMC-side daemon implementing the protocol must notify the host that its
+requests will be denied until further notice.
+
+## Protocol Versioning
+
+To enable evolution of the command and event interfaces, incremental changes to
+the behaviour are defined in new versions of the protocol. The descriptions
+and tables that follow all identify the versions to which they are applicable.
+
+The highest currently specified protocol version is version 3.
+
+## Table of Commands
+
+| ID | Name | v1 | v2 | v3 | Description |
+|----|------|----|----|----|-------------|
+|  1 | [`RESET`](#reset-command) | ✓ | ✓ | ✓ | Reset the state of the LPC firmware space, closing any active window |
+|  2 | [`GET_INFO`](#get_info-command) | ✓ | ✓ | ✓ | Perform protocol version negotiation and retrieve fundamental parameters |
+|  3 | [`GET_FLASH_INFO`](#get_flash_info-command) | ✓ | ✓ | ✓ | Retrieve flash-specific parameters |
+|  4 | [`CREATE_READ_WINDOW`](#create_read_window-command) | ✓ | ✓ | ✓ | Request mapping of a flash region for read |
+|  5 | [`CLOSE`](#close-command) | ✓ | ✓ | ✓ | Close the current window, flushing any dirty regions |
+|  6 | [`CREATE_WRITE_WINDOW`](#create_write_window-command) | ✓ | ✓ | ✓ | Request mapping of a flash region for write |
+|  7 | [`MARK_DIRTY`](#mark_dirty-command) | ✓ | ✓ | ✓ | Mark a region of a write window as modified |
+|  8 | [`FLUSH`](#flush-command) | ✓ | ✓ | ✓ | Flush dirty regions of the write window to flash |
+|  9 | [`ACK`](#ack-command) | ✓ | ✓ | ✓ | Acknowledge the receipt of an event from the BMC |
+| 10 | [`ERASE`](#erase-command) |   | ✓ | ✓ | Mark a region of a write window as erased |
+| 11 | [`GET_FLASH_NAME`](#get_flash_name-command) |   |   | ✓ | Retrieve the name of an indexed flash device |
+| 12 | [`LOCK`](#lock-command) |   |   | ✓ | Mark a region of the current flash window as immutable |
+
+## Table of Events
+
+| ID | Name | v1 | v2 | v3 | Description |
+|----|------|----|----|----|-------------|
+|  0 | [`PROTOCOL_RESET`](#protocol_reset-event) | ✓ | ✓ | ✓ | The host is required to perform version negotiation and re-establish its window of interest |
+|  1 | [`WINDOW_RESET`](#window_reset-event) |   | ✓ | ✓ | The host must re-establish its window of interest |
+|  6 | [`FLASH_CONTROL_LOST`](#flash_control_lost-event) |   | ✓ | ✓ | The host should suspend access requests |
+|  7 | [`DAEMON_READY`](#daemon_ready-event) |   | ✓ | ✓ | The daemon is active and can accept commands |
+
+## List of Transports
+
+An essential feature of the protocol is that its behaviour is independent of
+the host-BMC transport. The command and event interfaces of each transport
+necessarily reflect the version of the protocol they are implementing, but the
+transport has no influence otherwise.
+
+There are three documented transports for the protocol:
+
+1. The [ASPEED BMC LPC Mailbox transport](#mailbox-transport)
+2. The [IPMI transport](#ipmi-transport)
+3. The [DBus transport](#dbus-transport)
+
+The command layout, routing and event mechanism for each transport all have
+different features and are detailed below. An important note is that command
+design is limited by the most constrained transport - the LPC mailbox
+transport - where only 11 bytes are available for encoding of command
+parameters.
+
+Implementations must choose to support one or more of the transports outlined
+in this document.
+
+Note that the DBus transport is intended for BMC-internal communications, and
+can be used to separate a host-interface transport from the protocol
+implementation.
+
+## Protocol Flow
+
+The high-level protocol flow is that the host first issues a `GET_INFO` command
+to negotiate the protocol version and acquire parameters fundamental to
+constructing arguments to and interpreting responses from the commands that
+follow.
+
+Once `GET_INFO` has successfully completed, the host should request the flash
+parameters with `GET_FLASH_INFO`. The response provides information on the
+flash capacity and the size of its erase granule.
+
+Following `GET_FLASH_INFO`, the next act is to establish an active flash window
+with either one of the `CREATE_READ_WINDOW` or `CREATE_WRITE_WINDOW` commands.
+
+In the event of creating a write window the host must inform the BMC of the
+regions to which it has written with `MARK_DIRTY`- the BMC receives no
+notification of accesses from the host, they are simply mapped by the LPC2AHB
+bridge as necessary. As the accesses are to system memory and not the flash
+the changes identified by the `MARK_DIRTY` commands are not permanent until a
+`FLUSH` command is received (implicit flushes are discussed below), at which
+point the dirty regions of the active window will be written to the flash
+device.
+
+As an optimisation the host may choose to use the `ERASE` command to indicate
+that large regions should be set to the erased state. This optimisation saves
+the associated LPC firmware cycles to write the regions into the erased state.
+
+## Version Negotiation
+
+When invoking `GET_INFO` the host must provide the BMC its highest
+supported version of the protocol. The BMC must respond with a protocol version
+less than or equal to that requested by the host, or in the event that there is
+no such value, an error code. In the event that an error is returned the host
+must not continue to communicate with the BMC. Otherwise, the protocol version
+returned by the BMC is the agreed protocol version for all further
+communication. The host may at a future point request a change in protocol
+version by issuing a subsequent `GET_INFO` command.
+
+### Unversioned Commands
+
+In some circumstances it is necessary for bootstrap or optimisation purposes to
+support unversioned commands. The protocol supports three unversioned commands:
+
+1. `RESET`
+2. `GET_INFO`
+3. `ACK`
+
+All remaining commands have their presence and behaviour specified with respect
+to the negotiated version of the protocol.
+
+The arguments to the `GET_INFO` command are considered unversioned and as a
+result are static in nature - the protocol implementation has no means to
+decode version-specific arguments as the version has not yet been
+negotiated. With respect to the response, the version field is unversioned, but
+all subsequent fields _may_ be versioned.
+
+`RESET` remaining unversioned is an optimisation catering to deeply embedded
+components on the host side that may need access to the command. Keeping
+`RESET` unversioned removes the complexity of implementing `GET_INFO` with its
+version negotiation and minimises the overhead required to get into the
+pre-boot state.
+
+Defining `ACK` as unversioned ensures host firmware that has minimal protocol
+support can silence interrupts from the BMC as required.
+
+## Sequence Numbers
+
+Sequence numbers are included in messages for correlation of commands and
+responses. v1, v2 and v3 of the protocol permit either zero or one commands to
+be in progress (yet to receive a response).
+
+For generality, the host must generate a sequence number that is unique with
+respect to the previous command (one that has received a response) and any
+in-progress commands. Sequence numbers meeting this requirement are considered
+valid. The BMC's response to a command must contain the same sequence number
+issued by the host as found in the relevant command.
+
+Sequence numbers may be reused in accordance with the constraints outlined
+above. However, it is not an error if the BMC receives a unversioned command
+(`RESET`, `GET_INFO` or `ACK`) with an invalid sequence number. For all other
+cases, the BMC must respond with an error if the constraints are violated. If
+the host receives a sequence-related error response it must consider any
+in-progress commands to have failed. The host may retry the affected command(s)
+after generating a suitable sequence number.
+
+## Window Management
+
+There is only ever one active window which is the window created by the most
+recent `CREATE_READ_WINDOW` or `CREATE_WRITE_WINDOW` call which succeeded. Even
+though there are two types of windows there can still only be one active window
+irrespective of type. The host must not write to a read window. The host may
+read from a write window and the BMC must guarantee that the window reflects
+what the host has written there.
+
+A window can be closed by issuing the `CLOSE` command, in which case there is
+no active window and the host must not access the LPC firmware space until a
+window is subsequently opened. If the host closes an active write window then
+the BMC must perform an implicit flush. If the host tries to open a new window
+with an already active window then the active window is closed (and implicitly
+flushed if it was a write window). If the new window is successfully opened
+then it is the new active window; if the command fails then there is no active
+window and the previously active window must no longer be accessed.
+
+The host must not access an LPC address other than that which is contained by
+the active window. The host must not use write management functions (see below)
+if the active window is a read window or if there is no active window.
+
+## Command Parameter Types
+
+It is common in the protocol definition for command parameters to be
+represented in terms of a block size. This block size may refer to e.g. the
+size of the erase granule of the flash, or it may be another value entirely.
+Regardless of what it represents, the argument values are scaled by the block
+size determined by version negotiation. Specifying arguments in terms of a
+block size allows transports to keep a compact representation in constrained
+implementations such as the LPC mailbox transport.
+
+Note that for simplicity block size must always be a power-of-2. The block size
+must also be greater than or equal to 4K regardless of the negotiated protocol
+version.
+
+Finally, conversion between blocks and bytes is achieved by respectively
+dividing or multiplying the quantity by the negotiated block-size.
+
+# Transport Overview
+
+Several transports are defined for the protocol and are outlined below. The key
+features of transport support are the wire-format, delivery mechanisms of
+commands and events, and the definition and delivery of response codes.
+
+The DBus transport is the most foreign of the three as it does not encode the
+command index or a sequence number; these two elements are handled by the
+properties of DBus itself.
+
+## Mailbox Transport
+
+* Multi-byte quantity endianness: Little-endian
+* Command length encoding: Assumed from negotiated protocol version
+* Parameter alignment: Packed (no padding)
+* Command status response: ABI-defined Response byte
+* Event Delivery: ABI-defined BMC Status byte
+
+The mailbox transport defines the ABI used over the mailbox registers. There
+are 16 data registers and several status and control registers for managing
+interrupts between the host and the BMC. For the purpose of defining the
+transport ABI the status and control registers can mostly be disregarded, save
+for the necessity of issuing and responding to interrupts on each side.
+
+Assuming the registers are in a contiguous layout (this is not reflected in the
+hardware, but may be the abstraction presented by the associated kernel
+driver), the ABI is defined as follows, where the bytes in the range [2, 12]
+are available for command parameters and are defined on a per-command basis.
+
+```
+    0        7         15                    31
+   +----------+----------+---------------------+
+ 0 | Command  | Sequence |                     |
+   +----------+----------+---------------------+
+ 4 |                                           |
+   +-------------------------------------------+
+ 8 |                                           |
+   +----------+----------+----------+----------+
+12 |          | Response |  BMC Sts | Host Sts |
+   +----------+----------+----------+----------+
+    0        7         15         23         31
+```
+
+Command status response codes are as follows:
+
+### Status Codes
+
+| ID |     Name       | v1 | v2 | v3 | Description                                          |
+|----|----------------|----|----|----|------------------------------------------------------|
+|  1 | `SUCCESS`      | ✓  | ✓  | ✓  | Command completed successfully                       |
+|  2 | `PARAM_ERROR`  | ✓  | ✓  | ✓  | Error with parameters supplied or command invalid    |
+|  3 | `WRITE_ERROR`  | ✓  | ✓  | ✓  | Error writing to the backing file system             |
+|  4 | `SYSTEM_ERROR` | ✓  | ✓  | ✓  | Error in BMC performing system action                |
+|  5 | `TIMEOUT`      | ✓  | ✓  | ✓  | Timeout in performing action                         |
+|  6 | `BUSY`         |    | ✓  | ✓  | Flash access suspended, retry later                  |
+|  7 | `WINDOW_ERROR` |    | ✓  | ✓  | Invalid window state or command invalid for window   |
+|  8 | `SEQ_ERROR`    |    | ✓  | ✓  | Invalid sequence number supplied with command        |
+|  9 | `LOCKED_ERROR` |    |    | ✓  | Erased or dirtied region intersected a locked region |
+
+## IPMI Transport
+
+* Multi-byte quantity endianness: Little-endian
+* Command length encoding: Assumed from negotiated protocol version
+* Parameter alignment: Packed (no padding)
+* Command status response: Mapped to IPMI completion codes
+* Event Delivery: Status byte in SEL via `SMS_ATN`
+
+The IPMI transport must reserve one `(NetFn, Command)` pair for host-to-BMC
+communications and one SEL `(NetFn, Command)` pair for BMC-to-host
+communication, signaled by `SMS_ATN`.
+
+The wire command framing is as follows:
+
+1. The command identifier is the first value and is encoded in one byte
+2. The sequence number is the second value and is encoded in one byte
+3. Parameters required by the (version, command) pair follow
+
+```
+    0        7         15                     N
+   +----------+----------+---------     -------+
+ 0 | Command  | Sequence |          ...        |
+   +----------+----------+---------     -------+
+```
+
+## DBus Transport
+
+* Multi-byte quantity endianness: Transport encoded
+* Command length encoding: Transport encoded
+* Parameter alignment: Transport encoded
+* Command status response: Mapped to Unix system error codes
+* Event Delivery: DBus signals and properties per event type
+
+DBus defines its own wire-format for messages, and so support for this
+transport concentrates on mapping commands and events onto DBus concepts.
+Specifically, commands are represented by DBus methods and events are
+represented by properties for level-triggered (persistent) events and signals
+for edge-triggered (acknowledgeable) events. DBus will automatically generate a
+`PropertiesChanged` signal for changes to properties allowing consumers to
+learn of updates as they happen.
+
+As the commands are represented by DBus methods there is no need to encode the
+command index in the request - this is represented by the appropriate method on
+the implementation object's interface.
+
+Similarly, there's no need to encode sequence numbers as DBus handles the
+correlation of messages over the bus. As there is no encoding of sequence
+numbers, there is no need to describe a command status response like
+`SEQ_ERROR`, which allows a clean mapping to Unix error codes.
+
+Finally, commands mapped to methods have the number of parameters and types
+described by the method's type signature, though these descriptions concern the
+basic wire types and not the semantic types relevant to the protocol. The method
+type signature and parameter ordering are described in the relevant command
+definition.
+
+# Command Definitions
+
+The command identifier values and command-response parameter formats are
+described in tables under headers for each command. The order of the parameters
+in the parameter tables reflects the order of the parameters in the commands
+and responses. The M, I, and D columns represent the Mailbox, IPMI and DBus
+transports respectively. For the command identifier table the value in these
+columns' cells represent the command index, or for DBus, its method name. For
+the parameter tables the value represent the parameter's offset in the message
+(disregarding the command and sequence bytes), or in the case of DBus the
+appropriate [type
+signature](https://dbus.freedesktop.org/doc/dbus-specification.html#basic-types).
+
+## `RESET` Command
+
+| v1 | v2 | v3 | M | I | D     |
+|----|----|----|---|---|-------|
+| ✓  | ✓  | ✓  | 1 | 1 | Reset |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### Description
+
+Requests the BMC return the LPC firmware space to a state ready for host
+firmware bootstrap.
+
+## `GET_INFO` Command
+
+| v1 | v2 | v3 | M | I | D       |
+|----|----|----|---|---|---------|
+| ✓  | ✓  | ✓  | 2 | 2 | GetInfo |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Version           | Version |   1  | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Version           | Version |   1  | 0 | 0 | y |
+| Read Window Size  | Blocks  |   2  | 1 | 1 | q |
+| Write Window Size | Blocks  |   2  | 3 | 3 | q |
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Version           | Version |   1  | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Version           | Version |   1  | 0 | 0 | y |
+| Block Size Shift  | Count   |   1  | 5 | 1 | y |
+| Timeout           | Seconds |   2  | 6 | 2 | q |
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Version           | Version |   1  | 0 | 0 | y |
+| Block Size Shift  | Count   |   1  | 1 | 1 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Version           | Version |   1  | 0 | 0 | y |
+| Block Size Shift  | Count   |   1  | 5 | 1 | y |
+| Timeout           | Seconds |   2  | 6 | 2 | q |
+| Devices           | Count   |   1  | 8 | 4 | y |
+
+</td>
+</tr>
+</table>
+
+### Description
+
+The suggested timeout is a hint to the host as to how long it should wait after
+issuing a command to the BMC before it times out waiting for a response. This
+is the maximum time which the BMC thinks it could take to service any command
+which the host could issue. This may be set to zero to indicate that the BMC
+does not wish to provide a hint in which case the host must choose some
+reasonable value.
+
+From v3 the host may desire a specific block size and thus can request this by
+giving a hint to the daemon (may be zero). The daemon may use this to select
+the block size which it will use however is free to ignore it. The value in the
+response is the block size which must be used for all further requests until a
+new size is negotiated by another call to `GET_INFO`.
+
+## `GET_FLASH_INFO` Command
+
+| v1 | v2 | v3 | M | I | D            |
+|----|----|----|---|---|--------------|
+| ✓  | ✓  | ✓  | 3 | 3 | GetFlashInfo |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Size        | Bytes   | 4    | 0 | 0 | u |
+| Erase Granule     | Bytes   | 4    | 4 | 4 | u |
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Size        | Blocks  | 2    | 0 | 0 | q |
+| Erase Granule     | Blocks  | 2    | 2 | 2 | q |
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Device ID         | Index   | 1    | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Size        | Blocks  | 2    | 0 | 0 | q |
+| Erase Granule     | Blocks  | 2    | 2 | 2 | q |
+
+</td>
+</tr>
+</table>
+
+## `CREATE_READ_WINDOW` Command
+
+| v1 | v2 | v3 | M | I | D                |
+|----|----|----|---|---|------------------|
+| ✓  | ✓  | ✓  | 4 | 4 | CreateReadWindow |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Offset      | Blocks  | 2    | 0 | 0 | q |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| LPC FW Offset     | Blocks  | 2    | 0 | 0 | q |
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Address     | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| LPC FW Address    | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+| Flash Address     | blocks  | 2    | 4 | 4 | q |
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Address     | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+| Device ID         | Index   | 1    | 4 | 4 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| LPC FW Address    | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+| Flash Address     | blocks  | 2    | 4 | 4 | q |
+
+</td>
+</tr>
+</table>
+
+### Description
+
+The flash offset which the host requests access to is always taken from the
+start of flash - that is it is an absolute offset into flash.
+
+LPC bus address is always given from the start of the LPC address space - that
+is it is an absolute address.
+
+The requested access size is only a hint. The response indicates the actual
+size of the window. The BMC may want to use the requested size to pre-load the
+remainder of the request. The host must not access past the end of the active
+window.
+
+The flash offset mapped by the window is an absolute flash offset and must be
+less than or equal to the flash offset requested by the host. It is the
+responsibility of the host to use this information to access any offset which
+is required.
+
+The requested window size may be zero. In this case the BMC is free to create
+any sized window but it must contain at least the first block of data requested
+by the host. A large window is of course preferred and should correspond to the
+default size returned in the `GET_INFO` command.
+
+If this command returns successfully then the created window is the active
+window. If it fails then there is no active window.
+
+## `CLOSE` Command
+
+| v1 | v2 | v3 | M | I | D     |
+|----|----|----|---|---|-------|
+| ✓  | ✓  | ✓  | 5 | 5 | Close |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flags             | Field   | 1    | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flags             | Field   | 1    | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### Description
+
+Closes the active window. Any further access to the LPC bus address specified
+to address the previously active window will have undefined effects. If the
+active window is a write window then the BMC must perform an implicit flush.
+
+The Flags argument allows the host to provide some hints to the BMC. Defined
+values are:
+
+```
+0x01 - Short Lifetime:
+       The window is unlikely to be accessed anytime again in the near future.
+       The effect of this will depend on BMC implementation. In the event that
+       the BMC performs some caching the BMC daemon could mark data contained
+       in a window closed with this flag as first to be evicted from the cache.
+```
+
+## `CREATE_WRITE_WINDOW` Command
+
+| v1 | v2 | v3 | M | I | D                 |
+|----|----|----|---|---|-------------------|
+| ✓  | ✓  | ✓  | 6 | 6 | CreateWriteWindow |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Offset      | Blocks  | 2    | 0 | 0 | q |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| LPC FW Offset     | Blocks  | 2    | 0 | 0 | q |
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Address     | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| LPC FW Address    | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+| Flash Address     | blocks  | 2    | 4 | 4 | q |
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Address     | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+| Device ID         | Index   | 1    | 4 | 4 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| LPC FW Address    | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+| Flash Address     | blocks  | 2    | 4 | 4 | q |
+
+</td>
+</tr>
+</table>
+
+### Description
+
+The flash offset which the host requests access to is always taken from the
+start of flash - that is it is an absolute offset into flash.
+
+LPC bus address is always given from the start of the LPC address space - that
+is it is an absolute address.
+
+The requested access size is only a hint. The response indicates the actual
+size of the window. The BMC may want to use the requested size to pre-load the
+remainder of the request. The host must not access past the end of the active
+window.
+
+The flash offset mapped by the window is an absolute flash offset and must be
+less than or equal to the flash offset requested by the host. It is the
+responsibility of the host to use this information to access any offset which
+is required.
+
+The requested window size may be zero. In this case the BMC is free to create
+any sized window but it must contain at least the first block of data requested
+by the host. A large window is of course preferred and should correspond to the
+default size returned in the `GET_INFO` command.
+
+If this command returns successfully then the created window is the active
+window. If it fails then there is no active window.
+
+## `MARK_DIRTY` Command
+
+| v1 | v2 | v3 | M | I | D         |
+|----|----|----|---|---|-----------|
+| ✓  | ✓  | ✓  | 7 | 7 | MarkDirty |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Offset      | Blocks  | 2    | 0 | 0 | q |
+| Length            | Bytes   | 4    | 2 | 2 | u |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Window Offset     | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Window Offset     | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+| Flags             | Field   | 1    | 4 | 4 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### Description
+
+
+The BMC has no method for intercepting writes that
+occur over the LPC bus. The host must explicitly notify
+the daemon of where and when a write has occurred so it
+can be flushed to backing storage.
+
+Offsets are given as an absolute (either into flash (V1) or the
+active window (V2)) and a zero offset refers to the first
+block. If the offset + number exceeds the size of the active
+window then the command must not succeed.
+
+The host can give a hint to the daemon that is doesn't have to erase a flash
+area before writing to it by setting bit zero of the Flags parameter. This
+means that the daemon will blindly perform a write to that area and will not
+try to erase it before hand.  This can be used if the host knows that a large
+area has already been erased for example but then wants to perform many small
+writes.
+
+## `FLUSH` Command
+
+| v1 | v2 | v3 | M | I | D     |
+|----|----|----|---|---|-------|
+| ✓  | ✓  | ✓  | 8 | 8 | Flush |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Offset      | Blocks  | 2    | 0 | 0 | q |
+| Length            | Bytes   | 4    | 2 | 2 | u |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### Description
+
+Flushes any dirty/erased blocks in the active window to the backing storage.
+
+In V1 this can also be used to mark parts of the flash dirty and flush in a
+single command. In V2 the explicit mark dirty command must be used before a
+call to flush since there are no longer any arguments. If the offset + length
+exceeds the size of the active window then the command must not succeed.
+
+## `ACK` Command
+
+| v1 | v2 | v3 | M | I | D   |
+|----|----|----|---|---|-----|
+| ✓  | ✓  | ✓  | 9 | 9 | Ack |
+
+### v1 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Ack Mask          | Field   | 1    | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Ack Mask          | Field   | 1    | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Ack Mask          | Field   | 1    | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### Description
+
+The host should use this command to acknowledge BMC events propagated to the
+host.
+
+## `ERASE` Command
+
+| v1 | v2 | v3 | M  | I  | D     |
+|----|----|----|----|----|-------|
+|    | ✓  | ✓  | 10 | 10 | Erase |
+
+### v2 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Window Offset     | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Window Offset     | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### Description
+
+This command allows the host to erase a large area without the need to
+individually write 0xFF repetitively.
+
+Offset is the offset within the active window to start erasing from (zero
+refers to the first block of the active window) and number is the number of
+blocks of the active window to erase starting at offset. If the offset + number
+exceeds the size of the active window then the command must not succeed.
+
+## `GET_FLASH_NAME` Command
+
+| v1 | v2 | v3 | M  | I  | D            |
+|----|----|----|----|----|--------------|
+|    |    | ✓  | 11 | 11 | GetFlashName |
+
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Device ID         | Index   | 1    | 0 | 0 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Name length       | Bytes   | 1    | 0 | 0 | - |
+| Name              | String  | 10   | 1 | 1 | s |
+
+</td>
+</tr>
+</table>
+
+### Description
+
+Describes a flash with some kind of identifier useful to the host system.
+
+The length in the response is the number of response arguments as part of the
+flash name field which the host should expect to have been populated.
+
+Note that DBus encodes the string length in its string type, so the explicit
+length is omitted from the DBus message.
+
+## `LOCK` Command
+
+| v1 | v2 | v3 | M  | I  | D    |
+|----|----|----|----|----|------|
+|    |    | ✓  | 12 | 12 | Lock |
+
+### v3 Parameters
+
+<table>
+<tr>
+<th>Command</th><th>Response</th>
+</tr>
+<tr>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+| Flash Offset      | Blocks  | 2    | 0 | 0 | q |
+| Length            | Blocks  | 2    | 2 | 2 | q |
+| Device ID         | Index   | 1    | 4 | 4 | y |
+
+</td>
+<td valign="top">
+
+| Parameter         | Unit    | Size | M | I | D |
+|-------------------|---------|------|---|---|---|
+
+</td>
+</tr>
+</table>
+
+### Description
+
+Lock an area of flash so that the host can't mark it dirty or erased. If the
+requested area is within the current window and that area is currently marked
+dirty or erased then this command must fail.
+
+# Event Definitions
+
+The M, I, and D columns represent the Mailbox, IPMI and DBus transports
+respectively. The values in the M, I or D columns represent the events' bit
+index in the status byte, or in the case of the DBus transport the name of the
+relevant property or signal.
+
+
+## `PROTOCOL_RESET` Event
+
+| v1 | v2 | v3 | M | I | D             |
+|----|----|----|---|---|---------------|
+| ✓  | ✓  | ✓  | 0 | 0 | ProtocolReset |
+
+### Description
+
+Used to inform the host that a protocol reset has occurred, likely due to
+restarting the daemon. The host must perform protocol version negotiation again
+and must assume it has no active window. The host must also assume that any
+in-flight commands have failed.
+
+## `WINDOW_RESET` Event
+
+| v1 | v2 | v3 | M | I | D           |
+|----|----|----|---|---|-------------|
+|    | ✓  | ✓  | 1 | 1 | WindowReset |
+
+### Description
+
+The host must assume that its active window has been closed and that it no
+longer has an active window. The host is not required to perform protocol
+version negotiation again. The host must assume that any in-flight commands
+have failed.
+
+## `FLASH_CONTROL_LOST` Event
+
+| v1 | v2 | v3 | M | I | D                |
+|----|----|----|---|---|------------------|
+|    | ✓  | ✓  | 6 | 6 | FlashControlLost |
+
+### Description
+
+The BMC daemon has been suspended and thus no longer controls access to the
+flash (most likely because some other process on the BMC required direct access
+to the flash and has suspended the BMC daemon to preclude concurrent access).
+
+The BMC daemon must clear this bit itself when it regains control of the flash
+(the host isn't able to clear it through an acknowledge command).
+
+The host must not assume that the contents of the active window correctly
+reflect the contents of flash while this bit is set.
+
+## `DAEMON_READY` Event
+
+| v1 | v2 | v3 | M | I | D           |
+|----|----|----|---|---|-------------|
+|    | ✓  | ✓  | 7 | 7 | DaemonReady |
+
+### Description
+
+Used to inform the host that the BMC daemon is ready to accept command
+requests. The host isn't able to clear this bit through an acknowledge command,
+the BMC daemon must clear it before it terminates (assuming it didn't terminate
+unexpectedly).
+
+The host should not expect a response while this bit is not set.
+
+Note that this bit being set is not a guarantee that the BMC daemon will
+respond as it or the BMC may have crashed without clearing it.