How to put sensors into the ObjectMapper

Mike Jones proclivis at gmail.com
Thu Aug 6 06:01:41 AEST 2020 

Matt,

I figured this out. For those after me:

> the-date raspberrypi4 systemd[1]: Condition check resulted in Phosphor Hwmon Poller being skipped.

This error comes from ConditionFileNotEmpty=/etc/default/objc/hwmon/%I.conf

In file xyz.openbmc_project.Hwmon at .service

By looking at the code for phosphor-hwmon-readd and running it on a command line, I eventually realized the conf files needed to be one directory higher and named differently.

Now I have telemetry in the webui.

I pushed my code for anyone that is following along.

Mike

> On Aug 4, 2020, at 6:09 PM, Mike Jones <proclivis at gmail.com> wrote:
> 
> Matt,
> 
> Thanks for the help, I wish this was less painful. I think I know how this is supposed to work, but it does not. So I will walk through all the steps I took to manually debug, and hopefully you see a smoking gun. It could be as simple as the service makes some path assumption that does not hold when using raspberrypi’s hwmon paths which uses soc rather than ahb paths on an aspeed.
> 
> Sensors/phosphor-hwm adds 70-hwmon.rules and start_hwmon.sh.
> 
> These are on the target file system.
> 
> Then I tried to test starting Hwmon service manually like this:
> 
> udevadm info /sys/bus/i2c/devices/1-0030
> 
> Then using the variables…
> 
> /usr/bin/start_hwmon.sh start /devices/platform/soc/fe804000.i2c/i2c-1/1-0030 /soc/i2c at 7e804000/ltc3880 at 30
> 
> And a dbus query has no sensors. There is no process with hwmon in the name, and systemctl has nothing with hwmon either.
> 
> So I edit start_hwmon.sh to print the values and run the command manually:
> 
> systemctl —no-block start xyz.openbmc_project.Hwmon at -soc-i2c\x407e804000-ltc3880\x4030.service
> 
> Now, I am low on how the services use the @.
> 
> In sensors/phosphor-hwmon is xyz.openbmc_project.Hwmon at .service
> 
> I am assuming that text after the @ is a way of naming an instance of the service, so that one service can be run per device. Perhaps you can confirm that.
> 
> In /lib/systed/system I find the xyz.openbmc_project.Hwmon at .service
> 
> I assume that if this service was running, ps and systemctl would show it. So perhaps it runs and exits. So I use
> 
> Systemctl status  xyz.openbmc_project.Hwmon at .service
> 
> And see it calls it Phosphor Hwmon Poller, says it is loaded and lists a file:// long path to the service, static, vendor preset: enabled. But it also shows
> 
> Active:inactive (dead)
> 
> The some lines like:
> 
> the-date raspberrypi4 systemd[1]: Condition check resulted in Phosphor Hwmon Poller being skipped.
> 
> If I had to guess, it can’f find something in the /sys path.
> 
> journalctl -u  xyz.openbmc_project.Hwmon at .service gives the same messages.
> 
> So going back to the start_hwmon.sh
> 
> The udev variables are:
> 
> DEVPATH = /devices/platform/soc/fe804000.i2c/i2c-1/1-0030
> OF_FULLNAME = /soc/i2c at 7e804000/ltc3880 at 30
> 
> The start script cooks up this service name @-soc-i2c\x407e804000-ltc3880\x4030.service
> 
> Which is escaping OF_FULLNAME @ and replacing / with -
> 
> I assume the service uses that to go a hunting for the hwmon device and hopefully it knows to look in /sys/devices/platform/soc/fe804000.i2c/i2c-1/1-0030, which is really a directory to hwmon. That would mean the service has to know to look in /sys/devices/platform, because that is not passed to the service.
> 
> I noticed that the service file is really a configuration file. So I cat it out.
> 
> It has a ConditionFileNotEmpty=/etc/default/obmc/hwmon/%I.conf
> 
> This is the parent with child soc… to the conf files. So I should be a proper path. So I compare that path to the service name path to see if they match in any way.
> 
> The path to this device is
> 
> soc/i2c/@7e804000/ltc3880 at 30
> 
> So its a match with the name of the service. That looks good.
> 
> Then it seems to run
> 
> /usr/bin/env phosphor-hwmon-readd -o $I
> With SyslogIdentifier phosphor-hwmon-readd
> 
> I assume that the errors from the status somehow are consuming this Syslog.
> 
> So perhaps this comes down to the meaning of
> 
> the-date raspberrypi4 systemd[1]: Condition check resulted in Phosphor Hwmon Poller being skipped.
> 
> A google search seems to indicate this is a systemd message and is applied to disk checks, etc.
> 
> Any ideas on how to debug, or what might be amiss?
> 
> Also, I searched the source tree for phosphor-hwmon-readd* and come up empty. So I am not sure how to find the source for this. It does end up on the rootfs, so something is building. The name of the sources must be different. So I could not look in code to see how it does its job when it is run.
> 
> Mike
> 
> 
> 
>> On Aug 4, 2020, at 1:54 PM, Matt Spinler <mspinler at linux.ibm.com <mailto:mspinler at linux.ibm.com>> wrote:
>> 
>> 
>> 
>> On 8/3/2020 1:03 PM, Mike Jones wrote:
>>> My RaspPi work has progressed but I don’t know how to get sensors in the ObjectMapper, which I hope will mean sensors end up in webui.
>>> 
>>> BASIC INFORMATION
>>> ------------------------------
>>> 
>>> At this point, I have my PMbus devices in the device tree like this path:
>>> 
>>> /sys/firmware/devicetree/base/soc/i2c at 7e804000/ltc2974 at 32/regulators/vout0 to vout3
>>> 
>>> And the config files like this path:
>>> 
>>> /etc/default/obmc/hwmon/soc/i2c#7e804000/ltc2974 at 32/reg1 at 32.conf <mailto:32/reg1 at 32.conf> <mailto:32/reg1 at 32.conf <mailto:32/reg1 at 32.conf>>
>>> 
>>> The sensors show up here:
>>> 
>>> /sys/bus/i2c/devices/1-0032/hwmon/hwmon2
>>> 
>>> Indicating that the device tree is causing hwmon to offer its telemetry nodes.
>>> 
>>> From my reading of the docs, it seems like the ObjectMapper keeps an inventory of sensors.
>>> 
>>> So to search, I did something like:
>>> 
>>> dbus-send —system -print-reply \
>>> —dest=xyz.openbmc_project.ObjectMapper \
>>> /xyz/openbmc_project/object_mapper \
>>> xyz.openbmc_project.ObjectMapper.GetAncestors \
>>> string:”/xyz/openbmc_project/inventory.system” array:string: | grep ltc2974
>>> 
>>> But none of my devices are there.
>>> 
>>> I looked at meta-ibm and meta-hxt and could not see how to get the devices into the ObjectMapper.
>>> 
>>> ACTUAL QUESTIONS
>>> ------------------------------
>>> 
>>> So I have these questions:
>>> 
>>> - What it the mechanism for getting these into the ObjectMapper?
>> 
>> Hi,
>> The mapper just adds some convenience functions to be able to find things on D-Bus, so if the mapper
>> can't find it, then it isn't on D-Bus.
>> 
>> https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md <https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md> talks about how
>> phosphor-hwmon-readd will put sensor values on D-Bus.  What I don't think it mentions is that it
>> uses a udev rule to start its service when udev sees the hwmon subsystem hotplug.
>> 
>>> - Once there, will they show up in webui without any other files and recipes?
>> 
>> Yea, they will show up as /xyz/openbmc_project/sensors/<type>/<name> and bmcweb can find that.
>> 
>>> - What docs might describe what I need to know to connect the hwmon devices to the ObjectMapper?
>> 
>> That sensors doc I mentioned above has the goal of describing that.
>> 
>>> - Is there something I have to do to start the ObjectMapper service? I don’t see it with a grep through systemctl.
>> 
>> The service file for that is /lib/systemd/system/xyz.openbmc_project.ObjectMapper.service. Hopefully
>> that is present on your system.
>> 
>>> - Is there an existing meta layer that would be a good example and a pointer to the proper bb files to look at?
>> 
>> The meta-ibm layer makes extensive use of phosphor-hwmon:
>> meta-ibm/recipes-phoshpor/sensors/phosphor-hwmon_%.bbappend
>> 
>>> 
>>> THE CODE/LAYERS
>>> ----------------------------
>>> 
>>> My work so far is here:
>>> 
>>> https://github.com/Proclivis/meta-pmbus <https://github.com/Proclivis/meta-pmbus>
>>> 
>>> Configured by:
>>> 
>>> https://github.com/Proclivis/conf-meta-rasberrypi-evb <https://github.com/Proclivis/conf-meta-rasberrypi-evb>
>>> 
>>> Thanks, and sorry I am a newbie without tribal knowledge. I am trying to find solutions on my own and only ask for help when stuck. Unfortunately, I’m stuck.
>>> 
>>> Mike
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200805/4acbf651/attachment-0001.htm>

More information about the openbmc mailing list