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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138341): https://lists.openembedded.org/g/openembedded-core/message/138341 Mute This Topic: https://lists.openembedded.org/mt/74214757/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
