No dbus objects for phosphor-regulators

[Shawn McCarney]

Hi Mike,

> I made a config file below, and verified that it is on the target and 
> loads without error.

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?

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?

> 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.
>
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.

Does the 'journalctl | grep -i Regulators' show that the service files 
are being executed that enable and disable regulator sensor monitoring?

> 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.
>
Since you are reading a vout sensor for the rail named "vdd", the 
resulting D-Bus object path for the sensor should be

   /xyz/openbmc_project/sensors/voltage/vdd_vout

See 
https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/docs/config_file/pmbus_read_sensor.md#d-bus-sensor 
for more details.

Does that object path exist on D-Bus after you've powered on the chassis 
and sensor monitoring has been enabled?

You can see all the properties of the D-Bus sensor using the command

   busctl introspect xyz.openbmc_project.Power.Regulators 
/xyz/openbmc_project/sensors/voltage/vdd_vout

You can see all regulator sensor object paths via the command:

   busctl tree xyz.openbmc_project.Power.Regulators

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.

You can see the hysteresis values here: 
https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/src/dbus_sensor.cpp#L66

> What else do I need to so that there are dbus objects?

For bmcweb and Redfish to work, you need associations between the D-Bus 
sensor and two D-Bus inventory objects:

* 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.

* The chassis that contains the regulator.  This is required by Redfish 
since it groups sensors by chassis.

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.

Do the "fru" and "inventory_path" properties in your JSON file match the 
correct inventory object paths on your system?

> 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.
>
That's fine.  This application does not have any dependencies on open_power.

Let me know if you need more info.

Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220126/1a303165/attachment.htm>