Point mailbox daemon documentation to mboxbridge

Simlar to the update to mbox_protocol.md, those looking for the
documentation on the mailbox daemon should refer to the more
up-to-date version in th

Point mailbox daemon documentation to mboxbridge

Simlar to the update to mbox_protocol.md, those looking for the
documentation on the mailbox daemon should refer to the more
up-to-date version in the openbmc/mboxbridge repository.

Change-Id: Iedea144ee70c9c4059f08ccb131ddc4ecec7ad36
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

Point mailbox control protocol to mboxbridge

Similar to the update to mbox_protocol.md, those looking for this
documentation should refer to the more up-to-date version in the
openbmc/mboxbridge rep

Point mailbox control protocol to mboxbridge

Similar to the update to mbox_protocol.md, those looking for this
documentation should refer to the more up-to-date version in the
openbmc/mboxbridge repository.

Change-Id: I659f9a26822b81e99261c855f3ee61392bc9d6d5
Signed-off-by: Brandon Wyman <bjwyman@gmail.com>

show more ...

docs: Specify V3 of the mbox protocol

Version 3 of the mbox protocol makes four protocol changes:
- Add a requested block size argument to GET_MBOX_INFO
- Add a no erase argument to MARK_DIRTY
-

docs: Specify V3 of the mbox protocol

Version 3 of the mbox protocol makes four protocol changes:
- Add a requested block size argument to GET_MBOX_INFO
- Add a no erase argument to MARK_DIRTY
- Add a GET_FLASH_NAME command and support multiple flash devices
- Add a MARK_LOCKED command

Requested Block Size:
The requested block size argument has been added to the GET_MBOX_INFO
command to allow the host to request a specified block size which might
be required to allow data manipulation at a finer granularity. The
daemon should take this into account when choosing a block size for use
which it will specify in the response as before. The daemon has final
say and the host must use the block size the daemon chooses.

No Erase:
The no erase argument to the mark dirty command allows a host to specify
that an area of flash should not be erased before being written to, as is
the default behaviour. This can be used when a host has already erased a
large area and then performs many small writes which would normally mean
many erases due to the implicit erase before write, making this slow.

Add GET_FLASH_NAME command:
The ability to support multiple flash devices has been added so that the
mbox protocol can be used to arbitrate access from the host to a number
of flash devices which the daemon has access to. To facilitate this the
GET_FLASH_INFO, CREATE_{READ/WRITE}_WINDOW, and MARK_LOCKED commands now
take a flash ID, with the number of flash IDs allocated returned by the
GET_MBOX_INFO commands. There is also a new command GET_FLASH_NAME used
to convert a flash ID to a flash name.

Add MARK_LOCKED command:
The MARK_LOCKED command has been added to allow an area(s) of flash to be
locked, that is that area must be treated as read only and the host is
not allowed to dirty or erase any windows which map that area of flash.
Additionally another error code LOCKED_ERROR was added to be returned
when the host does try to dirty or erase a locked area.

The host cannot lock a currently dirty or erased area of the current
write window as it is not defined if the clean/dirty/erased value is
what should actually be "locked".

A locked area of flash remains so until the daemon receives an
mboxctl --clear-locked command and the locked areas are stored in a file
on the BMC filesystem to ensure persistence across BMC reboots/daemon
crashes.

Multiple flash device support proposed and defined by:
William A. Kennington III <wak@google.com>

Change-Id: I898698840dec221ae20e33943bb28e65abc4fe37
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Adriana Kobylak <anoo@us.ibm.com>
Reviewed-by: William A. Kennington III <wak@google.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

show more ...

Spelling and grammar fixes for mboxd.md

Change-Id: Ie653e70d709d5d616666bbc072042589d16a802f
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>

Spelling and grammar fixes for mbox_protocol.md

Change-Id: I506fd571ad93ecd548c94ff119c910aa873bf1d7
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>

Documentation: Point to canonical protocol documentation

Avoid conflicts in the protocol documentation by pointing back to the
reference implementation.

Change-Id: I380f32dab2e9b8bbeec25b9abffe9c54

Documentation: Point to canonical protocol documentation

Avoid conflicts in the protocol documentation by pointing back to the
reference implementation.

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

show more ...

docs: Add suggested timeout response argument to GET_MBOX_INFO

It would be nice to suggest to the host how long it should wait for a
response to a command before assuming that the BMC is not going t

docs: Add suggested timeout response argument to GET_MBOX_INFO

It would be nice to suggest to the host how long it should wait for a
response to a command before assuming that the BMC is not going to
respond and timing out.

Add a response argument for this to the GET_MBOX_INFO command. We don't want
to require a BMC to set this so we allow it to be zero to indicate that no
suggestion has been given.

This doesn't require us to bump the protocol number since the current daemon
just sets this to zero (which is allowed) and the host is free to ignore this,
which it currently does.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: Idd65a5660e0092b9abd98829403b981fd26f8bbe

show more ...

docs: Stipulate register 13 must be written last when writing a response

Writes to register 13 (Response Code) are what is used to generate an
interrupt to the host. On receiving this interrupt the

docs: Stipulate register 13 must be written last when writing a response

Writes to register 13 (Response Code) are what is used to generate an
interrupt to the host. On receiving this interrupt the host can start
processing the entire response message. Thus to ensure that the host
is processing the correct mbox response register 13 must be the last
to be written.

Stipulate in the protocol documentation that the last register to be
written by the BMC when writing a response must be the response code
into register 13.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: I2b4e14a81d7bbffc990cfb83321ab219e3df1d82

show more ...

docs: Stipulate that block size must be >= 4K and a power-of-2

Arguments and responses to most commands are given in block size which
is decided on during the version negotiation process when GET_MB

docs: Stipulate that block size must be >= 4K and a power-of-2

Arguments and responses to most commands are given in block size which
is decided on during the version negotiation process when GET_MBOX_INFO
is called.

We require that block size is greater than 4K (12 bit). The lpc bus
address space is 28 bit and commands which return an lpc bus address have
a 16 bit variable space, this means we can correctly specify anywhere in
the lpc address space.

This also allows us to support flash sizes up to 256MB where we can
correctly specify any flash offset in the command arguments.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: Ia08979017a3c0ff229ce412948dc4c67d357e82b

show more ...

docs: Reword create_{read/write}_window command spec

Reword the create_{read/write}_window command specification to make it
easier to understand and remove sentences which add no value or are
unnece

docs: Reword create_{read/write}_window command spec

Reword the create_{read/write}_window command specification to make it
easier to understand and remove sentences which add no value or are
unnecessarily verbose.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: Idb1ac8da82d4a1ab379c55ff650ef410de86e715

show more ...

mbox: Clarify sequence number constraints

And implement the specified behaviour.

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

mbox: 'regsiter' typo in protocol documentation

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

mbox: Clarify protocol version negotion

The specification intended that the mbox daemon return its highest
supported protocol version less-than-or-equal to the version requested
by the host. This wa

mbox: Clarify protocol version negotion

The specification intended that the mbox daemon return its highest
supported protocol version less-than-or-equal to the version requested
by the host. This was not clear in the documentation and was not the
behaviour implemented by the daemon.

Fix both the documentation and the daemon to perform to this
expectation.

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

show more ...

docs: Create Documentation folder and add mboxd and mboxctl documentation

Create a separate folder for documentation called Documentation.

Move the protocol definition into a file in this folder ca

docs: Create Documentation folder and add mboxd and mboxctl documentation

Create a separate folder for documentation called Documentation.

Move the protocol definition into a file in this folder called
mbox_protocol.md and update the README.md to explain the files in the
docs folder.

Also add two other files to the folder called mboxd.md and mboxctl.md
which document the operation of the reference implementations of the
mailbox daemon and the mailbox control program respectively.

Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Change-Id: I9f818700ad1e36a396a828f0f085b42cc106b550

show more ...