=EF=BB=BF =20 =20 =20

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=E2=80=99t 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-pow= er/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

=E2=80=9CPsuDevices=E2=80=9D: {

=E2=80=9C/xyz/openbmc-project/inventory/system/chassis/motherboard= /powersupply0=E2=80=9D : =E2=80=9C/sys/bus/i2c/devices/11-004f=E2=80=9D,

}

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. S= o 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 ter= m '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.).

=20