No dbus objects for phosphor-regulators

[Shawn McCarney]

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

It sounds like at least part of the problem might be the systemd service 
files not running.  The regulators service files are located in 
https://github.com/openbmc/phosphor-power/tree/master/services.

* phosphor-regulators.service:  This one launches the regulators app.  
This must be happening since you are a getting journal message about it 
loading the JSON config file.

* phosphor-regulators-config.service:  This is what causes the 
configuration entries to be executed in the JSON file.  This should 
happen early in the process of powering on the chassis before the 
regulators have received power (been enabled).

* phosphor-regulators-monitor-enable.service:  This enables sensor and 
phase fault monitoring.  This should happen during the chassis power on 
after the regulators have received power (been enabled).

* phosphor-regulators-monitor-disable.service:  This disables sensor and 
phase fault monitoring.  This should happen early when the chassis is 
being powered off.

Sounds like maybe the last 3 service files are being run?  You can tell 
for sure by looking in the journal (e.g. 'journalctl | grep -i 
regulator').  The Wants/Before/After dependencies in the files determine 
when they are run.  Perhaps the systemd targets they are dependent on 
aren't running on your system?

You can manually cause the regulators application to perform 
configuration and sensor monitoring using the 'regsctl' program. Look at 
the service files to see the proper regsctl command to use.  This is an 
implementation detail and could change in the future, but it may help 
with debugging right now.

Regarding the fact the 0xDD is being read, is it possibly being read by 
another application like hwmon?

Note that the phosphor-regulators application does direct I2C reads and 
writes using the i2c-dev subsystem.  This is the same code path as 
i2cget/i2cset.  This means it should not be used in conjunction with a 
device driver on the regulator.  Otherwise there may be interleaved I2C 
commands going to the device, which can be problematic.

>
> 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?
>
Sorry, I'm not very familiar with that.  Others on this list could help 
more with that as a separate question thread.  I use the 'obmcutil 
chassison' command.  Since that is a script, you could check out what it 
is doing and see if that would help.

>
>> 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?
>>
> I have a psu.json with fruConfigs, and this has
>
> “PsuDevices”: {
> “/xyz/openbmc-project/inventory/system/chassis/motherboard/powersupply0” 
> : “/sys/bus/i2c/devices/11-004f”,
> }
>
> Which is the same i2c address as used by phosphor-regulators.
>
> And a power-supply-monitor-0.conf to match.
>
It sounds like you are using a power supply application from the same 
repository.  That is no problem, but they are completely separate 
applications that do no share any data/functionality.  So I don't think 
the work you've done with the PSU app would impact the regulators app.

It may be a typo above, but a voltage regulator would not normally be at 
the same I2C address as a power supply.  The term 'power supply' in that 
repo means the device that converts AC/DC wall power to 12V DC to the 
system (e.g. the big brick).  The term 'voltage regulator' means the 
devices that step 12V DC from the power supply down to the levels needed 
by system components (like 3.3V, 1.1V, etc.).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220201/9a7239d7/attachment.htm>