<html><body><p><font size="2">Chris Austen <austenc@us.ibm.com> </font><br><br><tt><font size="2">> Patrick Venture <venture@google.com> wrote on 09/01/2017 02:35:46 PM:<br><br>> From: Patrick Venture <venture@google.com></font></tt><br><tt><font size="2">> To: Chris Austen <austenc@us.ibm.com></font></tt><br><tt><font size="2">> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org></font></tt><br><tt><font size="2">> Date: 09/01/2017 02:36 PM</font></tt><br><tt><font size="2">> Subject: Re: layers and adding a new system</font></tt><br><tt><font size="2">> <br>> Chris;<br>> <br>> I think this is valuable to point out -- and especially the value of<br>> MACHINE_OVERRIDES. Because Google is building OpenBMC from a single<br>> bblayer file, all the recipes we pickup need specific overrides. So<br>> it might be worth emphasizing the danger a little more that even<br>> things in a separate folder that is machine specific may get picked up<br>> depending on how things are organized.<br></font></tt><br><tt><font size="2">The results in my testing really surprised me but I think I understand</font></tt><br><tt><font size="2">why it is that way. It's likely a lot more common for all the machines</font></tt><br><tt><font size="2">in a bb file to need the same SRC files and append more if there is a </font></tt><br><tt><font size="2">specific machine addition.</font></tt><br><br><tt><font size="2">yeah organization is key. It almost feels like the meta-machines could </font></tt><br><tt><font size="2">use another layer. A hardware layer that defines the base set of </font></tt><br><tt><font size="2">hardware and then another layer where organizations can add their tweaks.</font></tt><br><br><tt><font size="2">Since Zaius specs are in OCP it only makes sense that others would want</font></tt><br><tt><font size="2">to create similar work and as such the OCP Zaius reference could in </font></tt><br><tt><font size="2">theory be its own meta. The danger of course is when there is a reference</font></tt><br><tt><font size="2">board change... all users of the layer are effected.</font></tt><br><br><tt><font size="2">I know it's difficult. There's no math formula that declares something </font></tt><br><tt><font size="2">is different enough to create a new reference meta. There's just us </font></tt><br><tt><font size="2">firmware engineers making hardware do our bidding via the principals of </font></tt><br><tt><font size="2">computer science.</font></tt><br><br><br><tt><font size="2">> <br>> On Fri, Sep 1, 2017 at 10:27 AM, Chris Austen <austenc@us.ibm.com> wrote:<br>> > As the popularity of OpenBMC grows the project will hopefully find itself<br>> > with additional pull requests to support more systems. As I did when I first<br>> > started out you could easily be allured to simply copy/past the entire<br>> > contents of a similar system under meta-openbmc-machines/... and call it<br>> > your own. However scale that to anything greater then a few machines and the<br>> > shier volume of duplicate code will become bulky and unmanageable. Yocto<br>> > recognized this as an issue and has provided support to reduce. I would like<br>> > to build a list of recommendations on how to add new hardware in to the<br>> > OpenBMC Project.<br>> ><br>> ><br>> > For hardware based on a similar design this is...<br>> ><br>> > Not good<br>> > ========<br>> > meta-mfg/meta-redfish/<br>> > meta-mfg/meta-bluefish/<br>> > meta-mfg/meta-yellowfish/<br>> > meta-mfg/meta-greenfish/<br>> ><br>> ><br>> > Good<br>> > ========<br>> > meta-mfg/meta-fish/<br>> ><br>> ><br>> > So how can you do that? With a single variable in your local.conf...<br>> > MACHINE. You change the MACHINE variable per system type but let default and<br>> > use the base platform for common items.<br>> ><br>> > MACHINE = "bluefish"<br>> ><br>> > A bbappend that is specific to the bluefish system; you append the _bluefish<br>> ><br>> > FILESEXTRAPATHS_prepend_bluefish := "${THISDIR}/${PN}:"<br>> > SRC_URI_append_bluefish = " <a href="file://0001-blueworms.patch">file://0001-blueworms.patch</a>"<br>> ><br>> > A bbappend that makes a common change to all of the fish type. This means<br>> > anyone adding the meta-fish layer gets this bbappend and the rainbowworms.<br>> ><br></font></tt><br><tt><font size="2">This is where the benefit of a reference layer helps the community. One person</font></tt><br><tt><font size="2">finds a hardware issue and everyone gets the fix. </font></tt><br><br><tt><font size="2">> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"<br>> > SRC_URI_append = " <a href="file://0001-rainbowworms.patch">file://0001-rainbowworms.patch</a>"<br>> ><br>> > Machine and default are all good until If you use a bluefish system but you<br>> > have a company policy use the MACHINEOVERRIDES variable<br>> ><br>> > FILESEXTRAPATHS_prepend_orgXfis := "${THISDIR}/${PN}:"<br>> > SRC_URI_append_orgXfis = " <a href="file://0001-blueXworms.patch">file://0001-blueXworms.patch</a>"<br>> ><br>> > Note yocto matches and runs every hit. That means if you add a default,<br>> > machine and machine override in the same bbappend, you get all three files.<br>> > So use with caution...<br>> ><br>> > FILESEXTRAPATHS_prepend_orgXfis := "${THISDIR}/${PN}:"<br>> > SRC_URI_append_orgXfis = " <a href="file://0001-blueXworms.patch">file://0001-blueXworms.patch</a>"<br>> > SRC_URI_append = " <a href="file://0001-rainbowworms.patch">file://0001-rainbowworms.patch</a>"<br>> > SRC_URI_append_bluefish = " <a href="file://0001-blueworms.patch">file://0001-blueworms.patch</a>"<br>> ><br>> > $ ls<br>> > 0001-blueXworms.patch<br>> > 0001-rainbowworms.patch<br>> > 0001-blueworms.patch<br>> ><br>> ><br>> > TBD.. need to add example of something being added, replaced and kernel<br>> > device tree needs.<br>> ><br>> ><br>> > Thoughts?<br>> <br>> There is an effort to write up some system component bring-up with<br>> OpenBMC, that's already had some results -- configuring LEDs. By<br>> adding something, are you referring to adding a new system's<br>> configuration or a new package to OpenBMC?<br>> <br></font></tt><br><tt><font size="2">I'd like to create some examples where a system configuration deviates from</font></tt><br><tt><font size="2">the reference. LEDs could be it or the reference uses PWM while another </font></tt><br><tt><font size="2">similar system uses an i2c device. I think if we don't start discussing </font></tt><br><tt><font size="2">best practices here we will see different approaches and confused gerrit </font></tt><br><tt><font size="2">responses </font></tt><br><br><tt><font size="2">Adding an example of another package or even replacing a package is a </font></tt><br><tt><font size="2">good thing to have documented too.</font></tt><br><br><tt><font size="2">> ><br>> ><br>> ><br>> > Chris Austen<br>> ><br>> <br></font></tt><BR>
</body></html>