<div dir="ltr">Greetings,<br>     I have some additional/newbie type questions here that are blocking my progress with this Proof-of-Concept.<br>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).<br><br>Sensors:<br>We’ve read through the documentation and pieced together the following:<br> -  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).<br> -  These sensors are inputs to the Linux Kernel’s hwmon sub-system.  Access is exported via sysfs entries for access by ???<br> -  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?<br> -  systemd is used to start up the various services associated with these objects, as defined in dbus.  <br> -  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.<br> -  Is there a sensor cache where polled readings are stored? It seemed to be hinted at but never stated explicitly.<br><br><br>The reason for these questions are:<br> -  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).  <br> -  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.  <br> -  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?<br> -  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?)<br><br><br>IPMI Commands:<br> -  We’ve tracked through the code and believe we’ve found the code responsible for some of the commands.  <br> -  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?<br> -  We’ve identified the following:<br>    the “openbmc” meta directory is just that:  meta-data - no code here.<br>    “ALL” code is fetched from the various GitHub repos for this project.<br>So if we wanted to modify, say phosphor-ipmi-host, we would:<br>       a) clone this repo and populate it with the code<br>      b) make the modifications necessary.<br>  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?   <br> -  Which then brought up the following question(s):<br>       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).<br>      Would we need to do this for each and every Repo we are adding and/or modifying as part of our system?<br><div>     Is there a “global” way to handle this? (Yocto documentation talks about the EXTERNALSRC capability and the .bbclass to include)</div><div><br></div><div>Regards,</div><div>Stephen Beckwith</div><div><br></div></div>