[PATCH openbmc 09/10] AST2500: Initial AST2500 BSP layer

[Brad Bishop]

On Mon, 2016-06-06 at 11:49 +0930, Andrew Jeffery wrote:
> On Sat, 2016-06-04 at 00:20 -0500, OpenBMC Patches wrote:
> >  5 files changed, 132 insertions(+)
> >  create mode 100644 meta-openbmc-bsp/meta-aspeed/meta-ast2500/conf/layer.conf
> >  create mode 100644 meta-openbmc-bsp/meta-aspeed/meta-ast2500/conf/machine/include/ast2500.inc
> >  create mode 100644 meta-openbmc-bsp/meta-aspeed/meta-ast2500/recipes-kernel/linux/linux-obmc/defconfig
> >  create mode 100644 meta-openbmc-bsp/meta-aspeed/meta-ast2500/recipes-kernel/linux/linux-obmc_%.bbappend
> >  create mode 100644 meta-openbmc-bsp/meta-aspeed/meta-ast2500/recipes.txt
> 
> This might show my ignorance of Yocto, but what drives us to structure
> the repository this way? Specifically, why are we nesting meta-aspeed

I think openbmc in the name meta-openbmc-bsp might be getting in the way
here.  Technically once upstream uboot/kernel support these chips there
isn't anything preventing anyone from using these outside of the openbmc
project.

Another thing to keep in mind as you contemplate this is that at the
moment meta-openbmc-bsp and meta-openbmc-machines are git subtrees in
the openbmc repository.

In my head the endgame would be some SOC vendor repositories hosted
upstream @ yoctoproject.org (they already do this with intel/freescale)
and OpenBMC just pulls those layers in.

> under meta-openbmc-bsp? Whilst OpenBMC is heavily centred around the
> Aspeed SoCs, in general Aspeed SoCs are used by more than OpenBMC. It
> feels like the OOP inheritance vs composition problem. Is that a fair
> analogy? If so, should we try to flatten out this hierarchy a bit?





> 
> Cheers,
> 
> Andrew
> _______________________________________________ openbmc mailing list openbmc at lists.ozlabs.org https://lists.ozlabs.org/listinfo/openbmc