diff --git a/Documentation/mbox_protocol.md b/Documentation/mbox_protocol.md
index bcd70a8..74863a7 100644
--- a/Documentation/mbox_protocol.md
+++ b/Documentation/mbox_protocol.md
@@ -17,19 +17,21 @@ limitations under the License.
 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 the flash with the specifics of how the host is required to control
-this described below.
+access to a flash device with the specifics of how the host is required to
+control this described below.
 
 ## Version
 
-Both version 1 and version 2 of the protocol are described below with version 2
-specificities represented with V2 in brackets - (V2).
+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.
 
 ## 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 the flash.
+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.
@@ -280,6 +282,14 @@ 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.
 
+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). An attempt to lock an area of flash which is not clean in the current
+window must fail with PARAM_ERROR. (V3)
+
 ### BMC Events
 
 The BMC can raise events with the host asynchronously to communicate to the
@@ -316,6 +326,8 @@ 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
@@ -329,6 +341,7 @@ TIMEOUT		5
 BUSY		6	(V2)
 WINDOW_ERROR	7	(V2)
 SEQ_ERROR	8	(V2)
+LOCKED_ERROR	9	(V3)
 ```
 
 ### Sequence Numbers
@@ -368,6 +381,10 @@ BUSY		- Daemon in suspended state (currently unable to access flash)
 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
@@ -394,9 +411,7 @@ Sizes and addresses specified in blocks must be converted to bytes by
 multiplying by the block size.
 ```
 Command:
-	RESET_STATE
-	Implemented in Versions:
-		V1, V2
+	RESET_STATE (V1)
 	Arguments:
 		-
 	Response:
@@ -408,9 +423,7 @@ Command:
 		pre mailbox protocol. Final behavior is still TBD.
 
 Command:
-	GET_MBOX_INFO
-	Implemented in Versions:
-		V1, V2
+	GET_MBOX_INFO (V1)
 	Arguments:
 		V1:
 		Args 0: API version
@@ -418,6 +431,10 @@ Command:
 		V2:
 		Args 0: API version
 
+		V3:
+		Args 0: API version
+		Args 1: Requested block size (shift)
+
 	Response:
 		V1:
 		Args 0: API version
@@ -430,6 +447,14 @@ Command:
 		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
@@ -439,25 +464,32 @@ Command:
 		the BMC	does not wish to provide a hint in which case the host
 		must choose some reasonable value.
 
+		The host may require 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 this. 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
-	Implemented in Versions:
-		V1, V2
+	GET_FLASH_INFO (V1)
 	Arguments:
+		V1, V2:
 		-
+
+		V3:
+		Args 0: Flash ID
 	Response:
 		V1:
 		Args 0-3: Flash size (bytes)
 		Args 4-7: Erase granule (bytes)
 
-		V2:
+		V2, V3:
 		Args 0-1: Flash size (blocks)
 		Args 2-3: Erase granule (blocks)
 
 Command:
-	CREATE_{READ/WRITE}_WINDOW
-	Implemented in Versions:
-		V1, V2
+	CREATE_{READ/WRITE}_WINDOW (V1)
 	Arguments:
 		V1:
 		Args 0-1: Requested flash offset (blocks)
@@ -466,11 +498,15 @@ Command:
 		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:
+		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)
@@ -504,9 +540,7 @@ Command:
 		window.
 
 Command:
-	CLOSE_WINDOW
-	Implemented in Versions:
-		V1, V2
+	CLOSE_WINDOW (V1)
 	Arguments:
 		V1:
 		-
@@ -533,9 +567,7 @@ Command:
 				evicted from the cache.
 
 Command:
-	MARK_WRITE_DIRTY
-	Implemented in Versions:
-		V1, V2
+	MARK_WRITE_DIRTY (V1)
 	Arguments:
 		V1:
 		Args 0-1: Flash offset to mark from base of flash (blocks)
@@ -544,6 +576,7 @@ Command:
 		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:
 		-
@@ -558,10 +591,15 @@ Command:
 		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
-	Implemented in Versions:
-		V1, V2
+	WRITE_FLUSH (V1)
 	Arguments:
 		V1:
 		Args 0-1: Flash offset to mark from base of flash (blocks)
@@ -585,9 +623,7 @@ Command
 
 
 Command:
-	BMC_EVENT_ACK
-	Implemented in Versions:
-		V1, V2
+	BMC_EVENT_ACK (V1)
 	Arguments:
 		Args 0:	Bits in the BMC status byte (mailbox data
 			register 15) to ack
@@ -598,9 +634,7 @@ Command:
 		supplied in mailbox register 15.
 
 Command:
-	MARK_WRITE_ERASED
-	Implemented in Versions:
-		V2
+	MARK_WRITE_ERASED (V2)
 	Arguments:
 		V2:
 		Args 0-1: Window offset to erase (blocks)
@@ -617,6 +651,31 @@ Command:
 		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 (V3)
+	Arguments:
+		Args 0: Flash ID
+	Response:
+		Args 0-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.
+
+Command:
+	MARK_LOCKED (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.
+
 ```
 
 ### BMC Events in Detail:
