Documentation: Rewrite protocol specification

The rewrite addresses two main issues in the original documentation:

1. The conflation of the protocol specification with the mailbox transport
2. Formatting and discoverability of command and event definitions

Additionally, the rewrite documents two new transports - IPMI and DBus.
It's noted that DBus is intended as a transport internal to the BMC,
while the IPMI transport is the new transport exposed to the host.

Finally, some commands and events have been renamed, however this has no
impact on the behaviour of the protocol.

Change-Id: Icc78141f4ead4395e8a348b80443cadd2300a751
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

2 files changed, 1463 insertions, 780 deletions

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.