On Fri, May 15, 2020 at 9:26 PM Denys Dmytriyenko <[email protected]> wrote: > > 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.
Just FYI: NXP i.MX8[M] series uses OP-TEE and it is also required to boot the SoC. > > 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 > -- Regards, Andrey.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138343): https://lists.openembedded.org/g/openembedded-core/message/138343 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]] -=-=-=-=-=-=-=-=-=-=-=-
