[kirkstone,v2] meta-ti-bsp: Add recipe for u-boot-ti-jailhouse and linux-ti-jailhouse

Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
be used for jailhouse for am62xx-evm.

Jailhouse support for am62xx-evm requires few patches for u-boot and linux
which are hosted at processor-sdk/u-boot and processor/linux respectively.
To build a image with jailhouse for am62xx-evm, these recipes
will be used instead of u-boot-ti-staging and linux-ti-staging by changing
the preferred_provider.

Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
---
 .../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb    | 9 +++++++++
 .../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb       | 9 +++++++++
 2 files changed, 18 insertions(+)
 create mode 100644 meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
 create mode 100644 meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb

On 6/5/2023 8:11 AM, Paresh Bhagat wrote:
> Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
> be used for jailhouse for am62xx-evm.
> 
> Jailhouse support for am62xx-evm requires few patches for u-boot and linux
> which are hosted at processor-sdk/u-boot and processor/linux respectively.
> To build a image with jailhouse for am62xx-evm, these recipes
> will be used instead of u-boot-ti-staging and linux-ti-staging by changing
> the preferred_provider.
> 
> Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
> ---
>   .../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb    | 9 +++++++++
>   .../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb       | 9 +++++++++
>   2 files changed, 18 insertions(+)
>   create mode 100644 meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>   create mode 100644 meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
> 
> diff --git a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> new file mode 100644
> index 00000000..079d55dd
> --- /dev/null
> +++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> @@ -0,0 +1,9 @@
> +require u-boot-ti-staging_2023.04.bb
> +
> +# This will have priority over generic uboot path
> +
> +BRANCH = "ti-u-boot-2023.04-jailhouse"
> +
> +UBOOT_GIT_URI = "git://git.ti.com/git/processor-sdk/u-boot.git"

What is reasoning for not upstreaming these patches (both u-boot and 
kernel) even just into the TI repositories?

My concern is the CICD process.  This is adding another recipe with a 
completely different linux/u-boot repository that we need to add support 
for to keep the recipes up to date.

And you guys will to keep rebasing these patches on top of the latest 
6.1 prod branch when CICD promotes.

This just feels like something that is going to turn into a lot of 
maintenance work in the future.


> +SRCREV = "79615e1c99b9aa73948f811f5f866cff2e34dc37"
> diff --git a/meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb b/meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
> new file mode 100644
> index 00000000..8e1edb55
> --- /dev/null
> +++ b/meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
> @@ -0,0 +1,9 @@
> +require linux-ti-staging_6.1.bb
> +
> +# Use different commit, repo and branch for jailhouse build
> +
> +BRANCH = "ti-linux-6.1.y-jailhouse"
> +
> +SRCREV = "0ed0dec2462b805b0188fe080895adc437871549"
> +
> +KERNEL_GIT_URI = "git://git.ti.com/git/processor-sdk/linux.git"

On 6/5/2023 8:30 AM, Ryan Eatmon via lists.yoctoproject.org wrote:
> 
> 
> On 6/5/2023 8:11 AM, Paresh Bhagat wrote:
>> Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
>> be used for jailhouse for am62xx-evm.
>>
>> Jailhouse support for am62xx-evm requires few patches for u-boot and 
>> linux
>> which are hosted at processor-sdk/u-boot and processor/linux 
>> respectively.
>> To build a image with jailhouse for am62xx-evm, these recipes
>> will be used instead of u-boot-ti-staging and linux-ti-staging by 
>> changing
>> the preferred_provider.
>>
>> Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
>> ---
>>   .../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb    | 9 +++++++++
>>   .../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb       | 9 +++++++++
>>   2 files changed, 18 insertions(+)
>>   create mode 100644 
>> meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>   create mode 100644 
>> meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
>>
>> diff --git 
>> a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb 
>> b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>> new file mode 100644
>> index 00000000..079d55dd
>> --- /dev/null
>> +++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>> @@ -0,0 +1,9 @@
>> +require u-boot-ti-staging_2023.04.bb
>> +
>> +# This will have priority over generic uboot path
>> +
>> +BRANCH = "ti-u-boot-2023.04-jailhouse"
>> +
>> +UBOOT_GIT_URI = "git://git.ti.com/git/processor-sdk/u-boot.git"
> 
> What is reasoning for not upstreaming these patches (both u-boot and 
> kernel) even just into the TI repositories?
> 
> My concern is the CICD process.  This is adding another recipe with a 
> completely different linux/u-boot repository that we need to add support 
> for to keep the recipes up to date.
> 
> And you guys will to keep rebasing these patches on top of the latest 
> 6.1 prod branch when CICD promotes.
> 
> This just feels like something that is going to turn into a lot of 
> maintenance work in the future.


After discussing this with Praneeth, these recipes should not be called 
jailhouse, but rather something more generic (maybe experiments).  We do 
not want to explode the number of recipes in the directory with every 
experiment we want to run in the future...  We can then configure which 
branch under the experiments to pick based on something in the distro 
features or via machine features.

And upon further reflection, do we want to create a new layer under the 
meta-ti repo to house all of these new changes and not host them in 
meta-ti-bsp?  Basically keep meta-ti-bsp as the production versions of 
code?  Any thoughs Andrew, Denys, Randolph?


> 
>> +SRCREV = "79615e1c99b9aa73948f811f5f866cff2e34dc37"
>> diff --git 
>> a/meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb 
>> b/meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
>> new file mode 100644
>> index 00000000..8e1edb55
>> --- /dev/null
>> +++ b/meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
>> @@ -0,0 +1,9 @@
>> +require linux-ti-staging_6.1.bb
>> +
>> +# Use different commit, repo and branch for jailhouse build
>> +
>> +BRANCH = "ti-linux-6.1.y-jailhouse"
>> +
>> +SRCREV = "0ed0dec2462b805b0188fe080895adc437871549"
>> +
>> +KERNEL_GIT_URI = "git://git.ti.com/git/processor-sdk/linux.git"
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#16665): https://lists.yoctoproject.org/g/meta-ti/message/16665
> Mute This Topic: https://lists.yoctoproject.org/mt/99339809/6551054
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/leave/10828724/6551054/1815494134/xyzzy [reatmon@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On Mon, Jun 5, 2023 at 5:25 PM Ryan Eatmon via lists.yoctoproject.org
<reatmon=ti.com@lists.yoctoproject.org> wrote:
> On 6/5/2023 8:30 AM, Ryan Eatmon via lists.yoctoproject.org wrote:
> > On 6/5/2023 8:11 AM, Paresh Bhagat wrote:
> >> Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
> >> be used for jailhouse for am62xx-evm.
> >>
> >> Jailhouse support for am62xx-evm requires few patches for u-boot and
> >> linux
> >> which are hosted at processor-sdk/u-boot and processor/linux
> >> respectively.
> >> To build a image with jailhouse for am62xx-evm, these recipes
> >> will be used instead of u-boot-ti-staging and linux-ti-staging by
> >> changing
> >> the preferred_provider.
> >>
> >> Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
> >> ---
> >>   .../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb    | 9 +++++++++
> >>   .../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb       | 9 +++++++++
> >>   2 files changed, 18 insertions(+)
> >>   create mode 100644
> >> meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> >>   create mode 100644
> >> meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
> >>
> >> diff --git
> >> a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> >> b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> >> new file mode 100644
> >> index 00000000..079d55dd
> >> --- /dev/null
> >> +++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> >> @@ -0,0 +1,9 @@
> >> +require u-boot-ti-staging_2023.04.bb
> >> +
> >> +# This will have priority over generic uboot path
> >> +
> >> +BRANCH = "ti-u-boot-2023.04-jailhouse"
> >> +
> >> +UBOOT_GIT_URI = "git://git.ti.com/git/processor-sdk/u-boot.git"
> >
> > What is reasoning for not upstreaming these patches (both u-boot and
> > kernel) even just into the TI repositories?
> >
> > My concern is the CICD process.  This is adding another recipe with a
> > completely different linux/u-boot repository that we need to add support
> > for to keep the recipes up to date.
> >
> > And you guys will to keep rebasing these patches on top of the latest
> > 6.1 prod branch when CICD promotes.
> >
> > This just feels like something that is going to turn into a lot of
> > maintenance work in the future.
>
>
> After discussing this with Praneeth, these recipes should not be called
> jailhouse, but rather something more generic (maybe experiments).  We do
> not want to explode the number of recipes in the directory with every
> experiment we want to run in the future...  We can then configure which
> branch under the experiments to pick based on something in the distro
> features or via machine features.
>
> And upon further reflection, do we want to create a new layer under the
> meta-ti repo to house all of these new changes and not host them in
> meta-ti-bsp?  Basically keep meta-ti-bsp as the production versions of
> code?  Any thoughs Andrew, Denys, Randolph?

For experiments I think it makes sense to have it hosted in another
layer, but in this case jailhouse is an official functionality that is
also supported by TI, isn't it?

My concern is that real customers might want to have jailhouse
enabled, which will force them to use this extra layer which might not
necessarily be aligned with the main bsp revision used (e.g. kernel
and u-boot), causing maintenance issues for product builders.

Maybe in this case it is just better to have the patches available in
the layer and enabled dynamically via machine features? It is still a
pain to maintain as it might have conflicts in the future and might
require patch updates, but if indeed a desired feature it might make
sense to be part of the main layer.

Cheers,

Hi,

On 06/06/23 03:29, Ricardo Salveti wrote:
> On Mon, Jun 5, 2023 at 5:25 PM Ryan Eatmon via lists.yoctoproject.org
> <reatmon=ti.com@lists.yoctoproject.org> wrote:
>> On 6/5/2023 8:30 AM, Ryan Eatmon via lists.yoctoproject.org wrote:
>>> On 6/5/2023 8:11 AM, Paresh Bhagat wrote:
>>>> Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
>>>> be used for jailhouse for am62xx-evm.
>>>>
>>>> Jailhouse support for am62xx-evm requires few patches for u-boot and
>>>> linux
>>>> which are hosted at processor-sdk/u-boot and processor/linux
>>>> respectively.
>>>> To build a image with jailhouse for am62xx-evm, these recipes
>>>> will be used instead of u-boot-ti-staging and linux-ti-staging by
>>>> changing
>>>> the preferred_provider.
>>>>
>>>> Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
>>>> ---
>>>>    .../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb    | 9 +++++++++
>>>>    .../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb       | 9 +++++++++
>>>>    2 files changed, 18 insertions(+)
>>>>    create mode 100644
>>>> meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>    create mode 100644
>>>> meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
>>>>
>>>> diff --git
>>>> a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>> b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>> new file mode 100644
>>>> index 00000000..079d55dd
>>>> --- /dev/null
>>>> +++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>> @@ -0,0 +1,9 @@
>>>> +require u-boot-ti-staging_2023.04.bb
>>>> +
>>>> +# This will have priority over generic uboot path
>>>> +
>>>> +BRANCH = "ti-u-boot-2023.04-jailhouse"
>>>> +
>>>> +UBOOT_GIT_URI = "git://git.ti.com/git/processor-sdk/u-boot.git"
>>> What is reasoning for not upstreaming these patches (both u-boot and
>>> kernel) even just into the TI repositories?
>>>
>>> My concern is the CICD process.  This is adding another recipe with a
>>> completely different linux/u-boot repository that we need to add support
>>> for to keep the recipes up to date.
>>>
>>> And you guys will to keep rebasing these patches on top of the latest
>>> 6.1 prod branch when CICD promotes.
>>>
>>> This just feels like something that is going to turn into a lot of
>>> maintenance work in the future.
>>
>> After discussing this with Praneeth, these recipes should not be called
>> jailhouse, but rather something more generic (maybe experiments).  We do
>> not want to explode the number of recipes in the directory with every
>> experiment we want to run in the future...  We can then configure which
>> branch under the experiments to pick based on something in the distro
>> features or via machine features.
>>
>> And upon further reflection, do we want to create a new layer under the
>> meta-ti repo to house all of these new changes and not host them in
>> meta-ti-bsp?  Basically keep meta-ti-bsp as the production versions of
>> code?  Any thoughs Andrew, Denys, Randolph?
> For experiments I think it makes sense to have it hosted in another
> layer, but in this case jailhouse is an official functionality that is
> also supported by TI, isn't it?
>
> My concern is that real customers might want to have jailhouse
> enabled, which will force them to use this extra layer which might not
> necessarily be aligned with the main bsp revision used (e.g. kernel
> and u-boot), causing maintenance issues for product builders.
>
> Maybe in this case it is just better to have the patches available in
> the layer and enabled dynamically via machine features? It is still a
> pain to maintain as it might have conflicts in the future and might
> require patch updates, but if indeed a desired feature it might make
> sense to be part of the main layer.

We need to support various distros going forward, so it must not be tied 
to Yocto layers, hence the seperate repos. Additionally, users must be 
able to use git kernel tree without going to worry about applying 
patches. We want to carry these changes as maintainable branch instead 
of *.patch files in meta-ti-bsp.

Thanks

>
> Cheers,

On Tue, Jun 6, 2023 at 8:59 AM Paresh Bhagat <p-bhagat@ti.com> wrote:
>
> Hi,
>
> On 06/06/23 03:29, Ricardo Salveti wrote:
> > On Mon, Jun 5, 2023 at 5:25 PM Ryan Eatmon via lists.yoctoproject.org
> > <reatmon=ti.com@lists.yoctoproject.org> wrote:
> >> On 6/5/2023 8:30 AM, Ryan Eatmon via lists.yoctoproject.org wrote:
> >>> On 6/5/2023 8:11 AM, Paresh Bhagat wrote:
> >>>> Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
> >>>> be used for jailhouse for am62xx-evm.
> >>>>
> >>>> Jailhouse support for am62xx-evm requires few patches for u-boot and
> >>>> linux
> >>>> which are hosted at processor-sdk/u-boot and processor/linux
> >>>> respectively.
> >>>> To build a image with jailhouse for am62xx-evm, these recipes
> >>>> will be used instead of u-boot-ti-staging and linux-ti-staging by
> >>>> changing
> >>>> the preferred_provider.
> >>>>
> >>>> Signed-off-by: Paresh Bhagat <p-bhagat@ti.com>
> >>>> ---
> >>>>    .../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb    | 9 +++++++++
> >>>>    .../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb       | 9 +++++++++
> >>>>    2 files changed, 18 insertions(+)
> >>>>    create mode 100644
> >>>> meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> >>>>    create mode 100644
> >>>> meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
> >>>>
> >>>> diff --git
> >>>> a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> >>>> b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> >>>> new file mode 100644
> >>>> index 00000000..079d55dd
> >>>> --- /dev/null
> >>>> +++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
> >>>> @@ -0,0 +1,9 @@
> >>>> +require u-boot-ti-staging_2023.04.bb
> >>>> +
> >>>> +# This will have priority over generic uboot path
> >>>> +
> >>>> +BRANCH = "ti-u-boot-2023.04-jailhouse"
> >>>> +
> >>>> +UBOOT_GIT_URI = "git://git.ti.com/git/processor-sdk/u-boot.git"
> >>> What is reasoning for not upstreaming these patches (both u-boot and
> >>> kernel) even just into the TI repositories?
> >>>
> >>> My concern is the CICD process.  This is adding another recipe with a
> >>> completely different linux/u-boot repository that we need to add support
> >>> for to keep the recipes up to date.
> >>>
> >>> And you guys will to keep rebasing these patches on top of the latest
> >>> 6.1 prod branch when CICD promotes.
> >>>
> >>> This just feels like something that is going to turn into a lot of
> >>> maintenance work in the future.
> >>
> >> After discussing this with Praneeth, these recipes should not be called
> >> jailhouse, but rather something more generic (maybe experiments).  We do
> >> not want to explode the number of recipes in the directory with every
> >> experiment we want to run in the future...  We can then configure which
> >> branch under the experiments to pick based on something in the distro
> >> features or via machine features.
> >>
> >> And upon further reflection, do we want to create a new layer under the
> >> meta-ti repo to house all of these new changes and not host them in
> >> meta-ti-bsp?  Basically keep meta-ti-bsp as the production versions of
> >> code?  Any thoughs Andrew, Denys, Randolph?
> > For experiments I think it makes sense to have it hosted in another
> > layer, but in this case jailhouse is an official functionality that is
> > also supported by TI, isn't it?
> >
> > My concern is that real customers might want to have jailhouse
> > enabled, which will force them to use this extra layer which might not
> > necessarily be aligned with the main bsp revision used (e.g. kernel
> > and u-boot), causing maintenance issues for product builders.
> >
> > Maybe in this case it is just better to have the patches available in
> > the layer and enabled dynamically via machine features? It is still a
> > pain to maintain as it might have conflicts in the future and might
> > require patch updates, but if indeed a desired feature it might make
> > sense to be part of the main layer.
>
> We need to support various distros going forward, so it must not be tied
> to Yocto layers, hence the seperate repos. Additionally, users must be
> able to use git kernel tree without going to worry about applying
> patches. We want to carry these changes as maintainable branch instead
> of *.patch files in meta-ti-bsp.

Then how are you planning on updating these extra branches moving
forward? Rebases? Merges from the main branch?

Just trying to understand how to best align this with customers
wanting to use jailhouse, since they might end up being behind from
the main bsp tree if the branch ends up being behind.

In or out yocto the maintenance pain will exist.

Cheers,

Hi Ricardo,

On 06/06/23 21:57, Ricardo Salveti wrote:
> On Tue, Jun 6, 2023 at 8:59 AM Paresh Bhagat<p-bhagat@ti.com>  wrote:
>> Hi,
>>
>> On 06/06/23 03:29, Ricardo Salveti wrote:
>>> On Mon, Jun 5, 2023 at 5:25 PM Ryan Eatmon via lists.yoctoproject.org
>>> <reatmon=ti.com@lists.yoctoproject.org>  wrote:
>>>> On 6/5/2023 8:30 AM, Ryan Eatmon via lists.yoctoproject.org wrote:
>>>>> On 6/5/2023 8:11 AM, Paresh Bhagat wrote:
>>>>>> Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
>>>>>> be used for jailhouse for am62xx-evm.
>>>>>>
>>>>>> Jailhouse support for am62xx-evm requires few patches for u-boot and
>>>>>> linux
>>>>>> which are hosted at processor-sdk/u-boot and processor/linux
>>>>>> respectively.
>>>>>> To build a image with jailhouse for am62xx-evm, these recipes
>>>>>> will be used instead of u-boot-ti-staging and linux-ti-staging by
>>>>>> changing
>>>>>> the preferred_provider.
>>>>>>
>>>>>> Signed-off-by: Paresh Bhagat<p-bhagat@ti.com>
>>>>>> ---
>>>>>>     .../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb    | 9 +++++++++
>>>>>>     .../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb       | 9 +++++++++
>>>>>>     2 files changed, 18 insertions(+)
>>>>>>     create mode 100644
>>>>>> meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>>>     create mode 100644
>>>>>> meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
>>>>>>
>>>>>> diff --git
>>>>>> a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>>> b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>>> new file mode 100644
>>>>>> index 00000000..079d55dd
>>>>>> --- /dev/null
>>>>>> +++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>>> @@ -0,0 +1,9 @@
>>>>>> +require u-boot-ti-staging_2023.04.bb
>>>>>> +
>>>>>> +# This will have priority over generic uboot path
>>>>>> +
>>>>>> +BRANCH = "ti-u-boot-2023.04-jailhouse"
>>>>>> +
>>>>>> +UBOOT_GIT_URI = "git://git.ti.com/git/processor-sdk/u-boot.git"
>>>>> What is reasoning for not upstreaming these patches (both u-boot and
>>>>> kernel) even just into the TI repositories?
>>>>>
>>>>> My concern is the CICD process.  This is adding another recipe with a
>>>>> completely different linux/u-boot repository that we need to add support
>>>>> for to keep the recipes up to date.
>>>>>
>>>>> And you guys will to keep rebasing these patches on top of the latest
>>>>> 6.1 prod branch when CICD promotes.
>>>>>
>>>>> This just feels like something that is going to turn into a lot of
>>>>> maintenance work in the future.
>>>> After discussing this with Praneeth, these recipes should not be called
>>>> jailhouse, but rather something more generic (maybe experiments).  We do
>>>> not want to explode the number of recipes in the directory with every
>>>> experiment we want to run in the future...  We can then configure which
>>>> branch under the experiments to pick based on something in the distro
>>>> features or via machine features.
>>>>
>>>> And upon further reflection, do we want to create a new layer under the
>>>> meta-ti repo to house all of these new changes and not host them in
>>>> meta-ti-bsp?  Basically keep meta-ti-bsp as the production versions of
>>>> code?  Any thoughs Andrew, Denys, Randolph?
>>> For experiments I think it makes sense to have it hosted in another
>>> layer, but in this case jailhouse is an official functionality that is
>>> also supported by TI, isn't it?
>>>
>>> My concern is that real customers might want to have jailhouse
>>> enabled, which will force them to use this extra layer which might not
>>> necessarily be aligned with the main bsp revision used (e.g. kernel
>>> and u-boot), causing maintenance issues for product builders.
>>>
>>> Maybe in this case it is just better to have the patches available in
>>> the layer and enabled dynamically via machine features? It is still a
>>> pain to maintain as it might have conflicts in the future and might
>>> require patch updates, but if indeed a desired feature it might make
>>> sense to be part of the main layer.
>> We need to support various distros going forward, so it must not be tied
>> to Yocto layers, hence the seperate repos. Additionally, users must be
>> able to use git kernel tree without going to worry about applying
>> patches. We want to carry these changes as maintainable branch instead
>> of *.patch files in meta-ti-bsp.
> Then how are you planning on updating these extra branches moving
> forward? Rebases? Merges from the main branch?
>
> Just trying to understand how to best align this with customers
> wanting to use jailhouse, since they might end up being behind from
> the main bsp tree if the branch ends up being behind.
>
> In or out yocto the maintenance pain will exist.
>
> Cheers,

It will be merge from the main branch. However, these repos will be 
setup to have auto merged.

Thanks,

Paresh

Hi,

On 07/06/23 15:51, Paresh Bhagat via lists.yoctoproject.org wrote:
>
> Hi Ricardo,
>
> On 06/06/23 21:57, Ricardo Salveti wrote:
>> On Tue, Jun 6, 2023 at 8:59 AM Paresh Bhagat<p-bhagat@ti.com>  wrote:
>>> Hi,
>>>
>>> On 06/06/23 03:29, Ricardo Salveti wrote:
>>>> On Mon, Jun 5, 2023 at 5:25 PM Ryan Eatmon via lists.yoctoproject.org
>>>> <reatmon=ti.com@lists.yoctoproject.org>  wrote:
>>>>> On 6/5/2023 8:30 AM, Ryan Eatmon via lists.yoctoproject.org wrote:
>>>>>> On 6/5/2023 8:11 AM, Paresh Bhagat wrote:
>>>>>>> Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
>>>>>>> be used for jailhouse for am62xx-evm.
>>>>>>>
>>>>>>> Jailhouse support for am62xx-evm requires few patches for u-boot and
>>>>>>> linux
>>>>>>> which are hosted at processor-sdk/u-boot and processor/linux
>>>>>>> respectively.
>>>>>>> To build a image with jailhouse for am62xx-evm, these recipes
>>>>>>> will be used instead of u-boot-ti-staging and linux-ti-staging by
>>>>>>> changing
>>>>>>> the preferred_provider.
>>>>>>>
>>>>>>> Signed-off-by: Paresh Bhagat<p-bhagat@ti.com>
>>>>>>> ---
>>>>>>>     .../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb    | 9 +++++++++
>>>>>>>     .../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb       | 9 +++++++++
>>>>>>>     2 files changed, 18 insertions(+)
>>>>>>>     create mode 100644
>>>>>>> meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>>>>     create mode 100644
>>>>>>> meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>>>> b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>>>> new file mode 100644
>>>>>>> index 00000000..079d55dd
>>>>>>> --- /dev/null
>>>>>>> +++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
>>>>>>> @@ -0,0 +1,9 @@
>>>>>>> +require u-boot-ti-staging_2023.04.bb
>>>>>>> +
>>>>>>> +# This will have priority over generic uboot path
>>>>>>> +
>>>>>>> +BRANCH = "ti-u-boot-2023.04-jailhouse"
>>>>>>> +
>>>>>>> +UBOOT_GIT_URI = "git://git.ti.com/git/processor-sdk/u-boot.git"
>>>>>> What is reasoning for not upstreaming these patches (both u-boot and
>>>>>> kernel) even just into the TI repositories?
>>>>>>
>>>>>> My concern is the CICD process.  This is adding another recipe with a
>>>>>> completely different linux/u-boot repository that we need to add support
>>>>>> for to keep the recipes up to date.
>>>>>>
>>>>>> And you guys will to keep rebasing these patches on top of the latest
>>>>>> 6.1 prod branch when CICD promotes.
>>>>>>
>>>>>> This just feels like something that is going to turn into a lot of
>>>>>> maintenance work in the future.
>>>>> After discussing this with Praneeth, these recipes should not be called
>>>>> jailhouse, but rather something more generic (maybe experiments).  We do
>>>>> not want to explode the number of recipes in the directory with every
>>>>> experiment we want to run in the future...  We can then configure which
>>>>> branch under the experiments to pick based on something in the distro
>>>>> features or via machine features.
>>>>>
>>>>> And upon further reflection, do we want to create a new layer under the
>>>>> meta-ti repo to house all of these new changes and not host them in
>>>>> meta-ti-bsp?  Basically keep meta-ti-bsp as the production versions of
>>>>> code?  Any thoughs Andrew, Denys, Randolph?
>>>> For experiments I think it makes sense to have it hosted in another
>>>> layer, but in this case jailhouse is an official functionality that is
>>>> also supported by TI, isn't it?
>>>>
>>>> My concern is that real customers might want to have jailhouse
>>>> enabled, which will force them to use this extra layer which might not
>>>> necessarily be aligned with the main bsp revision used (e.g. kernel
>>>> and u-boot), causing maintenance issues for product builders.
>>>>
>>>> Maybe in this case it is just better to have the patches available in
>>>> the layer and enabled dynamically via machine features? It is still a
>>>> pain to maintain as it might have conflicts in the future and might
>>>> require patch updates, but if indeed a desired feature it might make
>>>> sense to be part of the main layer.
>>> We need to support various distros going forward, so it must not be tied
>>> to Yocto layers, hence the seperate repos. Additionally, users must be
>>> able to use git kernel tree without going to worry about applying
>>> patches. We want to carry these changes as maintainable branch instead
>>> of *.patch files in meta-ti-bsp.
>> Then how are you planning on updating these extra branches moving
>> forward? Rebases? Merges from the main branch?
>>
>> Just trying to understand how to best align this with customers
>> wanting to use jailhouse, since they might end up being behind from
>> the main bsp tree if the branch ends up being behind.
>>
>> In or out yocto the maintenance pain will exist.
>>
>> Cheers,
>
> It will be merge from the main branch. However, these repos will be 
> setup to have auto merged.
>
> Thanks,
>
> Paresh
>
Forgot to put format to plain text. Please ignore.

Thanks,

Paresh

>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#16685): https://lists.yoctoproject.org/g/meta-ti/message/16685
> Mute This Topic: https://lists.yoctoproject.org/mt/99339809/7067447
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [p-bhagat@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>