Re: [meta-ti][master/kirkstone][PATCH] linux-ti-staging: Add 6.1 recipe

[Ryan Eatmon <reatmon@ti.com>]

On 3/15/2023 12:55, Andrew Davis wrote:
> On 3/14/23 2:52 PM, Denys Dmytriyenko wrote:
>> On Tue, Mar 14, 2023 at 11:46:23AM -0500, Bajjuri, Praneeth wrote:
>>> On 3/14/2023 11:37 AM, Ryan Eatmon wrote:
>>>>
>>>> Is there a better way of adding 6.1 without destroying the 5.10
>>>> support?   Because until we have 6.1 up and working it would be
>>>> nice to have a working kirkstone for anyone using it...
>>>
>>> Want to hear from denys as well based on past migration history.
>>>
>>> IMO, there was a window during early migration at 5.10 phase where
>>> we limited features to get the initial baseline ready and added
>>> overlays over the time when kernel added the same.
>>
>> Yes, this will be a major regression for existing customers using meta-ti
>> on Kirkstone!
>>
> 
> Kirkstone is not productized yet, I know it is late but that is the
> reality, customers should see Kirkstone as a preview until then.


While in principle I agree that we have not claimed that kirkstone is 
ready, it has not stopped some people from looking ahead into kirkstone 
and even master.


>> In the past, Yocto migration was better aligned with the BSP migration 
>> and
>> both would happen at about the same time every year. So, the new BSP 
>> would
>> be available in the new Yocto branch and there was a choice of using 
>> an old
>> branch with stable and feature-complete BSP, or a new, but unstable and
>> initially incomplete branch. That provided extra freedom and flexibility
>> to start completely from scratch in the new branch...
>>
>> That has changed a bit recently with 5.4 -> 5.10 migration happening in
>> Dunfell couple of years ago. And this time around 5.10 -> 6.1 in 
>> Kirkstone.
>> Both branches are Yocto LTS with many active users having some 
>> expectation
>> of stability.
>>
> 
> Dunfell should use 5.10, Kirkstone should use the newer kernel, I don't
> see the need to support both kernels on Kirkstone, especially if it will 
> just
> be temporary anyway. The juggling of both kernels during the migration will
> slow us down, better to move fast here to get Kirkstone users back up and
> running on the latest kernel.

As we continue to keep master more in mind and up to date with things 
going forward, this topic will continue to come up.  We cannot just nuke 
what is working to get something new going.  I think the best approach 
would be to not break the previous kernel in favor of the new kernel. 
We need to figure out a way to support both during the transition.


>> In Dunfell, initial 5.10 recipe was added in mid-January 2021:
>> https://git.yoctoproject.org/meta-ti/commit/?id=874ff0d7f9f31703e0a71a9f5d968051b77c2df0
>>
>> It broke things for many people and I suggested marking it to not be used
>> as the default:
>> https://git.yoctoproject.org/meta-ti/commit/?id=6496a0edeb8a84bfb1b9e13ec58814ea5babcde7
>>
>> Three months later, by mid-April 2021 the change was reverted and 5.10 
>> got
>> promoted to the default:
>> https://git.yoctoproject.org/meta-ti/commit/?id=7793303e6c1543e5058bf1a7e83ea72f3a45c079
>>
>> Although I'd argue it was a bit too soon, as lots of DTBs/DTBOs still 
>> had to
>> be removed from machine configs:
>> https://git.yoctoproject.org/meta-ti/commit/?id=8b206b32ec181624b929aa7f998f26ed99e140a7
>> https://git.yoctoproject.org/meta-ti/commit/?id=fb0a0ddd25d4308152ce8243e00b444cbb5d565d
>> https://git.yoctoproject.org/meta-ti/commit/?id=9ea50db095f91bad7c9b2f643347dc25be6e10dd
>> https://git.yoctoproject.org/meta-ti/commit/?id=ad28c5878171ef5b364f6bc9d8a5de514731964b
>> https://git.yoctoproject.org/meta-ti/commit/?id=ba0ddc5ae9ebf9777d31283f272e4ed518e1f514
>> https://git.yoctoproject.org/meta-ti/commit/?id=43bf0f36a3ac62cc3378688358ba704a27b501ce
>> https://git.yoctoproject.org/meta-ti/commit/?id=8bdfe1413c00e0c55132989dafcf8d91827999c3
>>
>>
>>> Remove all non-upstream Device Tree Overlays. We could have filtered 
>>> them
>>> out like as done in mainline and next testing. The issue would be as 
>>> they
>>> are added back to 6.1 and upstream we would need to conditionally
>>> re-enable each. Easier to get a clean start.
>>
>> I'd say we set DEFAULT_PREFERENCE = "-1" and, indeed, use automatic 
>> filtering
>> of DT files similar to mainline/next recipes, until 6.1 mostly catches 
>> up and
>> have majority of them integrated...
>>
> 
> Automatic filtering will not work, there are also DTBs that are not 
> overlays
> that are not upstream either. In other cases DTB names have changed. We 
> would
> need to maintain a list for each 5.10, 6.1, mainline, and next kernels. 
> That
> multiplied by each MACHINE.
> 
> Populating KERNEL_DEVICETREE based on what the kernel actually builds seems
> like the only reasonable solution today.
> 
> Andrew

The problem is that yocto supports the idea of multiple kernels, but has 
only a single KERNEL_DEVICETREE for a given platform.  And in addition 
to that issue, the KERNEL_DEVICETREE is used in a few recipes and so we 
cannot just move where this is defined into the kernel where it make 
sense.  We might need to think of a new way of handling this that can 
solve the issue in the most flexible manner.


-- 
Ryan Eatmon                reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc.  -  LCPD  -  MGTS