<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">Jason,<br><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Jan 26, 2022, at 3:43 PM, Shawn McCarney <shawnmm@linux.ibm.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Mike,</p>
<o:p></o:p>
<blockquote type="cite" cite="mid:8C9640C9-6E1B-4495-BA55-258DA1548799@gmail.com">I made a
config file below, and verified that it is on the target and loads
without error.<o:p></o:p></blockquote>
<p>Just to make sure I understand what you are saying, on the BMC
your 'config.json' file is installed in the
/usr/share/phosphor-regulators directory<br></p></div></blockquote><div>Correct</div><br><blockquote type="cite"><div dir="ltr"><p>
</p>
<p>And when you run 'journalctl -u phosphor-regulators.service', you
see a journal message stating that the phosphor-regulators
application has loaded your JSON file successfully? And no error
messages?<br></p></div></blockquote><div><br></div><div>Correct</div><br><blockquote type="cite"><div dir="ltr"><p>
</p>
<blockquote type="cite" cite="mid:8C9640C9-6E1B-4495-BA55-258DA1548799@gmail.com">
<p class="MsoNormal" style="-webkit-text-size-adjust: auto;
margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;">When
the target boots, using a I2C spy tool, the 0xDD command is
being read periodically, suggesting that this service is
processing the read command, and a query show the service is up.</p>
</blockquote>
<p>Sensor reading should begin when the chassis is powered on and
stop when the chassis is powered off. That is because some
regulators don't have power at standby or report invalid sensor
readings.</p></div></blockquote><div><br></div><div>I am using the SDK, so I have not worked on chassis power, so I don’t know if it is powered or not, but this gives me a good hint about the problem. Even so, the read command in config.json is getting polled. The other config item to modify the voltage did not occur.</div><div dir="ltr"><br></div>Given I am using an Aspeed EVK, is there an example for how to turn on a chassis with a GPIO, or a dbus operation, or an automatic turn on at boot?<br><blockquote type="cite"><div dir="ltr">
<p>Does the 'journalctl | grep -i Regulators' show that the service
files are being executed that enable and disable regulator sensor
monitoring?<br></p></div></blockquote><div>No, only the daemon starting.</div><blockquote type="cite"><div dir="ltr"><p>
</p>
<blockquote type="cite" cite="mid:8C9640C9-6E1B-4495-BA55-258DA1548799@gmail.com">
<p class="MsoNormal" style="-webkit-text-size-adjust: auto;
margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;">Using
dbus-monitor –system, I do not see any transactions that place
these sensor read values on dbus, nor does the normal probing
the chassis and inventory show values.</p>
</blockquote>
<p>Since you are reading a vout sensor for the rail named "vdd", the
resulting D-Bus object path for the sensor should be<br>
</p>
<p> /xyz/openbmc_project/sensors/voltage/vdd_vout</p>
<p>See
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/docs/config_file/pmbus_read_sensor.md#d-bus-sensor">https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/docs/config_file/pmbus_read_sensor.md#d-bus-sensor</a>
for more details.<br>
</p>
<p>Does that object path exist on D-Bus after you've powered on the
chassis and sensor monitoring has been enabled?<br></p></div></blockquote><div dir="ltr">It does not exist.</div><br><blockquote type="cite"><div dir="ltr"><p>
</p>
<p>You can see all the properties of the D-Bus sensor using the
command</p>
<p> busctl introspect xyz.openbmc_project.Power.Regulators
/xyz/openbmc_project/sensors/voltage/vdd_vout</p>
<p>You can see all regulator sensor object paths via the command:</p>
<p> busctl tree xyz.openbmc_project.Power.Regulators<br>
</p>
<p>The phosphor-regulators application reads sensors once per
second. However, it only updates D-Bus if the new sensor value
has changed more than a hysteresis amount. This is to avoid
generating a bunch of D-Bus traffic for minor value changes.</p>
<p>You can see the hysteresis values here:
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/src/dbus_sensor.cpp#L66">https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/src/dbus_sensor.cpp#L66</a><br>
</p>
<blockquote type="cite" cite="mid:8C9640C9-6E1B-4495-BA55-258DA1548799@gmail.com">
<p class="MsoNormal" style="-webkit-text-size-adjust: auto;
margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p></o:p></p>
What else do I need to so that there are dbus objects?<o:p></o:p></blockquote>
<p>For bmcweb and Redfish to work, you need associations between the
D-Bus sensor and two D-Bus inventory objects:<br>
</p>
<p>* The FRU that contains the regulator. This is the replaceable
hardware item where the regulator is located. Some regulators are
FRUs by themselves (replaceable). Some are located on larger FRUs
like a motherboard. This is used to get presence, health info,
and if applicable VPD.<br></p></div></blockquote><div dir="ltr">Ah, it did not occurs to me that a mother board as FRU is wapping regulators inside an FRU. Seems obvious now.</div><blockquote type="cite"><div dir="ltr"><p>
</p>
<p>* The chassis that contains the regulator. This is required by
Redfish since it groups sensors by chassis.</p></div></blockquote>Ok</div><div dir="ltr"><br><blockquote type="cite"><div dir="ltr"><p>
</p>
<p>The phosphor-regulators application creates those associations
automatically based on information in your JSON file. The "fru"
property of the regulator "device" provides the first inventory
object path. The "inventory_path" property of the "chassis"
provides the second inventory path. Both of those are relative to
the "/xyz/openbmc_project/inventory" root path.</p>
<p>Do the "fru" and "inventory_path" properties in your JSON file
match the correct inventory object paths on your system?<o:p></o:p><br></p></div></blockquote><div dir="ltr">I have a psu.json with fruConfigs, and this has</div><div dir="ltr"><br></div><div dir="ltr">“PsuDevices”: {</div><div dir="ltr"> “/xyz/openbmc-project/inventory/system/chassis/motherboard/powersupply0” : “/sys/bus/i2c/devices/11-004f”,</div><div dir="ltr">}</div><div dir="ltr"><br></div><div dir="ltr">Which is the same i2c address as used by phosphor-regulators.</div><div dir="ltr"><br></div><div dir="ltr">And a power-supply-monitor-0.conf to match.</div><blockquote type="cite"><div dir="ltr"><p>
<o:p></o:p></p>
<blockquote type="cite" cite="mid:8C9640C9-6E1B-4495-BA55-258DA1548799@gmail.com">
<p class="MsoNormal" style="-webkit-text-size-adjust: auto;
margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;">Note
I have not done anything to intentionally use open_power. My
goal is to only use phosphor-regulators to expose some telemetry
that hwmon does not support.</p>
</blockquote>
<p>That's fine. This application does not have any dependencies on
open_power.</p>
<p>Let me know if you need more info.</p>
<p>Shawn<br>
</p>
</div></blockquote>Mike</div><div dir="ltr"><br></div></body></html>