<div dir="ltr"><div>Hi Emily,</div><div> Thank you very much for your comments and suggestions. Some have have been helpful. However, I've seemed to have run into an issue with the "devtool modify" setup. Please let me explain:</div><div>I have setup what I will call an "external build" setup (which is similar to how we handle our current development). As an example:</div><div>~/home/sbeckwit/yocto_dev is the "root"</div><div><span style="font-family:monospace">├── obmc-build<br>│ ├── downloads<br>│ ├── sstate-cache<br>│ ├── tmp<br>│ └── workspace<br>├── obmc-dev<br>│ └── openbmc <span style="font-family:arial,sans-serif">This contains the openbmc git repo - all the meta, etc.</span> <br></span> </div><div>The bblaysers.conf file sits in the obmc-dev/openbmc/build/conf directory - it includes a path to the workspace directory.</div><div>There is a devtool.conf also in this obmc-dev/openbmc/build/conf directory, defines the "workspace_path" to point to the workspace directory.</div><div><br></div><div>I have tried run devtool modify from the "dev" directory (in the build directory) and also from the obmc-build directory. I've added the - - bbpath parameter as well as trying the - - basepath, in all cases I get the failure below. <br></div><div><br></div><div>Synopsis:</div><div> - The files devtool is looking for exist, in a directory in the path, but for some reason it's just not able to "figure it out". Maybe because of the external build setup?? <br></div><div> - Is this something for the Yocto team?? <br></div><div>We did an experiment with a "poky" (separate stand-alone setup we started with) and this did seem to work, but this was a "self-contained" setup, i.e. it does not use a "external build directory" setup. <br></div><div><br></div><div>You insights are greatly appreciated!</div><div><br></div><div>Regards,</div><div>Stephen Beckwith</div><div><br></div><div><br></div><div><br><span style="font-family:monospace">Initialising tasks: 100% |###########################################################| Time: 0:00:00<br>NOTE: Executing RunQueue Tasks<br>ERROR: Function failed: do_replace_entity_default (log file is located at /home/sbeckwit/yocto_dev/obmc-build/tmp</span>/work/armv6-openbmc-linux-gnueabi/phosphor-ipmi-host/1.0+gitAUTOINC+455ee0b99c-<span style="font-family:monospace">r1/devtooltmp-s45iteon/temp/log.do_patch.6941)<br>ERROR: Logfile of failure stored in: /home/sbeckwit/yocto_dev/obmc-build/tmp/work/armv6-openbmc-linux-gnueabi/phosphor-ipmi-host/1.0+gitAUTOINC+455ee0b99c-r1/devtooltmp-s45iteon/temp/log.do_patch.6941<br>Log data follows:<br>| DEBUG: Executing python function devtool_pre_patch<br>| DEBUG: Python function devtool_pre_patch finished<br>| DEBUG: Executing python function patch_task_patch_prefunc<br>| DEBUG: Python function patch_task_patch_prefunc finished<br>| DEBUG: Executing python function extend_recipe_sysroot<br>| NOTE: Direct dependencies are []<br>| NOTE: Installed into sysroot: []<br>| NOTE: Skipping as already exists in sysroot: []<br>| DEBUG: Python function extend_recipe_sysroot finished<br>| DEBUG: Executing python function do_patch<br>| DEBUG: Executing python function patch_do_patch<br></span><br>File being looked for in the output: - yet these are IN the specified directory that is in the path list:<br><br><span style="font-family:monospace">| DEBUG: Searching for entity.yaml in paths:<br>| DEBUG: Searching for merge_yamls.py in paths:<br>| DEBUG: Searching for xyz.openbmc_project.Ipmi.Internal.SoftPowerOff.service in paths:<br>| DEBUG: Searching for phosphor-ipmi-host.service in paths:<br></span><br>==> This path shows up in each of the 4 sets of files listed for each of the searches above.<br><br><b><span style="font-family:monospace">| /home/sbeckwit/yocto_dev/obmc-dev/openbmc/meta-phosphor/recipes-phosphor/ipmi/phosphor-ipmi-host/<br></span></b><br>| DEBU<span style="font-family:monospace">G: Python function patch_do_patch finished<br>| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']<br>| DEBUG: Executing shell function do_replace_entity_default<br>| cp: cannot stat 'entity.yaml': No such file or directory<br>| WARNING: exit code 1 from a shell command.<br>| DEBUG: Python function do_patch finished<br>| ERROR: Function failed: do_replace_entity_default (log file is located at /home/sbeckwit/yocto_dev/obmc-build/tmp/work/armv6-openbmc-linux-gnueabi/phosphor-ipmi-host/1.0+gitAUTOINC+455ee0b99c-r1/devtooltmp-s45iteon/temp/log.do_patch.6941)<br>NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and 1 failed.<br>ERROR: Extracting source for phosphor-ipmi-host failed<br></span><br><b><span style="font-family:monospace">sbeckwit@ubuntu:~/yocto_dev/obmc-dev/openbmc/meta-phosphor/recipes-phosphor/ipmi/phosphor-ipmi-host$ ls<br>entity.yaml phosphor-ipmi-host.service<br>merge_yamls.py xyz.openbmc_project.Ipmi.Internal.SoftPowerOff.service<br></span></b><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 25, 2019 at 4:43 PM Emily Shaffer <<a href="mailto:emilyshaffer@google.com">emilyshaffer@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Nov 25, 2019 at 1:41 PM Emily Shaffer <<a href="mailto:emilyshaffer@google.com" target="_blank">emilyshaffer@google.com</a>> wrote:<br>
><br>
> On Mon, Nov 25, 2019 at 1:28 PM Stephen Beckwith<br>
> <<a href="mailto:embeddedsteve@gmail.com" target="_blank">embeddedsteve@gmail.com</a>> wrote:<br>
> ><br>
> > Greetings,<br>
> > I have some additional/newbie type questions here that are blocking my progress with this Proof-of-Concept.<br>
><br>
> Hi and welcome. I can't answer every question you have but I'll reply<br>
> where I can and hope for the community to fill in more blanks. :)<br>
><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>
><br>
> phosphor-hwmon is responsible for most of these, yeah.<br>
><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>
<br>
Ah, I skimmed in my first pass and neglected this. It's likely that<br>
this sensor isn't in your sensor list yaml, which IPMI draws on. See<br>
<a href="https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/sensor-example.yaml" rel="noreferrer" target="_blank">https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/sensor-example.yaml</a>.<br>
<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>
><br>
> During hacking, you can use 'devtool' which is used to help configure<br>
> the bitbake run. I think 'devtool modify' is what you're looking for<br>
> to ask for your local copy instead of the SRC_URI destination.<br>
><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>
><br>
> As I understand it, when you write the recipe for your internal<br>
> platform (which you will need to do anyway - for example a Zaius<br>
> builds differently than a Tioga Pass) you will point the SRC_URI to<br>
> the internal branch or fork of, say, phosphor-host-ipmi. That branch<br>
> carries your patches - proprietary features that can't be upstreamed,<br>
> or hotfixes you couldn't wait for upstream to merge. Then, your<br>
> internal branch of each project should be rebased regularly against<br>
> what is happening upstream. I'll try not to get into upstreaming best<br>
> practices, but you should keep in mind when you're checking things in<br>
> downstream that should really be sent upstream - i.e., bug fixes that<br>
> affect everyone - that your downstream branch needs to be able to cope<br>
> once those patches make it into the upstream you're rebasing against.<br>
><br>
> > Would we need to do this for each and every Repo we are adding and/or modifying as part of our system?<br>
><br>
> If there are changes from upstream, those changes have to go<br>
> somewhere, and your recipe needs to reference them. If there's no<br>
> changes from upstream but you want to include different 100%-upstream<br>
> packages, you'd change that in your recipe, AIUI.<br>
><br>
> > Is there a “global” way to handle this? (Yocto documentation talks about the EXTERNALSRC capability and the .bbclass to include)<br>
><br>
> Take it with a grain of salt from me; it's been some time since I did<br>
> much with bitbake recipes. These days I'm just a humble IPMI hospice<br>
> carer :)<br>
><br>
> - Emily<br>
</blockquote></div>