xref: /openbmc/phosphor-mboxd/README.md (revision acdbdd14)
104e8ffdaSSuraj Jitindar SinghCopyright 2017 IBM
2c442b710SCyril Bur
3c442b710SCyril BurLicensed under the Apache License, Version 2.0 (the "License");
4c442b710SCyril Buryou may not use this file except in compliance with the License.
5c442b710SCyril BurYou may obtain a copy of the License at
6c442b710SCyril Bur
7c442b710SCyril Bur  http://www.apache.org/licenses/LICENSE-2.0
8c442b710SCyril Bur
9c442b710SCyril BurUnless required by applicable law or agreed to in writing, software
10c442b710SCyril Burdistributed under the License is distributed on an "AS IS" BASIS,
11c442b710SCyril BurWITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
12c442b710SCyril BurSee the License for the specific language governing permissions and
13c442b710SCyril Burlimitations under the License.
14c442b710SCyril Bur
1525eca77fSAndrew JefferyMBOX
1625eca77fSAndrew Jeffery====
1757b0bca4SAndrew Jeffery
1804e8ffdaSSuraj Jitindar SinghThis repo contains the protocol definition for the host to BMC mailbox
1904e8ffdaSSuraj Jitindar Singhcommunication specification which can be found in
2004e8ffdaSSuraj Jitindar SinghDocumentation/mbox_procotol.md.
212dff340aSSuraj Jitindar Singh
2204e8ffdaSSuraj Jitindar SinghThere is also a reference implementation of a BMC mailbox daemon, the details
2304e8ffdaSSuraj Jitindar Singhof which can be found in Documentation/mboxd.md.
242dff340aSSuraj Jitindar Singh
2504e8ffdaSSuraj Jitindar SinghFinally there is also an implementation of a mailbox daemon control program, the
2604e8ffdaSSuraj Jitindar Singhdetails of which can be found in Documentation/mboxctl.md.
2725eca77fSAndrew Jeffery
28*aff2de64SAndrew JefferyBuilding
29*aff2de64SAndrew Jeffery========
30*aff2de64SAndrew Jeffery
31*aff2de64SAndrew JefferyThe build system is a standard autotools setup. `bootstrap.sh` runs all the
32*aff2de64SAndrew Jefferyjobs necessary to initialise autotools.
33*aff2de64SAndrew Jeffery
34*aff2de64SAndrew JefferyBy default mboxd is configured and built _without_ the 'virtual PNOR' feature
35*aff2de64SAndrew Jefferydiscussed below. The virtual PNOR functionality is written in C++, and due to
36*aff2de64SAndrew Jefferysome autotools clunkiness even if it is disabled mboxd will still be linked
37*aff2de64SAndrew Jefferywith `CXX`. Point `CXX` to `cc` at configure time if you do not have a C++
38*aff2de64SAndrew Jefferycompiler for your target (`./configure CXX=cc`).
39*aff2de64SAndrew Jeffery
40*aff2de64SAndrew JefferyIf you are hacking on the reference implementation it's recommended to run
41*aff2de64SAndrew Jeffery`bootstrap.sh` with the `dev` argument:
42*aff2de64SAndrew Jeffery
43*aff2de64SAndrew Jeffery```
44*aff2de64SAndrew Jeffery$ ./bootstrap.sh dev
45*aff2de64SAndrew Jeffery$ ./configure
46*aff2de64SAndrew Jeffery$ make
47*aff2de64SAndrew Jeffery$ make check
48*aff2de64SAndrew Jeffery```
49*aff2de64SAndrew Jeffery
50*aff2de64SAndrew JefferyThis will turn on several of the compiler's sanitizers to help find bad memory
51*aff2de64SAndrew Jefferymanagement and undefined behaviour in the code via the test suites.
52*aff2de64SAndrew Jeffery
53*aff2de64SAndrew JefferyOtherwise, build with:
54*aff2de64SAndrew Jeffery
55*aff2de64SAndrew Jeffery```
56*aff2de64SAndrew Jeffery$ ./bootstrap.sh
57*aff2de64SAndrew Jeffery$ ./configure
58*aff2de64SAndrew Jeffery$ make
59*aff2de64SAndrew Jeffery$ make check
60*aff2de64SAndrew Jeffery```
61*aff2de64SAndrew Jeffery
62*aff2de64SAndrew JefferyIn addition to its role as a flash abstraction `mboxd` can also serve as a
63*aff2de64SAndrew Jefferypartition/filesystem abstraction. This feature is known as 'virtual PNOR' and
64*aff2de64SAndrew Jefferyit can be enabled at `configure` time (note that this requires a C++ compiler
65*aff2de64SAndrew Jefferyfor your target):
66*aff2de64SAndrew Jeffery
67*aff2de64SAndrew Jeffery```
68*aff2de64SAndrew Jeffery$ ./bootstrap.sh
69*aff2de64SAndrew Jeffery$ ./configure --enable-virtual-pnor
70*aff2de64SAndrew Jeffery$ make
71*aff2de64SAndrew Jeffery$ make check
72*aff2de64SAndrew Jeffery```
73*aff2de64SAndrew Jeffery
7425eca77fSAndrew JefferyStyle Guide
7525eca77fSAndrew Jeffery===========
7625eca77fSAndrew Jeffery
7725eca77fSAndrew JefferyPreamble
7825eca77fSAndrew Jeffery--------
7925eca77fSAndrew Jeffery
8025eca77fSAndrew JefferyThis codebase is a mix of C (due to its heritage) and C++. This is an ugly
8125eca77fSAndrew Jefferysplit: message logging and error handling can be vastly different inside the
8225eca77fSAndrew Jefferysame codebase. The aim is to remove the split one way or the other over time
8325eca77fSAndrew Jefferyand have consistent approaches to solving problems.
8425eca77fSAndrew Jeffery
8525eca77fSAndrew Jefferyphosphor-mboxd is developed as part of the OpenBMC project, which also leads to
8625eca77fSAndrew Jefferyintegration of frameworks such as
8725eca77fSAndrew Jeffery[phosphor-logging](https://github.com/openbmc/phosphor-logging). Specifically
8825eca77fSAndrew Jefferyon phosphor-logging, it's noted that without care we can achieve absurd
8925eca77fSAndrew Jefferyduplication or irritating splits in where errors are reported, as the C code is
9025eca77fSAndrew Jefferynot capable of making use of the interfaces provided.
9125eca77fSAndrew Jeffery
9225eca77fSAndrew JefferyRules
9325eca77fSAndrew Jeffery-----
9425eca77fSAndrew Jeffery
9525eca77fSAndrew Jeffery1. Message logging MUST be done to stdout or stderr, and MUST NOT be done
9625eca77fSAndrew Jeffery   directly via journal APIs or wrappers of the journal APIs.
9725eca77fSAndrew Jeffery
9825eca77fSAndrew Jeffery   Rationale:
9925eca77fSAndrew Jeffery
10025eca77fSAndrew Jeffery   We have two scenarios where we care about output, with the important
10125eca77fSAndrew Jeffery   restriction that the method must be consistent between C and C++:
10225eca77fSAndrew Jeffery
10325eca77fSAndrew Jeffery   1. Running in-context on an OpenBMC-based system
10425eca77fSAndrew Jeffery   2. Running the test suite
10525eca77fSAndrew Jeffery
10625eca77fSAndrew Jeffery   In the first case it is desirable that the messages appear in the system
10725eca77fSAndrew Jeffery   journal. To this end, systemd will by default capture stdout and stderr of
10825eca77fSAndrew Jeffery   the launched binary and redirect it to the journal.
10925eca77fSAndrew Jeffery
11025eca77fSAndrew Jeffery   In the second case it is *desirable* that messages be captured by the test
11125eca77fSAndrew Jeffery   runner (`make check`) for test failure analysis, and it is *undesirable* for
11225eca77fSAndrew Jeffery   messages to appear in the system journal (as these are tests, not issues
11325eca77fSAndrew Jeffery   affecting the health of the system they are being executed on).
11425eca77fSAndrew Jeffery
11525eca77fSAndrew Jeffery   Therefore direct calls to the journal MUST be avoided for the purpose of
11625eca77fSAndrew Jeffery   message logging.
11725eca77fSAndrew Jeffery
11825eca77fSAndrew Jeffery   Note: This section specifically targets the use of phosphor-logging's
11925eca77fSAndrew Jeffery   `log<T>()`. It does not prevent the use of `elog<T>()`.
120