On Fri, May 15, 2020, 1:32 PM Khem Raj <raj.k...@gmail.com> wrote: > > > On 5/15/20 12:12 PM, 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, 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. > > > > I think getting oe-core qemuarm64 boot with uboot+TF-A as an option > sounds good, and if thats more common solution that armv8 devices are > following then perhaps would make sense to have this tested in core too. > But I guess that can be ironed out. As such python deps I think are good > for dunfell too, we have to ensure meta-python removal happens in > dunfell as well. >
+1 on keeping testing this in core as the end goal, I also agree that this would qualify for the Dunfell changes in both oe-core and meta-python since its the first step in that direction Alejandro > >> > >> Cheers, > >> > >> Richard > >> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138372): https://lists.openembedded.org/g/openembedded-core/message/138372 Mute This Topic: https://lists.openembedded.org/mt/74214757/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
