Sharing TF-A with multiple BSP

Sharing TF-A with multiple BSP

[Joshua Watt]

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

Re: [meta-arm] Sharing TF-A with multiple BSP

[Denys Dmytriyenko]

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
> 

> 

Re: [meta-arm] Sharing TF-A with multiple BSP

[Denys Dmytriyenko]

+ 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
> > 
> 
> > 
> 

> 

Re: [meta-arm] Sharing TF-A with multiple BSP

[Khem Raj]

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
> > >
> >
> > >
> >
>
> > 
>

Re: [meta-arm] Sharing TF-A with multiple BSP

[Joshua Watt]

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
>>>>
>>>