layers and adding a new system

[Chris Austen]

Chris Austen <austenc at us.ibm.com>

> Patrick Venture <venture at google.com> wrote on 09/01/2017 02:35:46 PM:

> From: Patrick Venture <venture at google.com>
> To: Chris Austen <austenc at us.ibm.com>
> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
> Date: 09/01/2017 02:36 PM
> Subject: Re: layers and adding a new system
>
> Chris;
>
> I think this is valuable to point out -- and especially the value of
> MACHINE_OVERRIDES.  Because Google is building OpenBMC from a single
> bblayer file, all the recipes we pickup need specific overrides.  So
> it might be worth emphasizing the danger a little more that even
> things in a separate folder that is machine specific may get picked up
> depending on how things are organized.

The results in my testing really surprised me but I think I understand
why it is that way.  It's likely a lot more common for all the machines
in a bb file to need the same SRC files and append more if there is a
specific machine addition.

yeah organization is key.  It almost feels like the meta-machines could
use another layer.  A hardware layer that defines the base set of
hardware and then another layer where organizations can add their tweaks.

Since Zaius specs are in OCP it only makes sense that others would want
to create similar work and as such the OCP Zaius reference could in
theory be its own meta.  The danger of course is when there is a reference
board change... all users of the layer are effected.

I know it's difficult.  There's no math formula that declares something
is different enough to create a new reference meta.  There's just us
firmware engineers making hardware do our bidding via the principals of
computer science.


>
> On Fri, Sep 1, 2017 at 10:27 AM, Chris Austen <austenc at us.ibm.com> wrote:
> > As the popularity of OpenBMC grows the project will hopefully find
itself
> > with additional pull requests to support more systems. As I did when I
first
> > started out you could easily be allured to simply copy/past the entire
> > contents of a similar system under meta-openbmc-machines/... and call
it
> > your own. However scale that to anything greater then a few machines
and the
> > shier volume of duplicate code will become bulky and unmanageable.
Yocto
> > recognized this as an issue and has provided support to reduce. I would
like
> > to build a list of recommendations on how to add new hardware in to the
> > OpenBMC Project.
> >
> >
> > For hardware based on a similar design this is...
> >
> > Not good
> > ========
> > meta-mfg/meta-redfish/
> > meta-mfg/meta-bluefish/
> > meta-mfg/meta-yellowfish/
> > meta-mfg/meta-greenfish/
> >
> >
> > Good
> > ========
> > meta-mfg/meta-fish/
> >
> >
> > So how can you do that? With a single variable in your local.conf...
> > MACHINE. You change the MACHINE variable per system type but let
default and
> > use the base platform for common items.
> >
> > MACHINE = "bluefish"
> >
> > A bbappend that is specific to the bluefish system; you append the
_bluefish
> >
> > FILESEXTRAPATHS_prepend_bluefish := "${THISDIR}/${PN}:"
> > SRC_URI_append_bluefish = " file://0001-blueworms.patch"
> >
> > A bbappend that makes a common change to all of the fish type. This
means
> > anyone adding the meta-fish layer gets this bbappend and the
rainbowworms.
> >

This is where the benefit of a reference layer helps the community.  One
person
finds a hardware issue and everyone gets the fix.

> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > SRC_URI_append = " file://0001-rainbowworms.patch"
> >
> > Machine and default are all good until If you use a bluefish system but
you
> > have a company policy use the MACHINEOVERRIDES variable
> >
> > FILESEXTRAPATHS_prepend_orgXfis := "${THISDIR}/${PN}:"
> > SRC_URI_append_orgXfis = " file://0001-blueXworms.patch"
> >
> > Note yocto matches and runs every hit. That means if you add a default,
> > machine and machine override in the same bbappend, you get all three
files.
> > So use with caution...
> >
> > FILESEXTRAPATHS_prepend_orgXfis := "${THISDIR}/${PN}:"
> > SRC_URI_append_orgXfis = " file://0001-blueXworms.patch"
> > SRC_URI_append = " file://0001-rainbowworms.patch"
> > SRC_URI_append_bluefish = " file://0001-blueworms.patch"
> >
> > $ ls
> > 0001-blueXworms.patch
> > 0001-rainbowworms.patch
> > 0001-blueworms.patch
> >
> >
> > TBD.. need to add example of something being added, replaced and kernel
> > device tree needs.
> >
> >
> > Thoughts?
>
> There is an effort to write up some system component bring-up with
> OpenBMC, that's already had some results -- configuring LEDs.  By
> adding something, are you referring to adding a new system's
> configuration or a new package to OpenBMC?
>

I'd like to create some examples where a system configuration deviates from
the reference.  LEDs could be it or the reference uses PWM while another
similar system uses an i2c device.  I think if we don't start discussing
best practices here we will see different approaches and confused gerrit
responses

Adding an example of another package or even replacing a package is a
good thing to have documented too.

> >
> >
> >
> > Chris Austen
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170901/6f2b3df8/attachment.html>