* Sharing TF-A with multiple BSP
@ 2020-05-11 14:47 Joshua Watt
2020-05-11 17:37 ` [meta-arm] " Denys Dmytriyenko
[not found] ` <160E09F2270E9334.31760@lists.yoctoproject.org>
0 siblings, 2 replies; 5+ messages in thread
From: Joshua Watt @ 2020-05-11 14:47 UTC (permalink / raw)
To: meta-arm
Continuing the outcome from a discussion that was on the OE-core mailing
list, I've started converting some of the BSP layers I work on to use
the trusted-firmware-a recipe from meta-arm as the canonical source of
ATF instead of each of the implementing their own recipe. So far this
has gone well except for one annoyance I've found: meta-arm has a layer
dependency on meta-python, specifically for the optee recipe. Normally,
this wouldn't be such a big deal, but in a ideal world there will now be
a lot of BSP layers that depend on meta-arm to provide ATF, and it seems
annoying to have to make all of those layers (transitively) depend on
meta-python.
I can think of a few possible options:
1) Do nothing because no one other than me thinks this is a problem :)
2) Use BBFILES_DYNAMIC to make optee optional based on the presence of
meta-python
3) Use PACKAGECONFIG to remove the python parts of optee (if that's even
possible). They can be automatically added back if meta-python is
present via BBFILES_DYNAMIC.
4) Remove the hard requirement of meta-python from meta-arm; it's only
needed to build optee so the users can figure it out?
Anyone else have any ideas or thoughts?
Thanks,
Joshua Watt
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-arm] Sharing TF-A with multiple BSP
2020-05-11 14:47 Sharing TF-A with multiple BSP Joshua Watt
@ 2020-05-11 17:37 ` Denys Dmytriyenko
[not found] ` <160E09F2270E9334.31760@lists.yoctoproject.org>
1 sibling, 0 replies; 5+ messages in thread
From: Denys Dmytriyenko @ 2020-05-11 17:37 UTC (permalink / raw)
To: Joshua Watt; +Cc: meta-arm
On Mon, May 11, 2020 at 09:47:49AM -0500, Joshua Watt wrote:
> Continuing the outcome from a discussion that was on the OE-core
> mailing list, I've started converting some of the BSP layers I work
> on to use the trusted-firmware-a recipe from meta-arm as the
> canonical source of ATF instead of each of the implementing their
> own recipe. So far this has gone well except for one annoyance I've
> found: meta-arm has a layer dependency on meta-python, specifically
> for the optee recipe. Normally, this wouldn't be such a big deal,
> but in a ideal world there will now be a lot of BSP layers that
> depend on meta-arm to provide ATF, and it seems annoying to have to
> make all of those layers (transitively) depend on meta-python.
Yeah, I raised this issue over a month ago - unfortunately, nobody replied
or acknowledged...
> I can think of a few possible options:
>
> 1) Do nothing because no one other than me thinks this is a problem :)
Don't flatter yourself... :) :D J/k
> 2) Use BBFILES_DYNAMIC to make optee optional based on the presence
> of meta-python
>
> 3) Use PACKAGECONFIG to remove the python parts of optee (if that's
> even possible). They can be automatically added back if meta-python
> is present via BBFILES_DYNAMIC.
I don't think those are optional - they are used during the build to
sign some parts. And also for ELF manipulations.
> 4) Remove the hard requirement of meta-python from meta-arm; it's
> only needed to build optee so the users can figure it out?
>
>
> Anyone else have any ideas or thoughts?
I can think of couple more options:
5) there are only 3 python modules needed - pycrypto, pycryptodomex (actually
a replacement for pycrypto, so upstream can drop first one) and pyelftools.
Could probably try to make a case of moving them to OE-Core?
6) Like optee was inside own sub-layer meta-optee within meta-linaro, can look
into separating it into meta-optee within meta-arm.
> Thanks,
> Joshua Watt
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-arm] Sharing TF-A with multiple BSP
[not found] ` <160E09F2270E9334.31760@lists.yoctoproject.org>
@ 2020-05-11 17:48 ` Denys Dmytriyenko
2020-05-11 18:00 ` Khem Raj
0 siblings, 1 reply; 5+ messages in thread
From: Denys Dmytriyenko @ 2020-05-11 17:48 UTC (permalink / raw)
To: Joshua Watt, Khem Raj; +Cc: meta-arm
+ Khem
[apparently, nobody follows the list, so need to round up everyone interested] :)
Please see below for possible discussed options. IMHO, #5 would be ideal.
On Mon, May 11, 2020 at 01:37:30PM -0400, Denys Dmytriyenko wrote:
> On Mon, May 11, 2020 at 09:47:49AM -0500, Joshua Watt wrote:
> > Continuing the outcome from a discussion that was on the OE-core
> > mailing list, I've started converting some of the BSP layers I work
> > on to use the trusted-firmware-a recipe from meta-arm as the
> > canonical source of ATF instead of each of the implementing their
> > own recipe. So far this has gone well except for one annoyance I've
> > found: meta-arm has a layer dependency on meta-python, specifically
> > for the optee recipe. Normally, this wouldn't be such a big deal,
> > but in a ideal world there will now be a lot of BSP layers that
> > depend on meta-arm to provide ATF, and it seems annoying to have to
> > make all of those layers (transitively) depend on meta-python.
>
> Yeah, I raised this issue over a month ago - unfortunately, nobody replied
> or acknowledged...
>
>
> > I can think of a few possible options:
> >
> > 1) Do nothing because no one other than me thinks this is a problem :)
>
> Don't flatter yourself... :) :D J/k
>
>
> > 2) Use BBFILES_DYNAMIC to make optee optional based on the presence
> > of meta-python
> >
> > 3) Use PACKAGECONFIG to remove the python parts of optee (if that's
> > even possible). They can be automatically added back if meta-python
> > is present via BBFILES_DYNAMIC.
>
> I don't think those are optional - they are used during the build to
> sign some parts. And also for ELF manipulations.
>
>
> > 4) Remove the hard requirement of meta-python from meta-arm; it's
> > only needed to build optee so the users can figure it out?
> >
> >
> > Anyone else have any ideas or thoughts?
>
> I can think of couple more options:
>
> 5) there are only 3 python modules needed - pycrypto, pycryptodomex (actually
> a replacement for pycrypto, so upstream can drop first one) and pyelftools.
> Could probably try to make a case of moving them to OE-Core?
>
> 6) Like optee was inside own sub-layer meta-optee within meta-linaro, can look
> into separating it into meta-optee within meta-arm.
>
>
> > Thanks,
> > Joshua Watt
> >
>
> >
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-arm] Sharing TF-A with multiple BSP
2020-05-11 17:48 ` Denys Dmytriyenko
@ 2020-05-11 18:00 ` Khem Raj
2020-05-11 20:42 ` Joshua Watt
0 siblings, 1 reply; 5+ messages in thread
From: Khem Raj @ 2020-05-11 18:00 UTC (permalink / raw)
To: Denys Dmytriyenko; +Cc: Joshua Watt, meta-arm
On Mon, May 11, 2020 at 10:48 AM Denys Dmytriyenko <denis@denix.org> wrote:
>
> + Khem
>
> [apparently, nobody follows the list, so need to round up everyone interested] :)
>
Admittedly I don't follow and this layer shows up because I need
meta-ti just for beaglebone
which does not use optee, so not that interesting but I am on
receiving end of this. I agree
option 5 is best and if, we could also move the recipe to meta-oe at
least that can be a lesser
common place if not core.
> Please see below for possible discussed options. IMHO, #5 would be ideal.
>
>
> On Mon, May 11, 2020 at 01:37:30PM -0400, Denys Dmytriyenko wrote:
> > On Mon, May 11, 2020 at 09:47:49AM -0500, Joshua Watt wrote:
> > > Continuing the outcome from a discussion that was on the OE-core
> > > mailing list, I've started converting some of the BSP layers I work
> > > on to use the trusted-firmware-a recipe from meta-arm as the
> > > canonical source of ATF instead of each of the implementing their
> > > own recipe. So far this has gone well except for one annoyance I've
> > > found: meta-arm has a layer dependency on meta-python, specifically
> > > for the optee recipe. Normally, this wouldn't be such a big deal,
> > > but in a ideal world there will now be a lot of BSP layers that
> > > depend on meta-arm to provide ATF, and it seems annoying to have to
> > > make all of those layers (transitively) depend on meta-python.
> >
> > Yeah, I raised this issue over a month ago - unfortunately, nobody replied
> > or acknowledged...
> >
> >
> > > I can think of a few possible options:
> > >
> > > 1) Do nothing because no one other than me thinks this is a problem :)
> >
> > Don't flatter yourself... :) :D J/k
> >
> >
> > > 2) Use BBFILES_DYNAMIC to make optee optional based on the presence
> > > of meta-python
> > >
> > > 3) Use PACKAGECONFIG to remove the python parts of optee (if that's
> > > even possible). They can be automatically added back if meta-python
> > > is present via BBFILES_DYNAMIC.
> >
> > I don't think those are optional - they are used during the build to
> > sign some parts. And also for ELF manipulations.
> >
> >
> > > 4) Remove the hard requirement of meta-python from meta-arm; it's
> > > only needed to build optee so the users can figure it out?
> > >
> > >
> > > Anyone else have any ideas or thoughts?
> >
> > I can think of couple more options:
> >
> > 5) there are only 3 python modules needed - pycrypto, pycryptodomex (actually
> > a replacement for pycrypto, so upstream can drop first one) and pyelftools.
> > Could probably try to make a case of moving them to OE-Core?
> >
> > 6) Like optee was inside own sub-layer meta-optee within meta-linaro, can look
> > into separating it into meta-optee within meta-arm.
> >
> >
> > > Thanks,
> > > Joshua Watt
> > >
> >
> > >
> >
>
> >
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-arm] Sharing TF-A with multiple BSP
2020-05-11 18:00 ` Khem Raj
@ 2020-05-11 20:42 ` Joshua Watt
0 siblings, 0 replies; 5+ messages in thread
From: Joshua Watt @ 2020-05-11 20:42 UTC (permalink / raw)
To: Khem Raj, Denys Dmytriyenko; +Cc: meta-arm, openembedded-core
Looping in OE-core. Specifically, would there be any push back to adding
pycryptodomex and pyelftools to oe-core?
On 5/11/20 1:00 PM, Khem Raj wrote:
> On Mon, May 11, 2020 at 10:48 AM Denys Dmytriyenko <denis@denix.org> wrote:
>> + Khem
>>
>> [apparently, nobody follows the list, so need to round up everyone interested] :)
>>
> Admittedly I don't follow and this layer shows up because I need
> meta-ti just for beaglebone
> which does not use optee, so not that interesting but I am on
> receiving end of this. I agree
> option 5 is best and if, we could also move the recipe to meta-oe at
> least that can be a lesser
> common place if not core.
>
>> Please see below for possible discussed options. IMHO, #5 would be ideal.
>>
>>
>> On Mon, May 11, 2020 at 01:37:30PM -0400, Denys Dmytriyenko wrote:
>>> On Mon, May 11, 2020 at 09:47:49AM -0500, Joshua Watt wrote:
>>>> Continuing the outcome from a discussion that was on the OE-core
>>>> mailing list, I've started converting some of the BSP layers I work
>>>> on to use the trusted-firmware-a recipe from meta-arm as the
>>>> canonical source of ATF instead of each of the implementing their
>>>> own recipe. So far this has gone well except for one annoyance I've
>>>> found: meta-arm has a layer dependency on meta-python, specifically
>>>> for the optee recipe. Normally, this wouldn't be such a big deal,
>>>> but in a ideal world there will now be a lot of BSP layers that
>>>> depend on meta-arm to provide ATF, and it seems annoying to have to
>>>> make all of those layers (transitively) depend on meta-python.
>>> Yeah, I raised this issue over a month ago - unfortunately, nobody replied
>>> or acknowledged...
>>>
>>>
>>>> I can think of a few possible options:
>>>>
>>>> 1) Do nothing because no one other than me thinks this is a problem :)
>>> Don't flatter yourself... :) :D J/k
>>>
>>>
>>>> 2) Use BBFILES_DYNAMIC to make optee optional based on the presence
>>>> of meta-python
>>>>
>>>> 3) Use PACKAGECONFIG to remove the python parts of optee (if that's
>>>> even possible). They can be automatically added back if meta-python
>>>> is present via BBFILES_DYNAMIC.
>>> I don't think those are optional - they are used during the build to
>>> sign some parts. And also for ELF manipulations.
>>>
>>>
>>>> 4) Remove the hard requirement of meta-python from meta-arm; it's
>>>> only needed to build optee so the users can figure it out?
>>>>
>>>>
>>>> Anyone else have any ideas or thoughts?
>>> I can think of couple more options:
>>>
>>> 5) there are only 3 python modules needed - pycrypto, pycryptodomex (actually
>>> a replacement for pycrypto, so upstream can drop first one) and pyelftools.
>>> Could probably try to make a case of moving them to OE-Core?
>>>
>>> 6) Like optee was inside own sub-layer meta-optee within meta-linaro, can look
>>> into separating it into meta-optee within meta-arm.
>>>
>>>
>>>> Thanks,
>>>> Joshua Watt
>>>>
>>>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-05-11 20:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-11 14:47 Sharing TF-A with multiple BSP Joshua Watt
2020-05-11 17:37 ` [meta-arm] " Denys Dmytriyenko
[not found] ` <160E09F2270E9334.31760@lists.yoctoproject.org>
2020-05-11 17:48 ` Denys Dmytriyenko
2020-05-11 18:00 ` Khem Raj
2020-05-11 20:42 ` Joshua Watt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.