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

[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

[dunfell/master PATCH 1/6] Revert "conf: j7-evm: Add jailhouse dtbo"

[praneeth]

From: Praneeth Bajjuri <praneeth@ti.com>

This reverts commit 47cca9560d3464a67ed725ab573e8b976a3367c4.

Reverting for now, as the support for this overlay is not yet
present on ti-linux-5.10.y

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
---
 conf/machine/j7-evm.conf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/conf/machine/j7-evm.conf b/conf/machine/j7-evm.conf
index ee23207b..2620ec11 100644
--- a/conf/machine/j7-evm.conf
+++ b/conf/machine/j7-evm.conf
@@ -14,7 +14,6 @@ KERNEL_DEVICETREE = " \
     ti/k3-j721e-proc-board-tps65917.dtb \
     ti/k3-j721e-common-proc-board-infotainment.dtbo \
     ti/k3-j721e-pcie-backplane.dtbo \
-    ti/k3-j721e-common-proc-board-jailhouse.dtbo \
 "
 
 UBOOT_MACHINE = "j721e_evm_a72_config"
-- 
2.17.1

[dunfell/master PATCH 2/6] Revert "j7-evm: add new k3-j721e-proc-board-tps65917.dtb"

[praneeth]

From: Praneeth Bajjuri <praneeth@ti.com>

This reverts commit 7ce8ddaf75b9ec40d69b4059c9ca3040a509f7d5.

Reverting for now, as the support for this dtb is not yet
present on ti-linux-5.10.y

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
---
 conf/machine/j7-evm.conf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/conf/machine/j7-evm.conf b/conf/machine/j7-evm.conf
index 2620ec11..ad59b502 100644
--- a/conf/machine/j7-evm.conf
+++ b/conf/machine/j7-evm.conf
@@ -11,7 +11,6 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 KERNEL_DEVICETREE = " \
     ti/k3-j721e-common-proc-board.dtb \
-    ti/k3-j721e-proc-board-tps65917.dtb \
     ti/k3-j721e-common-proc-board-infotainment.dtbo \
     ti/k3-j721e-pcie-backplane.dtbo \
 "
-- 
2.17.1

[dunfell/master PATCH 3/6] Revert "j7-evm: add new infotainment DTBO file"

[praneeth]

From: Praneeth Bajjuri <praneeth@ti.com>

This reverts commit e8a9485db6310252317a68ed155e35d9d6c9f7f2.

Reverting for now, as the support for this overlay is not yet
present on ti-linux-5.10.y

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
---
 conf/machine/j7-evm.conf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/conf/machine/j7-evm.conf b/conf/machine/j7-evm.conf
index ad59b502..884c524d 100644
--- a/conf/machine/j7-evm.conf
+++ b/conf/machine/j7-evm.conf
@@ -11,7 +11,6 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 KERNEL_DEVICETREE = " \
     ti/k3-j721e-common-proc-board.dtb \
-    ti/k3-j721e-common-proc-board-infotainment.dtbo \
     ti/k3-j721e-pcie-backplane.dtbo \
 "
 
-- 
2.17.1

[dunfell/master PATCH 4/6] Revert "j7-evm: add k3-j721e-pcie-backplane.dtbo"

[praneeth]

From: Praneeth Bajjuri <praneeth@ti.com>

This reverts commit dc9ca5ef3a4da4ab3e5da8d189fa9cfd087005da.

Reverting for now, as the support for this overlay is not yet
present on ti-linux-5.10.y

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
---
 conf/machine/j7-evm.conf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/conf/machine/j7-evm.conf b/conf/machine/j7-evm.conf
index 884c524d..1b99baeb 100644
--- a/conf/machine/j7-evm.conf
+++ b/conf/machine/j7-evm.conf
@@ -11,7 +11,6 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 KERNEL_DEVICETREE = " \
     ti/k3-j721e-common-proc-board.dtb \
-    ti/k3-j721e-pcie-backplane.dtbo \
 "
 
 UBOOT_MACHINE = "j721e_evm_a72_config"
-- 
2.17.1

[dunfell/master PATCH 5/6] Revert "conf: machine: j7200-evm: Add Jailhouse overlay"

[praneeth]

From: Praneeth Bajjuri <praneeth@ti.com>

This reverts commit 00dc1b1cd70f56dba577bb647c118b8df27f5a46.

Reverting for now, as the support for this overlay is not yet
present on ti-linux-5.10.y

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
---
 conf/machine/j7200-evm.conf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/conf/machine/j7200-evm.conf b/conf/machine/j7200-evm.conf
index 5ee6c89c..2565c90c 100644
--- a/conf/machine/j7200-evm.conf
+++ b/conf/machine/j7200-evm.conf
@@ -9,7 +9,6 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 KERNEL_DEVICETREE = " \
     ti/k3-j7200-common-proc-board.dtb \
-    ti/k3-j7200-common-proc-board-jailhouse.dtbo \
 "
 
 UBOOT_MACHINE = "j7200_evm_a72_config"
-- 
2.17.1

[dunfell/master PATCH 6/6] conf/machine: am65xx: Remove non-existent dtb* from 5.10

[praneeth]

From: Praneeth Bajjuri <praneeth@ti.com>

Remove the non-existent dtb* , as they are not currently present on
ti-linux-5.10.y.

-    ti/k3-am654-base-board-sr1.dtb
-    ti/k3-am654-gp.dtbo
-    ti/k3-am654-idk.dtbo
-    ti/k3-am654-idk-sr1.dtbo
-    ti/k3-am654-evm-hdmi.dtbo
-    ti/k3-am654-evm-oldi-lcd1evm.dtbo
-    ti/k3-am654-evm-tc358876.dtbo
-    ti/k3-am654-pcie-usb2.dtbo
-    ti/k3-am654-pcie-usb3.dtbo
-    ti/k3-am654-base-board-jailhouse.dtbo
-    ti/k3-am654-evm-prupwm.dtbo

Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
---
 conf/machine/include/am65xx.inc | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/conf/machine/include/am65xx.inc b/conf/machine/include/am65xx.inc
index 547c2e87..2a813f20 100644
--- a/conf/machine/include/am65xx.inc
+++ b/conf/machine/include/am65xx.inc
@@ -8,17 +8,6 @@ SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 KERNEL_DEVICETREE = " \
     ti/k3-am654-base-board.dtb \
-    ti/k3-am654-base-board-sr1.dtb \
-    ti/k3-am654-gp.dtbo \
-    ti/k3-am654-idk.dtbo \
-    ti/k3-am654-idk-sr1.dtbo \
-    ti/k3-am654-evm-hdmi.dtbo \
-    ti/k3-am654-evm-oldi-lcd1evm.dtbo \
-    ti/k3-am654-evm-tc358876.dtbo \
-    ti/k3-am654-pcie-usb2.dtbo \
-    ti/k3-am654-pcie-usb3.dtbo \
-    ti/k3-am654-base-board-jailhouse.dtbo \
-    ti/k3-am654-evm-prupwm.dtbo \
 "
 
 BBMULTICONFIG += "k3r5-sr2"
-- 
2.17.1

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

[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(-)
> 

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

[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(-)
> 

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

[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

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

[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(-)
>>>
> 

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

[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

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

[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

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

[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(-)
>>>>>>
>>>>
> 

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

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

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

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

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

[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