docs/designs/bmc-reset-with-host-up.md

18 A good portion of this is explained in the phosphor-state-manager [README][1].
24 The high level flow is that OpenBMC software first checks for pgood, and if set,
28 - /run/openbmc/chassis@0-on
29 - /run/openbmc/host@0-on
31 It should be noted that although full support is not in place for multi-chassis
32 and multi-host systems, the framework is there to build on.
33 `op-reset-chassis-running@.service` is a templated service, checking pgood in
35 /run/openbmc/chassis@%i-on, to indicate power is on for that instance. Similar
36 implementation is done for the host via `phosphor-reset-host-check@.service` and
37 the file /run/openbmc/host@%i-on.
39 If chassis power is on and the host is up, then `obmc-chassis-poweron@.target`
40 and `obmc-host-start@.target` are started.
49 - `ConditionPathExists=!/run/openbmc/chassis@%i-on`
50 - `ConditionPathExists=!/run/openbmc/host@%i-on`
57 allow this customization. For example, some systems would prefer to just leave
65 - Support both IPMI and PLDM as mechanisms to determine if the host is running.
66   - Allow either or both to be enabled
67 - Support custom behavior when chassis power is on but the BMC is unable to
69 - Both IPMI and PLDM stacks will give the host a set amount of time to respond.
70   Lack of response within this time limit will result in the BMC potentially
72   - This time limit must be configurable at build time
73 - IPMI and PLDM will implement a phosphor-dbus-interface interface,
80 - IPMI will continue to utilize the SMS_ATN command to indicate to the host that
86 - PLDM will utilize a GetTID command to the host to determine if it is running
87 - Where applicable, PLDM will provide a mechanism to distinguish between
89   - For example, on IBM systems there is a difference between the hostboot (host
99 - Check pgood
100 - Call mapper for all implementations of
102 - Read `CurrentFirmwareCondition` property of all interface. If any call returns
104 - Otherwise, check host via any custom mechanisms
105 - Execute automated recovery of host if desired
108 services and applications within phosphor-state-manager will coordinate the
109 checking of pgood, and if set, request the IPMI and PLDM applications to
111 software in phosphor-state-manager will take the appropriate action of creating
116 within phosphor-state-manager. Any system or company specific services can be
119 - `obmc-chassis-powerreset@.target.require`
120 - `obmc-host-reset@.target.requires`
124 A separate service and application will be created within phosphor-state-manager
129 - If chassis power on (/run/openbmc/chassis@%i-on)
130 - And host is off (!ConditionPathExists=!/run/openbmc/host@%i-on)
131 - And restored BootProgress is not None
132 - Then (assume host was booting before BMC reboot)
133   - Log error indicating situation
134   - Move host to Quiesce and allow automated recovery to kick in
147 the host as-is, even if it is unable to communicate with the host over IPMI or
155 It is the responsibility of the host firmware to set this register as applicable
166 or PLDM anyway, except you created something custom. So 99% of the time the IPMI
168 own custom host-detection applications in.
182 - Reboot the BMC while the host is booting, but before it's in a state where it
186 - Reboot the BMC when the host is up and running but disable the IPMI/PLDM stack
192   https://github.com/openbmc/phosphor-state-manager#bmc-reset-with-host-andor-chassis-on