Fix formatting issue

Change-Id: Ib026da1cacc78b2b72fae72e87238dca3426c519
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>

Fixed format errors in the build

Change-Id: I5c274fa52abef0634fc80037d192b269959a757a
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>

prettier: re-format

Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.

prettier: re-format

Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.

Change-Id: If25c6524616e9c814ceab023c877d6049cb9f959
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

Documentation: Remove mboxctl.md

The merge of phosphor-mboxd and mboxbridge blew away the content. No-one
has complained, so remove the broken file.

Change-Id: Ic52bb4c3946b03485197efce1f6c6ff7ef71

Documentation: Remove mboxctl.md

The merge of phosphor-mboxd and mboxbridge blew away the content. No-one
has complained, so remove the broken file.

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

show more ...

protocol: Rework publication of events over DBus transport

A set of races was discovered around the propagation of HIOMAP protocol
BMC status events during BMC shutdown. In particular the change imp

protocol: Rework publication of events over DBus transport

A set of races was discovered around the propagation of HIOMAP protocol
BMC status events during BMC shutdown. In particular the change impacts
the design of the DBus transport defined in the protocol specification,
as signalling of both acknowledgeable and non-acknowledgeable events
could not be made atomic.

A particular case where this matters is when the daemon is terminated,
at which point it should simultaneously clear BMC_EVENT_DAEMON_READY and
set BMC_EVENT_PROTOCOL_RESET. The DBus interface as designed required
this be done as two separate messages, which lead to races propagating
the complete state update to the host during shutdown of ipmid.

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

show more ...

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. Form

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>

show more ...

mboxd: Rename mboxd_msg to transport_mbox

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

mboxd: Rename windows files

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

mboxd: Rename lpc source files

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

mboxd: Rename flash files

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

dbus: Use new bus name, object and interface

The new interface is a more typical use of DBus, exposing multiple
methods for the functions that are available on the object. The legacy
interface by co

dbus: Use new bus name, object and interface

The new interface is a more typical use of DBus, exposing multiple
methods for the functions that are available on the object. The legacy
interface by comparison exposed only one method whose arguments selected
sub-commands to be executed. The legacy approach is not terribly
discoverable and leads to a lack of clarity in the client code. The
legacy approach also obscured the implementation with its use of `struct
mbox_dbus_msg`. The new interface wraps around the existing helpers and
so also deals with `struct mbox_dbus_msg`, but this can at least be
removed in the future.

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

show more ...

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 ...