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.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138342):
https://lists.openembedded.org/g/openembedded-core/message/138342
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]
-=-=-=-=-=-=-=-=-=-=-=-
