Re: [OE-core][PATCH 0/4] Import recipes from meta-python

["Denys Dmytriyenko" <denis@denix.org>]

On Fri, May 15, 2020 at 02:12:55PM -0500, Joshua Watt wrote:
> 
> On 5/15/20 2:05 PM, Richard Purdie wrote:
> >On Fri, 2020-05-15 at 14:53 -0400, Denys Dmytriyenko wrote:
> >>I see Richard has merged these to master-next, thanks!
> >>And thanks Joshua for volunteering to maintain these recipes :)
> >>I submitted removal patches to meta-python.
> >>
> >>So, it is good we are getting this extra dependency resolved in master. The
> >>question is - can we get these backported to dunfell, does it qualify?
> >>
> >>Otherwise Jon wanted to finally branch off meta-arm into dunfell today and
> >>we'll have to live with it until gatesgarth.
> >I put them into -next so we could test them, see if the autobuilder had
> >any surprises. Good news is there weren't any.
> >
> >The question still remains whether this is the best approach or not and
> >some people I talked to were not convinced that a consensus had been
> >reached.
> >
> >The question I guess is how widely used is optee and does it warrant
> >adding this? Its a little ironic the thing people want is trusted-
> >firmware...
> 
> FWIW, after having gone through the exercise of pulling in TF-A into
> qemuarm64, I think I've been convinced that op-tee and TF-A belong
> together since they are sometimes tightly integrated together
> (something I didn't realize before). As such, having both in the
> same layer makes sense. Even if TF-A was in oe-core, you'd probably
> want op-tee also, which means the python modules would have to be
> there anyway. I think we can still have the discussion about moving
> the whole lot over there, but we don't need to do that now, and
> moving the python recipes at least cuts out the meta-python
> dependency.
> 
> My last concern was testing of optee, since there was no platform
> that could build it by default,

Many TI platforms do. All our recent Aarch64 platforms (K3 family) use 
TF-A and OP-TEE by default and require them both to boot.

Even many of our Armv7 platforms use OP-TEE, but you'd need a special "secure" 
version of the platform, and those are not available to the broad-market.


> but I fixed that by implemented
> support for a qemuarm64-based machine that's defined in meta-arm
> which uses TF-A + optee + u-boot and can successful boot using TF-A
> and passes the op-tee unit tests, so I don't have any concern about
> that anymore.

That's great for testing meta-arm components w/o requiring any specialized 
platforms!

-- 
Denys