Milton, This is giving me a good start and I am digging through the docs. I want to test my concepts, so for each of these, I’ll write what I think is true and you can tell me where I am wrong, and put a question where I am not sure. - BMC power is assumed to be independent from BMC power - Enabling chassis power can interact with a HotSwap device or power path switching device, or an IBC, etc, to power on/off everything in the chassis but the BMC - When the Host is off, does this imply it has no power, or that the host is in an idle state and not running but has power applied? - For the above question, I assume most systems are VRM based - What about auxiliary supplies? Suppose a design has an FPGA or DSP independent from the host. Are these expected to follow chassis or host power? In non-CPU systems, the poweron of an FPGA and other support chips can have a complicated sequence. Is that handled in an integrated fashion with the VRM or independently? Mike > On Aug 23, 2020, at 9:22 PM, Milton Miller II wrote: > > Resend as plain text. > >> On August 21, 2020, Mike Jones wrote:>I am trying to understand how >> the Server power button in the webui >>> works. >>> >>> As before, using raspberry pi, and I’ll leave project links at the >>> end for anyone that wants to use them. Things work up to monitoring >>> voltages. Note the conf project has a phosphor branch for the full >>> monty.>>To reverse engineer, I setup: dbus-monitor —system > >> someFile.log >>> >>> There is a message for systemd1.Manager; member=StartUnit and best I >>> can tell, somehow this gets routed to systemd to start some service >>> or run some exe. I see this mentioned in the dbus transactions: >>> >>> "obmc-host-start@0.target” >>> >>> And that is in /lib/systemd/system and depends >>> on obmc-host-startmin@0.target, but that does not depend on any >>> service. So that is a dead end. It also depends on a reboot >> attempts, >>> but I think that is not responsible for power on/off. >>> >>> Then there are chassis services, but I cannot find a link from >>> obmc-host-start@0.target to objc-chassis-poweron@0.target. >> >> >> >>>> In this >>> doc: https://github.com/openbmc/docs/blob/master/architecture/openbm >> c >>> -systemd.md >>> >>> It shows: >>> >>> >>> ls -1 /lib/systemd/system/obmc-chassis-poweron\@0.target.requires/ >>> op-power-start@0.service op-wait-power-on@0.service>>But when I “ls” >> that path, the above dependencies are not there. >>> There is only a dependency on phosphor-fan-presence-tach@0.service >>> >>> There is some state service that lead to things with xzy paths, and >> I >>> eventually found /run/systemd/units. These have file names starting >>> with “invocation” in the names and link to GUID like nodes that >> don’t >>> “cat” like a normal file. So I am not sure how those work. Is there >>> some kernel driver that works like sysfs so that these nodes are not >>> traditional files? >>> >>> What I am trying to understand is two things: >>> >>> - Interaction with the power regulator >>> - Interaction with the host cpu >>> >>> So my hope is someone can connect the dots of the path from the dbus >>> to systemd through the targets to a service executable doing the >> work >>> so I can try to replace them with: >>> >>> - Something that turns the regulators on/off, with pmbus in this >>> case. >>> - Something that can behave like a host to keep the system happy >> like >>> a real system. >> >> >> >> Hi. There is some design documentation here >> >> https://github.com/openbmc/docs/blob/master/designs/state-management- >> and-external-interfaces.md >> >> and that links to phosphor-state-manager which has a lot of the units >> >> that kick off power and state transitions. >> >> >> The op-power-start are for systems following the OpenPOWER reference >> designs. The regulators are sequenced by an external microcontroller >> >> based on the state of a POWER_ON gpio from the BMC and a return >> PGOOD to indicate the state. There are also other op- prefixed units >> that >> initiate the host processor initialization (after the units check >> that fans are >> running as you found). >> >> There is also a watchdog that is started when the host is started and >> >> pinged and stopped via IPMI. >> >> If you are prototyping for a x86 system, there are alternative >> power implementations where the gpio toggles to represent a >> main power button push and their start cpu sequences. I think >> there are also arm systems but don't know what they are using >> for host interaction. >> >> I hope this advances your investigation and learning. >> >> milton >> >>>> Mike >>> >>> My repos >>> —————— >>> >>> https://github.com/Proclivis/meta-pmbus-raspberrypi.git >>> https://github.com/Proclivis/meta-pmbus-phosphor.git >>> https://github.com/Proclivis/conf-openbmc-adi.git >>> >>> The monitor messages for StartUnit >>> ——— >>> >>> method call time=1598039669.247458 sender=:1.48 -> >>> destination=org.freedesktop.systemd1 serial=33 >>> path=/org/freedesktop/systemd1; >>> interface=org.freedesktop.systemd1.Manager; member=StartUnit >>> string "obmc-host-start@0.target" >>> string "replace" >>> method call time=1598039669.276170 sender=:1.3 -> >>> destination=org.freedesktop.DBus serial=775 >>> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; >>> member=GetConnectionUnixUser >>> string ":1.48" >>> method return time=1598039669.276234 sender=org.freedesktop.DBus -> >>> destination=:1.3 serial=4294967295 reply_serial=775 >>> uint32 0 >>> method call time=1598039669.280376 sender=:1.3 -> >>> destination=org.freedesktop.DBus serial=776 >>> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; >>> member=AddMatch >>> string >>> "type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/ >> D >>> Bus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0 >> = >>> ':1.48'" >>> method return time=1598039669.280661 sender=org.freedesktop.DBus -> >>> destination=:1.3 serial=4294967295 reply_serial=776 >>> method call time=1598039669.280701 sender=:1.3 -> >>> destination=org.freedesktop.DBus serial=777 >>> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; >>> member=GetNameOwner >>> string ":1.48" >>> method return time=1598039669.280738 sender=org.freedesktop.DBus -> >>> destination=:1.3 serial=4294967295 reply_serial=777 >>> string ":1.48" >>> signal time=1598039669.280774 sender=:1.3 -> destination=(null >>> destination) serial=778 path=/org/freedesktop/systemd1; >>> interface=org.freedesktop.systemd1.Manager; member=UnitNew >>> string "obmc-host-start@0.target" >>> object path >>> "/org/freedesktop/systemd1/unit/obmc_2dhost_2dstart_400_2etarget" >>> signal time=1598039669.280823 sender=:1.3 -> destination=(null >>> destination) serial=779 path=/org/freedesktop/systemd1; >>> interface=org.freedesktop.systemd1.Manager; member=JobNew >>> uint32 1105 >>> object path "/org/freedesktop/systemd1/job/1105" >>> string "obmc-host-start@0.target" >>> method return time=1598039669.280883 sender=:1.3 -> >> destination=:1.48 >>> serial=780 reply_serial=33 >>> object path "/org/freedesktop/systemd1/job/1105" >>> signal time=1598039669.281305 sender=:1.48 -> destination=(null >>> destination) serial=34 path=/xyz/openbmc_project/state/host0; >>> interface=org.freedesktop.DBus.Properties; member=PropertiesChanged >>> string "xyz.openbmc_project.State.Host" >>> array [ >>> dict entry( >>> string "RequestedHostTransition" >>> variant string >>> "xyz.openbmc_project.State.Host.Transition.On" >>> ) >>> ] >>> array [ >>> ]