Ongoing Questions about OpenBMC

[Stephen Beckwith]

Greetings,
     I have some additional/newbie type questions here that are blocking my
progress with this Proof-of-Concept.
We currently have an OpenBMC image booting in QEMU (version 4.1.0) and have
been investigating certain aspects of this image, namely IPMI command
support and sensors, as these are 2 areas we will need to modify prior to
porting this onto our target platform. (AST2500 based).

Sensors:
We’ve read through the documentation and pieced together the following:
 -  Sensors get defined in the DTS file, which is “consumed” by the Linux
kernel.  This defines the physical device’s aspects (i.e. on which I2C bus
at what address).
 -  These sensors are inputs to the Linux Kernel’s hwmon sub-system.
Access is exported via sysfs entries for access by ???
 -  There are some .conf and .yaml files that contain the
limits/ranges/properties for these devices. This information is
“initialized” (?) into dbus objects, where the name of the sensor’s
configuration file is the exported sysfs name, correct?
 -  systemd is used to start up the various services associated with these
objects, as defined in dbus.
 -  It was stated on the documentation that the sensors become “objects”
that will broadcast their state change on the dbus for others to know about
this change.  What is it that “detects” this change?  An interrupt from the
Sensors? (which seems odd to me, in my 30+ years, I’ve not seen too many
temp sensors that are interrupt driven).  Are these objects polled?  By
whom?  Our best guess so far seems to indicate that the phosphor-hwmon
service is what polls these.
 -  Is there a sensor cache where polled readings are stored? It seemed to
be hinted at but never stated explicitly.


The reason for these questions are:
 -  In poking around the image loaded in QEMU, we don’t seem to be seeing
any Sensor updates occurring.  We would like to be able to “stub” these for
simulation purposes, as we need to add in all of the platform sensors we
need to monitor (~ 100).
 -  There is an lm75 defined.  It shows up in the sysfs.  However, it does
not show up in the IPMI listing of the sensors or on the dbus.
 -  It seems that maybe the sensor monitoring is not running?  Could it be
that some service is not being started, due to this being QEMU?  Any
insights on this?
 -  If this is simply a limitation of Qemu, is there a recommended
method/scheme to handle the “stubbing” of sensors?  (i.e. running a
background script that writes to the sysfs entries to periodically change
the readings?)


IPMI Commands:
 -  We’ve tracked through the code and believe we’ve found the code
responsible for some of the commands.
 -  As an experiment, we’d like to modify this source code accordingly to
verify this is the code executing the command.  This then brought up the
question:  How is this done?
 -  We’ve identified the following:
the “openbmc” meta directory is just that:  meta-data - no code here.
“ALL” code is fetched from the various GitHub repos for this project.
So if we wanted to modify, say phosphor-ipmi-host, we would:
a) clone this repo and populate it with the code
b) make the modifications necessary.
c) How then to tell the build system to use this modified code for the
build?  Modify the bitbake recipe in the meta- directory to point the
SRC_URI here?
 -  Which then brought up the following question(s):
How does one go about adding in new code in this setup?  (assuming that
we’re NOT just trying to append to existing functionality, but adding
entirely new proprietary functionality to the system both inside our layer
and in other repos).
Would we need to do this for each and every Repo we are adding and/or
modifying as part of our system?
Is there a “global” way to handle this? (Yocto documentation talks about
the EXTERNALSRC capability and the .bbclass to include)

Regards,
Stephen Beckwith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191125/7b16e6b5/attachment-0001.htm>