summaryrefslogtreecommitdiffstats
path: root/Documentation
Commit message (Collapse)AuthorAgeFilesLines
* Documentation: Remove mboxctl.mdAndrew Jeffery2019-03-201-3/+0
| | | | | | | | 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>
* protocol: Rework publication of events over DBus transportAndrew Jeffery2018-11-261-3/+5
| | | | | | | | | | | | | | | | | 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>
* Documentation: Rewrite protocol specificationAndrew Jeffery2018-09-142-780/+1463
| | | | | | | | | | | | | | | | | 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>
* mboxd: Rename mboxd_msg to transport_mboxAndrew Jeffery2018-09-121-1/+1
| | | | | Change-Id: I0f4e206648c02a98fa938a7e582470c8d90904f1 Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
* mboxd: Rename windows filesAndrew Jeffery2018-09-051-1/+1
| | | | | Change-Id: I44e110906fd0f751f8f34b175f971e65896a7301 Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
* mboxd: Rename lpc source filesAndrew Jeffery2018-09-051-1/+1
| | | | | Change-Id: I289618c90b2df8911e362397b7eab99403c86c05 Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
* mboxd: Rename flash filesAndrew Jeffery2018-09-051-1/+1
| | | | | Change-Id: Icfe9d61775a198c5a0f8227bf5d6c4b7f11aeec3 Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
* dbus: Use new bus name, object and interfaceAndrew Jeffery2018-09-051-1/+1
| | | | | | | | | | | | | | | 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>
* Unfork phosphor-mboxd from mboxbridgeAndrew Jeffery2018-08-032-4/+959
|\ | | | | | | | | Change-Id: I1b3b9d7fd47719594c1de027389959a5a9a3ea7a Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
| * docs: Specify V3 of the mbox protocolSuraj Jitindar Singh2017-10-201-36/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Spelling and grammar fixes for mboxd.mdGunnar Mills2017-08-221-26/+26
| | | | | | | | | | Change-Id: Ie653e70d709d5d616666bbc072042589d16a802f Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
| * Spelling and grammar fixes for mbox_protocol.mdGunnar Mills2017-08-221-21/+21
| | | | | | | | | | Change-Id: I506fd571ad93ecd548c94ff119c910aa873bf1d7 Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
* | Point mailbox daemon documentation to mboxbridgeBrandon Wyman2017-11-171-180/+2
| | | | | | | | | | | | | | | | | | 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>
* | Point mailbox control protocol to mboxbridgeBrandon Wyman2017-11-171-109/+2
| | | | | | | | | | | | | | | | | | 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>
* | Documentation: Point to canonical protocol documentationAndrew Jeffery2017-05-251-688/+2
|/ | | | | | | | 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>
* docs: Add suggested timeout response argument to GET_MBOX_INFOSuraj Jitindar Singh2017-05-031-0/+9
| | | | | | | | | | | | | | | | | 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
* docs: Stipulate register 13 must be written last when writing a responseSuraj Jitindar Singh2017-05-031-0/+7
| | | | | | | | | | | | | | | 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
* docs: Stipulate that block size must be >= 4K and a power-of-2Suraj Jitindar Singh2017-05-031-2/+13
| | | | | | | | | | | | | | | | | 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
* docs: Reword create_{read/write}_window command specSuraj Jitindar Singh2017-05-031-19/+15
| | | | | | | | | 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
* mbox: Clarify sequence number constraintsAndrew Jeffery2017-04-261-16/+28
| | | | | | | And implement the specified behaviour. Change-Id: I268d5896aa8dda3875cd79f4ff18929c8e3aea49 Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
* mbox: 'regsiter' typo in protocol documentationAndrew Jeffery2017-04-241-1/+1
| | | | | Change-Id: Ic78359102aae580dadb4de782f7ea025aaa3f4ad Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
* mbox: Clarify protocol version negotionAndrew Jeffery2017-04-241-10/+11
| | | | | | | | | | | | | 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>
* docs: Create Documentation folder and add mboxd and mboxctl documentationSuraj Jitindar Singh2017-04-113-0/+944
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
OpenPOWER on IntegriCloud