<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<blockquote type="cite"
cite="mid:FC1C96F9-CA9C-45B8-9FF5-26CF04109852@gmail.com">
<div dir="ltr">
<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>
</blockquote>
<p>It sounds like at least part of the problem might be the systemd
service files not running. The regulators service files are
located in
<a class="moz-txt-link-freetext" href="https://github.com/openbmc/phosphor-power/tree/master/services">https://github.com/openbmc/phosphor-power/tree/master/services</a>.</p>
<p>* 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.</p>
<p>* 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).<br>
</p>
<p>* 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).</p>
<p>* phosphor-regulators-monitor-disable.service: This disables
sensor and phase fault monitoring. This should happen early when
the chassis is being powered off.</p>
<p>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?</p>
<p>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.</p>
<p>Regarding the fact the 0xDD is being read, is it possibly being
read by another application like hwmon?</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:FC1C96F9-CA9C-45B8-9FF5-26CF04109852@gmail.com">
<div dir="ltr">
<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>
<br>
</div>
</blockquote>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:FC1C96F9-CA9C-45B8-9FF5-26CF04109852@gmail.com">
<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.<br>
<br>
</div>
</div>
</blockquote>
<p>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.</p>
<p>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.).</p>
</body>
</html>