Ongoing Questions about OpenBMC

[Emily Shaffer]

On Mon, Nov 25, 2019 at 1:28 PM Stephen Beckwith
<embeddedsteve at gmail.com> wrote:
>
> Greetings,
>      I have some additional/newbie type questions here that are blocking my progress with this Proof-of-Concept.

Hi and welcome. I can't answer every question you have but I'll reply
where I can and hope for the community to fill in more blanks. :)

> 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.

phosphor-hwmon is responsible for most of these, yeah.

>  -  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?

During hacking, you can use 'devtool' which is used to help configure
the bitbake run. I think 'devtool modify' is what you're looking for
to ask for your local copy instead of the SRC_URI destination.

>  -  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).

As I understand it, when you write the recipe for your internal
platform (which you will need to do anyway - for example a Zaius
builds differently than a Tioga Pass) you will point the SRC_URI to
the internal branch or fork of, say, phosphor-host-ipmi. That branch
carries your patches - proprietary features that can't be upstreamed,
or hotfixes you couldn't wait for upstream to merge. Then, your
internal branch of each project should be rebased regularly against
what is happening upstream.  I'll try not to get into upstreaming best
practices, but you should keep in mind when you're checking things in
downstream that should really be sent upstream - i.e., bug fixes that
affect everyone - that your downstream branch needs to be able to cope
once those patches make it into the upstream you're rebasing against.

> Would we need to do this for each and every Repo we are adding and/or modifying as part of our system?

If there are changes from upstream, those changes have to go
somewhere, and your recipe needs to reference them. If there's no
changes from upstream but you want to include different 100%-upstream
packages, you'd change that in your recipe, AIUI.

> Is there a “global” way to handle this? (Yocto documentation talks about the EXTERNALSRC capability and the .bbclass to include)

Take it with a grain of salt from me; it's been some time since I did
much with bitbake recipes. These days I'm just a humble IPMI hospice
carer :)

 - Emily