[dunfell/master PATCH 0/6] am65x/j7*: Remove non-existent 5.10.y dtb*


praneeth
 

From: Praneeth Bajjuri <praneeth@ti.com>

The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.

Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.

Praneeth Bajjuri (6):
Revert "conf: j7-evm: Add jailhouse dtbo"
Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"
Revert "j7-evm: add new infotainment DTBO file"
Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"
Revert "conf: machine: j7200-evm: Add Jailhouse overlay"
conf/machine: am65xx: Remove non-existent dtb* from 5.10

conf/machine/include/am65xx.inc | 11 -----------
conf/machine/j7-evm.conf | 4 ----
conf/machine/j7200-evm.conf | 1 -
3 files changed, 16 deletions(-)

--
2.17.1


praneeth
 

Denys,

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>
The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.
Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Need your recommendation if this is the right approach to enable the builds at this early stage of LTS migration (and re-enable the overlays once the support is added in kernel).

Praneeth Bajjuri (6):
Revert "conf: j7-evm: Add jailhouse dtbo"
Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"
Revert "j7-evm: add new infotainment DTBO file"
Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"
Revert "conf: machine: j7200-evm: Add Jailhouse overlay"
conf/machine: am65xx: Remove non-existent dtb* from 5.10
conf/machine/include/am65xx.inc | 11 -----------
conf/machine/j7-evm.conf | 4 ----
conf/machine/j7200-evm.conf | 1 -
3 files changed, 16 deletions(-)


praneeth
 

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>
The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.
Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Will send a v2 shortly adding more platforms in same category ( removing non-existent dtb/o in meta-ti to match the kernel status)

Praneeth Bajjuri (6):
Revert "conf: j7-evm: Add jailhouse dtbo"
Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"
Revert "j7-evm: add new infotainment DTBO file"
Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"
Revert "conf: machine: j7200-evm: Add Jailhouse overlay"
conf/machine: am65xx: Remove non-existent dtb* from 5.10
conf/machine/include/am65xx.inc | 11 -----------
conf/machine/j7-evm.conf | 4 ----
conf/machine/j7200-evm.conf | 1 -
3 files changed, 16 deletions(-)


Denys Dmytriyenko
 

On Thu, Apr 15, 2021 at 12:07:05PM -0500, praneeth via lists.yoctoproject.org wrote:
Denys,

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>

The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.

Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Need your recommendation if this is the right approach to enable the
builds at this early stage of LTS migration (and re-enable the
overlays once the support is added in kernel).
That's kind of normal to start a new LTS with bare minimum of dtb/o support.

But I have 2 concerns:

1. Maybe better to just push commit with removal, instead of reverting old
commits - it may get quite confusing soon with reverts of reverts...

2. Do you think it's still premature to make 5.10 as a default in meta-ti
dunfell branch? Since dunfell is kind of established stable (not a new LTS),
anyone who updates meta-ti will go from fully working 5.4 to a very minimal
and bare 5.10 - may be a bad user experience...


Praneeth Bajjuri (6):
Revert "conf: j7-evm: Add jailhouse dtbo"
Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"
Revert "j7-evm: add new infotainment DTBO file"
Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"
Revert "conf: machine: j7200-evm: Add Jailhouse overlay"
conf/machine: am65xx: Remove non-existent dtb* from 5.10

conf/machine/include/am65xx.inc | 11 -----------
conf/machine/j7-evm.conf | 4 ----
conf/machine/j7200-evm.conf | 1 -
3 files changed, 16 deletions(-)
--
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


praneeth
 

On 4/15/2021 1:24 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 12:07:05PM -0500, praneeth via lists.yoctoproject.org wrote:
Denys,

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>

The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.

Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Need your recommendation if this is the right approach to enable the
builds at this early stage of LTS migration (and re-enable the
overlays once the support is added in kernel).
That's kind of normal to start a new LTS with bare minimum of dtb/o support.
But I have 2 concerns:
1. Maybe better to just push commit with removal, instead of reverting old
commits - it may get quite confusing soon with reverts of reverts...
makes sense. will squash in v2.

2. Do you think it's still premature to make 5.10 as a default in meta-ti
dunfell branch? Since dunfell is kind of established stable (not a new LTS),
anyone who updates meta-ti will go from fully working 5.4 to a very minimal
and bare 5.10 - may be a bad user experience...
Was thinking in similar line.
So, till the 5.10 baseline matures i will continue to use dunfell-next to stage the patches and keep dunfell branch untouched w.r.t merging 5.10 specific changes.

Let me know if this a good approach, The only problem in that case is the graphics update for 5.10 that i recently pulled to dunfell branch. Need to revert it to keep 5.4 dunfell experience retained.

Any other ideas?


Praneeth Bajjuri (6):
Revert "conf: j7-evm: Add jailhouse dtbo"
Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"
Revert "j7-evm: add new infotainment DTBO file"
Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"
Revert "conf: machine: j7200-evm: Add Jailhouse overlay"
conf/machine: am65xx: Remove non-existent dtb* from 5.10

conf/machine/include/am65xx.inc | 11 -----------
conf/machine/j7-evm.conf | 4 ----
conf/machine/j7200-evm.conf | 1 -
3 files changed, 16 deletions(-)


Denys Dmytriyenko
 

On Thu, Apr 15, 2021 at 02:00:31PM -0500, Bajjuri, Praneeth wrote:


On 4/15/2021 1:24 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 12:07:05PM -0500, praneeth via lists.yoctoproject.org wrote:
Denys,

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>

The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.

Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Need your recommendation if this is the right approach to enable the
builds at this early stage of LTS migration (and re-enable the
overlays once the support is added in kernel).
That's kind of normal to start a new LTS with bare minimum of dtb/o support.

But I have 2 concerns:

1. Maybe better to just push commit with removal, instead of reverting old
commits - it may get quite confusing soon with reverts of reverts...
makes sense. will squash in v2.


2. Do you think it's still premature to make 5.10 as a default in meta-ti
dunfell branch? Since dunfell is kind of established stable (not a new LTS),
anyone who updates meta-ti will go from fully working 5.4 to a very minimal
and bare 5.10 - may be a bad user experience...
Was thinking in similar line.
So, till the 5.10 baseline matures i will continue to use
dunfell-next to stage the patches and keep dunfell branch untouched
w.r.t merging 5.10 specific changes.

Let me know if this a good approach, The only problem in that case
is the graphics update for 5.10 that i recently pulled to dunfell
branch. Need to revert it to keep 5.4 dunfell experience retained.
Try those updates first with 5.4 before reverting them, mayve they'll work.


Any other ideas?



Praneeth Bajjuri (6):
Revert "conf: j7-evm: Add jailhouse dtbo"
Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"
Revert "j7-evm: add new infotainment DTBO file"
Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"
Revert "conf: machine: j7200-evm: Add Jailhouse overlay"
conf/machine: am65xx: Remove non-existent dtb* from 5.10

conf/machine/include/am65xx.inc | 11 -----------
conf/machine/j7-evm.conf | 4 ----
conf/machine/j7200-evm.conf | 1 -
3 files changed, 16 deletions(-)
--
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


Denys Dmytriyenko
 

On Thu, Apr 15, 2021 at 04:22:20PM -0400, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 02:00:31PM -0500, Bajjuri, Praneeth wrote:


On 4/15/2021 1:24 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 12:07:05PM -0500, praneeth via lists.yoctoproject.org wrote:
Denys,

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>

The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.

Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Need your recommendation if this is the right approach to enable the
builds at this early stage of LTS migration (and re-enable the
overlays once the support is added in kernel).
That's kind of normal to start a new LTS with bare minimum of dtb/o support.

But I have 2 concerns:

1. Maybe better to just push commit with removal, instead of reverting old
commits - it may get quite confusing soon with reverts of reverts...
makes sense. will squash in v2.


2. Do you think it's still premature to make 5.10 as a default in meta-ti
dunfell branch? Since dunfell is kind of established stable (not a new LTS),
anyone who updates meta-ti will go from fully working 5.4 to a very minimal
and bare 5.10 - may be a bad user experience...
Was thinking in similar line.
So, till the 5.10 baseline matures i will continue to use
dunfell-next to stage the patches and keep dunfell branch untouched
w.r.t merging 5.10 specific changes.
Another approach could be to keep using core-next branding for a bit longer,
leaving 5.4 as a default, until 5.10 is ready.


Let me know if this a good approach, The only problem in that case
is the graphics update for 5.10 that i recently pulled to dunfell
branch. Need to revert it to keep 5.4 dunfell experience retained.
Try those updates first with 5.4 before reverting them, mayve they'll work.


Any other ideas?



Praneeth Bajjuri (6):
Revert "conf: j7-evm: Add jailhouse dtbo"
Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"
Revert "j7-evm: add new infotainment DTBO file"
Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"
Revert "conf: machine: j7200-evm: Add Jailhouse overlay"
conf/machine: am65xx: Remove non-existent dtb* from 5.10

conf/machine/include/am65xx.inc | 11 -----------
conf/machine/j7-evm.conf | 4 ----
conf/machine/j7200-evm.conf | 1 -
3 files changed, 16 deletions(-)
--
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


praneeth
 

On 4/16/2021 12:35 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 04:22:20PM -0400, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 02:00:31PM -0500, Bajjuri, Praneeth wrote:


On 4/15/2021 1:24 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 12:07:05PM -0500, praneeth via lists.yoctoproject.org wrote:
Denys,

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>

The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.

Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Need your recommendation if this is the right approach to enable the
builds at this early stage of LTS migration (and re-enable the
overlays once the support is added in kernel).
That's kind of normal to start a new LTS with bare minimum of dtb/o support.

But I have 2 concerns:

1. Maybe better to just push commit with removal, instead of reverting old
commits - it may get quite confusing soon with reverts of reverts...
makes sense. will squash in v2.


2. Do you think it's still premature to make 5.10 as a default in meta-ti
dunfell branch? Since dunfell is kind of established stable (not a new LTS),
anyone who updates meta-ti will go from fully working 5.4 to a very minimal
and bare 5.10 - may be a bad user experience...
Was thinking in similar line.
So, till the 5.10 baseline matures i will continue to use
dunfell-next to stage the patches and keep dunfell branch untouched
w.r.t merging 5.10 specific changes.
Another approach could be to keep using core-next branding for a bit longer,
leaving 5.4 as a default, until 5.10 is ready.
the final SDK release with 5.4 on dunfell has already been made so not aware of anyone using this combination for active development now.

and 5.10 needs to be getting to a better shape soon.
Thinking, it makes sense to switch to 5.10 and start addressing the regressions as we progress with development.


Let me know if this a good approach, The only problem in that case
is the graphics update for 5.10 that i recently pulled to dunfell
branch. Need to revert it to keep 5.4 dunfell experience retained.
Try those updates first with 5.4 before reverting them, mayve they'll work.


Any other ideas?



Praneeth Bajjuri (6):
Revert "conf: j7-evm: Add jailhouse dtbo"
Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"
Revert "j7-evm: add new infotainment DTBO file"
Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"
Revert "conf: machine: j7200-evm: Add Jailhouse overlay"
conf/machine: am65xx: Remove non-existent dtb* from 5.10

conf/machine/include/am65xx.inc | 11 -----------
conf/machine/j7-evm.conf | 4 ----
conf/machine/j7200-evm.conf | 1 -
3 files changed, 16 deletions(-)


Denys Dmytriyenko
 

Praneeth,

On Sun, Apr 18, 2021 at 11:51:06PM -0500, praneeth via lists.yoctoproject.org wrote:
On 4/16/2021 12:35 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 04:22:20PM -0400, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 02:00:31PM -0500, Bajjuri, Praneeth wrote:
On 4/15/2021 1:24 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 12:07:05PM -0500, praneeth via lists.yoctoproject.org wrote:
Denys,

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>

The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.

Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Need your recommendation if this is the right approach to enable the
builds at this early stage of LTS migration (and re-enable the
overlays once the support is added in kernel).
That's kind of normal to start a new LTS with bare minimum of dtb/o support.

But I have 2 concerns:

1. Maybe better to just push commit with removal, instead of reverting old
commits - it may get quite confusing soon with reverts of reverts...
makes sense. will squash in v2.


2. Do you think it's still premature to make 5.10 as a default in meta-ti
dunfell branch? Since dunfell is kind of established stable (not a new LTS),
anyone who updates meta-ti will go from fully working 5.4 to a very minimal
and bare 5.10 - may be a bad user experience...
Was thinking in similar line.
So, till the 5.10 baseline matures i will continue to use
dunfell-next to stage the patches and keep dunfell branch untouched
w.r.t merging 5.10 specific changes.
Another approach could be to keep using core-next branding for a bit longer,
leaving 5.4 as a default, until 5.10 is ready.
the final SDK release with 5.4 on dunfell has already been made so
not aware of anyone using this combination for active development
now.

and 5.10 needs to be getting to a better shape soon.
Thinking, it makes sense to switch to 5.10 and start addressing the
regressions as we progress with development.
I see dunfell has been merged with "empty" 5.10 which is the default.
What happened to keeping this to dunfell-next for now? As you said above:

| So, till the 5.10 baseline matures i will continue to use
| dunfell-next to stage the patches and keep dunfell branch untouched
| w.r.t merging 5.10 specific changes.

While I understand the need to migrate from 5.4 to 5.10 and get developers
working on it, willingly introducing regressions into a stable branch is
quite undesirable. Anyone developing a product for a TI part with meta-ti
would normally pull the latest stable branch. And while last week it used
to work perfectly fine, providing full-featured 5.4 experience, this week
it appears to be very barebone and with limited features 5.10 experience by
default...

Will be needing to advise people to pin down to 07.03.00.005 tag and not rush
to the latest 2021.00.001 tag for now.


Let me know if this a good approach, The only problem in that case
is the graphics update for 5.10 that i recently pulled to dunfell
branch. Need to revert it to keep 5.4 dunfell experience retained.
Try those updates first with 5.4 before reverting them, mayve they'll work.


Any other ideas?


praneeth
 

Hi Denys,

On 4/22/2021 3:48 PM, Denys Dmytriyenko wrote:
Praneeth,
On Sun, Apr 18, 2021 at 11:51:06PM -0500, praneeth via lists.yoctoproject.org wrote:
On 4/16/2021 12:35 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 04:22:20PM -0400, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 02:00:31PM -0500, Bajjuri, Praneeth wrote:
On 4/15/2021 1:24 PM, Denys Dmytriyenko wrote:
On Thu, Apr 15, 2021 at 12:07:05PM -0500, praneeth via lists.yoctoproject.org wrote:
Denys,

On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
From: Praneeth Bajjuri <praneeth@ti.com>

The current ti-linux-5.10.y integration branch doesnt have support for
non base board dtb/o form the primary latest processor board on am65 and
j7* evms yet.

Removing these dtb/o for enabling the builds to continue.
Plan to add these blob and overlays back once the equivalent support is
added in the integrated ti-linux-5.10.y kernel.
Need your recommendation if this is the right approach to enable the
builds at this early stage of LTS migration (and re-enable the
overlays once the support is added in kernel).
That's kind of normal to start a new LTS with bare minimum of dtb/o support.

But I have 2 concerns:

1. Maybe better to just push commit with removal, instead of reverting old
commits - it may get quite confusing soon with reverts of reverts...
makes sense. will squash in v2.


2. Do you think it's still premature to make 5.10 as a default in meta-ti
dunfell branch? Since dunfell is kind of established stable (not a new LTS),
anyone who updates meta-ti will go from fully working 5.4 to a very minimal
and bare 5.10 - may be a bad user experience...
Was thinking in similar line.
So, till the 5.10 baseline matures i will continue to use
dunfell-next to stage the patches and keep dunfell branch untouched
w.r.t merging 5.10 specific changes.
Another approach could be to keep using core-next branding for a bit longer,
leaving 5.4 as a default, until 5.10 is ready.
the final SDK release with 5.4 on dunfell has already been made so
not aware of anyone using this combination for active development
now.

and 5.10 needs to be getting to a better shape soon.
Thinking, it makes sense to switch to 5.10 and start addressing the
regressions as we progress with development.
I see dunfell has been merged with "empty" 5.10 which is the default.
Can you help here, didnot understand this "merged with "empty" 5.10 which is the default"

What happened to keeping this to dunfell-next for now? As you said above:
| So, till the 5.10 baseline matures i will continue to use
| dunfell-next to stage the patches and keep dunfell branch untouched
| w.r.t merging 5.10 specific changes.
While I understand the need to migrate from 5.4 to 5.10 and get developers
working on it, willingly introducing regressions into a stable branch is
quite undesirable. Anyone developing a product for a TI part with meta-ti
would normally pull the latest stable branch. And while last week it used
to work perfectly fine, providing full-featured 5.4 experience, this week
it appears to be very barebone and with limited features 5.10 experience by
default...
The 5.4 stability on dunfell took longer and also a need to making 5.10 migration ready on the same branch makes the ride not smoother too.

Few updates on the planned next steps (basically getting from barebone to complete features as per the product plan).

* non display overlays support will come in the next week.
* display overlays will take more than few weeks as the migration for this on kernel side has not started either.
* non-k3 devices fails to build today, but the fixes are in progress (testing them on dunfell-next branch now)
* jailhouse has been disabled temporarily. This feature is in review to be completely descoped too as desired by product teams. depending on the direction closure worst case we might have to remove jailhouse completely from meta-ti/meta-arago on dunfell and master.

Not the best choice, but the reason i pulled dunfell-next to dunfell is to initiate the system test and other automation job/build dependencies to have those ready for 2021LTS baseline too.

Have also kept -master untouched for this transitionary period. Will sync all patches to master once dunfell with 5.10 is featured.

Will be needing to advise people to pin down to 07.03.00.005 tag and not rush
to the latest 2021.00.001 tag for now.
You are right, this is what i am advising the teams who need dunfell repository for more development on the top (Ex: processor-sdk) till 5.10 is completely ready on dunfell.

Both jacinto and sitara processor-sdk are using the pinned config and adding any further recipe updates in the meta-processor-sdk* layer on top for time being.



Let me know if this a good approach, The only problem in that case
is the graphics update for 5.10 that i recently pulled to dunfell
branch. Need to revert it to keep 5.4 dunfell experience retained.
Try those updates first with 5.4 before reverting them, mayve they'll work.


Any other ideas?


Denys Dmytriyenko
 

Praneeth,

On Thu, Apr 22, 2021 at 05:28:19PM -0500, Bajjuri, Praneeth wrote:
On 4/22/2021 3:48 PM, Denys Dmytriyenko wrote:
2. Do you think it's still premature to make 5.10 as a default in meta-ti
dunfell branch? Since dunfell is kind of established stable (not a new LTS),
anyone who updates meta-ti will go from fully working 5.4 to a very minimal
and bare 5.10 - may be a bad user experience...
Was thinking in similar line.
So, till the 5.10 baseline matures i will continue to use
dunfell-next to stage the patches and keep dunfell branch untouched
w.r.t merging 5.10 specific changes.
Another approach could be to keep using core-next branding for a bit longer,
leaving 5.4 as a default, until 5.10 is ready.
the final SDK release with 5.4 on dunfell has already been made so
not aware of anyone using this combination for active development
now.

and 5.10 needs to be getting to a better shape soon.
Thinking, it makes sense to switch to 5.10 and start addressing the
regressions as we progress with development.
I see dunfell has been merged with "empty" 5.10 which is the default.
Can you help here, didnot understand this "merged with "empty" 5.10
which is the default"
Sorry, I meant barebone mainline 5.10 vs. TI-enhanced 5.4. Basically, anything
that is not yet upstream, has to be re-added again to 5.10 - IPC/rpmsg, any
advanced PM/thermal, secure device support, DT overlays, etc.


What happened to keeping this to dunfell-next for now? As you said above:

| So, till the 5.10 baseline matures i will continue to use
| dunfell-next to stage the patches and keep dunfell branch untouched
| w.r.t merging 5.10 specific changes.

While I understand the need to migrate from 5.4 to 5.10 and get developers
working on it, willingly introducing regressions into a stable branch is
quite undesirable. Anyone developing a product for a TI part with meta-ti
would normally pull the latest stable branch. And while last week it used
to work perfectly fine, providing full-featured 5.4 experience, this week
it appears to be very barebone and with limited features 5.10 experience by
default...
The 5.4 stability on dunfell took longer and also a need to making
5.10 migration ready on the same branch makes the ride not smoother
too.

Few updates on the planned next steps (basically getting from
barebone to complete features as per the product plan).

* non display overlays support will come in the next week.
* display overlays will take more than few weeks as the migration
for this on kernel side has not started either.
* non-k3 devices fails to build today, but the fixes are in progress
(testing them on dunfell-next branch now)
* jailhouse has been disabled temporarily. This feature is in review
to be completely descoped too as desired by product teams. depending
on the direction closure worst case we might have to remove
jailhouse completely from meta-ti/meta-arago on dunfell and master.

Not the best choice, but the reason i pulled dunfell-next to dunfell
is to initiate the system test and other automation job/build
dependencies to have those ready for 2021LTS baseline too.
Thank you for all the details! Much appreciate the visibility here.


Have also kept -master untouched for this transitionary period. Will
sync all patches to master once dunfell with 5.10 is featured.
Well, it usually works the other way around - it's Ok to break master, but not
a stable or, even worse, an LTS branch... :) But hopefully we'll figure out
the best process and eventually get there.


Will be needing to advise people to pin down to 07.03.00.005 tag and not rush
to the latest 2021.00.001 tag for now.
You are right, this is what i am advising the teams who need dunfell
repository for more development on the top (Ex: processor-sdk) till
5.10 is completely ready on dunfell.

Both jacinto and sitara processor-sdk are using the pinned config
and adding any further recipe updates in the meta-processor-sdk*
layer on top for time being.
To be clear, I'm not referring to internal BU customers anymore. Instead, I'm
worried how external customers and any OE-savvy consulting agency handles
things. Very few will stick to an SDK release or corresponding tag. That is
due to OE/Yocto recommendation to always pull latest from a stable/LTS branch,
in order to pick up any security fixes...


Let me know if this a good approach, The only problem in that case
is the graphics update for 5.10 that i recently pulled to dunfell
branch. Need to revert it to keep 5.4 dunfell experience retained.
Try those updates first with 5.4 before reverting them, mayve they'll work.


Any other ideas?
--
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964