How to put sensors into the ObjectMapper

How to put sensors into the ObjectMapper

[Mike Jones]

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

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@7e804000/ltc2974@32/regulators/vout0 to vout3

And the config files like this path:

/etc/default/obmc/hwmon/soc/i2c#7e804000/ltc2974@32/reg1@32.conf <mailto:32/reg1@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?
- Once there, will they show up in webui without any other files and recipes?
- What docs might describe what I need to know to connect the hwmon devices to the ObjectMapper?
- Is there something I have to do to start the ObjectMapper service? I don’t see it with a grep through systemctl.
- Is there an existing meta layer that would be a good example and a pointer to the proper bb files to look at?

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

[-- Attachment #2: Type: text/html, Size: 3787 bytes --]

Re: How to put sensors into the ObjectMapper

[Matt Spinler]

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@7e804000/ltc2974@32/regulators/vout0 
> to vout3
>
> And the config files like this path:
>
> /etc/default/obmc/hwmon/soc/i2c#7e804000/ltc2974@32/reg1@32.conf 
> <mailto:32/reg1@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 
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
>
> Configured by:
>
> 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

Re: How to put sensors into the ObjectMapper

[Mike Jones]

[-- Attachment #1: Type: text/plain, Size: 7453 bytes --]

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@7e804000/ltc3880@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@-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@.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@.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@.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@.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@7e804000/ltc3880@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@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@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@7e804000/ltc2974@32/regulators/vout0 to vout3
>> 
>> And the config files like this path:
>> 
>> /etc/default/obmc/hwmon/soc/i2c#7e804000/ltc2974@32/reg1@32.conf <mailto:32/reg1@32.conf> <mailto:32/reg1@32.conf <mailto:32/reg1@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


[-- Attachment #2: Type: text/html, Size: 27148 bytes --]

Re: How to put sensors into the ObjectMapper

[Mike Jones]

[-- Attachment #1: Type: text/plain, Size: 8396 bytes --]

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@.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@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@7e804000/ltc3880@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@-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@.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@.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@.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@.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@7e804000/ltc3880@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@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@linux.ibm.com <mailto:mspinler@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@7e804000/ltc2974@32/regulators/vout0 to vout3
>>> 
>>> And the config files like this path:
>>> 
>>> /etc/default/obmc/hwmon/soc/i2c#7e804000/ltc2974@32/reg1@32.conf <mailto:32/reg1@32.conf> <mailto:32/reg1@32.conf <mailto:32/reg1@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
> 


[-- Attachment #2: Type: text/html, Size: 28780 bytes --]