[OE-core] [PATCH] arm-trusted-firmware: add upstream version 2.2

Jon Mason jdmason at kudzu.us
Fri Jan 24 23:00:36 UTC 2020


On Fri, Jan 24, 2020 at 5:46 PM Denys Dmytriyenko <denis at denix.org> wrote:
>
> On Fri, Jan 24, 2020 at 05:30:04PM -0500, Jon Mason wrote:
> > On Thu, Jan 23, 2020 at 5:16 PM Denys Dmytriyenko <denis at denix.org> wrote:
> > >
> > > On Thu, Jan 23, 2020 at 04:10:33PM -0600, Joshua Watt wrote:
> > > >
> > > > On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:
> > > > >On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> > > > >>On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko <denis at denix.org> wrote:
> > > > >>>From: Denys Dmytriyenko <denys at ti.com>
> > > > >>>
> > > > >>>Many BSPs require ARM Trusted Firmware (also known as Trusted Firmware-A).
> > > > >>>To avoid duplicating efforts of adding very similar recipes to BSP layers,
> > > > >>>add an upstream reference implementation to openembedded-core, which can be
> > > > >>>customized by BSPs, if needed.
> > > > >>Isn't this one of the things that Jon Mason is trying to
> > > > >>standardize/support in meta-arm ?
> > > > >>
> > > > >>http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a
> > > > >Ah, interesting, somehow I totally missed that one! :)
> > > > >
> > > > >What triggered this submission is that we have our own variant in meta-ti and
> > > > >Joshua Watt was adding a very similar one to meta-rockchip:
> > > > >https://lists.yoctoproject.org/g/yocto/topic/70054501#48116
> > > >
> > > > FWIW, variants of this recipe crop up in pretty much every ARM-based
> > > > BSP layer (e.g. https://github.com/alistair23/meta-pine64/blob/master/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2.1.bb);
> > > > it seems common enough that a base recipe that each BSP layer can
> > > > bbappend to suite their needs seems like it would be useful?
> > >
> > > Yes, indeed, hence we agreed to submit it to oe-core...
> > >
> > > And meta-arm sounds like a good idea and can be used by all those ARM-based
> > > BSPs as a base, but for some reason I cannot find any announcements for that
> > > new layer... Jon?
> >
> > Sorry, I was unaware that it was common practice to announce this kind
> > of thing.  Also, it was very barebones for the first few weeks.  In
> > fact, I still think it is minimal.  That being said, I'll send email
> > to OE-devel (and/or OE-Core) announcing it properly.
>
> If you want it to be a base for other ARM-based BSP layers, it should be very
> well known, well maintained and Yocto-compliant. I see there are multiple
> sub-layers in meta-arm and there was a recent discussion how to properly
> separate things in those sub-layers - BSP, Distro and Apps w/o mixing them.

Yes, and per that discussion we removed the distro portion from our
layer.  We are currently working on CI.  So this will be heavily
tested and verified on Arm reference platforms (and hopefully others).
Also, it's on my TODO list to get this layer Yocto-complaint for the
3.1 release.  If anything is lacking, let me know and I'll add it to
the list!

> For example, our meta-ti BSP layer has no other dependency besides OE-Core,
> making it very clean. In order for me to make meta-ti also depend on meta-arm
> for ATF, OPTEE, etc., I would like it to be up to the quality standards of
> OE-Core! So, the bar is quite high, but I'm willing to help and work in that
> direction with you and others.

I appreciate this, and agree that this is only useful if it is of the
highest quality.  Otherwise, development will fragment and everyone
will waste resources doing their own thing.

We are in the process of pulling in recipes from meta-linaro (per
their suggestion) for OP-TEE and binary toolchains, and my hope is
that this will be a "one stop shop" for all things Arm related.

Thanks,
Jon


>
> --
> Denys
>
>
> > Thanks,
> > Jon
> >
> >
> > >
> > > --
> > > Denys
> > >
> > >
> > > > >>What's the delta between the two ?
> > > > >Hmm, that one uses older 2.1 version. Other than that, I'll need to test to
> > > > >see if it's as adaptable and expandable as our more simplistic variants...
> > > > >
> > > >
> > > --
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core at lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >


More information about the Openembedded-core mailing list