layers and adding a new system

layers and adding a new system

[Chris Austen]

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]




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 are 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 make a common change to all of the fish type.  This means
anyone adding the meta-fish layer gets this bbappend and the rainbowworms.

    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?



Chris Austen

[-- Attachment #2: Type: text/html, Size: 4284 bytes --]

Re: layers and adding a new system

[Patrick Venture]

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.

On Fri, Sep 1, 2017 at 10:27 AM, Chris Austen <austenc@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 are 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 make a common change to all of the fish type. This means
> anyone adding the meta-fish layer gets this bbappend and the rainbowworms.
>
> 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?

>
>
>
> Chris Austen
>

Re: layers and adding a new system

[Chris Austen]

[-- Attachment #1: Type: text/plain, Size: 5276 bytes --]

Chris Austen <austenc@us.ibm.com>

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

> From: Patrick Venture <venture@google.com>
> To: Chris Austen <austenc@us.ibm.com>
> Cc: OpenBMC Maillist <openbmc@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@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
> >
>

[-- Attachment #2: Type: text/html, Size: 7625 bytes --]