docs/designs/bmc-boot-ready.md

33 `multi-user.target` has successfully started all if its services.
37 1. D-Bus objects don't exist until the backend is prepared to handle them.
43 Option 1 is challenging because D-Bus interfaces provided by OpenBMC state
44 applications have a mix of read-only properties (like current state) and
51 the op-panel code now need to properly handle error codes like this. You can
60 [1]: https://lists.ozlabs.org/pipermail/openbmc/2022-April/030175.html
62   https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/yaml/xyz/openbmc_project/State
64 …https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/State/BMC…
68 - Queue up chassis and host requested state changes until the BMC is in the
70   - What the "proper state" is will be implementation specific but by default
71     phosphor-state-manager will queue all requests until the BMC state has
90 multi-user.target and all of it's dependent services have completed prior to a
92 easier and safer to just have a global wait-for-bmc-ready function as proposed
103 This function will be implemented within the existing phosphor-state-manager
104 repository. x86-power-control, an alternative to phosphor-state-manager, could
109 - Ensure a power on request is properly queued and executed when it is made