docs/designs/bmc-boot-ready.md

12 firmware) to power on and boot the system. The goal of this design is to define
16 For example, on some system, you can not power on the chassis until the VPD has
29 [state][2] management interfaces in a system. The BMC, Chassis, and Host. Within
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.
38 2. If a user tries something that system is not in proper state to handle then
40 3. If a user tries something that system is not in proper state to handle then
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
56 changes would be needed. One concern is that having a system somewhat randomly
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
97 Users will need to understand that their request to power on the system may be
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