[meta-freescale] i.MX 3.10.31-1.1.0_beta release - community feedback requested

Tue Aug 19 10:24:41 PDT 2014

On Tue, Aug 19, 2014 at 12:55 PM, Eric Nelson
<eric.nelson at boundarydevices.com> wrote:
> Thanks Otavio,
>
> On 08/19/2014 06:59 AM, Otavio Salvador wrote:
>> Hello everyone,
>>
>> (Included all people who replied in Cc)
>>
>> On Mon, Aug 18, 2014 at 12:32 PM, Lauren Post <Lauren.Post at freescale.com> wrote:
>>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
>> ...
>>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>>
>>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>>>         o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>>>         o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>>>         o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>>>         o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>>         o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>>>         o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>>
>>> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
>>
>> I gave some thought about community feedback regarding these two options.
>>
>> First I'd like to analyse the facts about the two options:
>>
>> - Option 1 - Conservative option
>>    - 3.10.31-beta is merged ASAP in master-next
>>    - Yocto Project 1.7 is released with 3.10.17-ga
>>    - in October, when we branch 1.7, 3.10.31-beta is merged in master
>>
>>    Consequences:
>>     - Yocto Project 1.7 has 3.10.17 with GA quality for i.MX6 (with
>> all patch released included - 1.0.1, …)
>>     - Yocto Project 1.7 has support for the BSP for i.MX6, by FSL
>>     - Yocto Project 1.7 is a stable branch with a stable BSP (GA
>> quality) for i.MX6
>>     - Freescale allow customers to use Yocto Project 1.7 for production
>>     - Pre-test of 3.10.31-beta is done in master-next focusing Yocto
>> Project 1.8 development cycle
>>     - Test of 3.10.310-beta is done in master as soon as Yocto Project
>> 1.7 is branched
>>
>> - Option 2 - Aggressive option
>>    - 3.10.31-beta is merged ASAP in master
>>    - Yocto Project 1.7 is released with 3.10.31-bea with Beta quality
>>    - Yocto Project 1.7 has 3.10.31 with GA quality merged (expected) in January
>>
>>    Consequences:
>>     - Yocto Project 1.7 has 3.10.31 with Beta quality for i.MX6
>>     - Yocto Project 1.7 DOES NOT has support for the BSP for i.MX6, by FSL
>>     - Yocto Project 1.7 is a stable branch with a Beta BSP for i.MX6
>>     - Freescale advise customers to use Daisy (Yocto Project 1.6 with
>> 3.10.17-ga) for production until 3.10.31-ga is released and merged
>> into Yocto Project 1.7 (expected in January)
>>     - Pre-test of 3.10.31-beta is done in master until end-September
>> as we need to branch for Yocto Project 1.7 release
>>     - Test of 3.10.31-beta is done in Yocto Project 1.7 STABLE release
>>
>> - Option 3 - Maintain both BSPs around
>>    - I deny this as the amount of effort to support and test all this
>> would increase my maintainer work and I see no real benefit on this.
>> So this is a unfeasible.
>>
>
> This is an interesting personality test.
>
> So far, it sounds as if Otavio and Carlos are the conservative
> ones, and Alfonso, Sébastien and I are "aggressive".

I am sure you didn't take this to the personal side, but for clearness
I am not talking about personality but the way we will handle
transitions.

...
>> I think we are doing a great job here. I am aware of several examples
>> where Freescale release fails badly and FSL Community BSP works fine,
>> this can be seen in several examples as:
>>
>>    - use of 3rd-party boards
>>    - kernel customizability
>>
>> The Freescale release is tested only for the boards they enumerate in
>> the Release Notes which comes with the release.
>>
>
> Please note that Freescale's Beta testing has been done against
> components of Yocto 1.7 if I'm not mistaken, and only against
> their kernel sources.

Are you sure?

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/log/?h=daisy_3.10.31-1.1.0_beta

So no. They are not doing extensive test on top of upcoming 1.7.

>> Currently we have 3 vendors which still use 3.0.35 (2 of those -
>> Congatec and SolidRun - does not have 3.10.17 kernels integrated yet)
>> and moving to a newer BSP means breaking all previous kernels as the
>> newer GPU imposes a kernel update. Is it realistic to expect those all
>> vendors to move to 3.10.31-beta in less than 2 months?
>
> The situation is a it messier than that. We also "still use" 3.0.35
> kernels for some of our customers, and that's a situation likely to
> persist for a long while. I suspect that the same is true for any
> vendor doing custom designs or offering SOMs.
>
> The transition to device tree will be a long one.

Great; how are you going to do with 3.0.35 users in 1.7 if we go with newer GPU?

It seems some vendors are finishing their update to 3.10.17 (I know
about Congatec, which sent an initial patch this week, and other
vendors which didn't send patches yet). Expecting they to jump to a
new kernel and GPU in less of a month is not realistic.

>> Trustability is something quite difficult to build, but dead easy to
>> lost. If we release Yocto Project 1.7 with the 3.10.31-beta BSP and it
>> has a severe issue, we will have a broken release until February - at
>> best. The community cannot be expected to provide an extended test of
>> the FSL Community BSP, especially because of the short time before we
>> need to branch for 1.7 release.
>
> I think this is the crux of the question: how much weight do you
> give to the "-beta" and "-GA" tags?
>
> In my experience, Freescale does a pretty good job of testing
> even prior to "-alpha" and "-beta" releases. Without going through
> the entire patch sets, my suspicion is that there are more bug
> fixes in the 3.10.31 kernel than newly-introduced bugs.
>
> e.g., this PCIe bug fix is present in 3.10.31, but doesn't appear
> to be present in 3.10.17_1.0.1:
>         http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.31_1.1.0_beta&id=c8a6b97
>
> At this stage, I've not spent much time with 3.10.31, and I've
> only used it on Freescale hardware (SABRE SD), and I suspect
> that the same is true for others on the list.

Agreed; the point is Freescale won't provide support in case of issues
and any fixes will need to wait until GA goes out.

About backporting fixes I fully agree Freescale ought to be more
active in including fixes in their GA kernel while doing the next-BSP
development. I hope this improves in mid/long term.

>> All that said, I vote for Option 1 - conservative.
>>
>> The possible feedback we, as community, can provide to Freescale I
>> think won't be decisive for the quality of 3.10.31 release. As you all
>> can see our bugzilla[1] has feedback entries which are more than one
>> year[2][3] old and there is no one at Freescale responsible to /fix/
>> these or comment officially on those.
>>
>> 1. https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=meta-fsl-arm
>> 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5098 (opened in
>> September of 2013)
>> 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 (opened in
>> May of 2013)
>>
>> I hope this makes clear my position. If most of the community prefer
>> the Option 2 I will accept it, but I think it is not the best choice.
>>
>
> I'll re-iterate my preference for Option 2, and I think a key piece of
> the equation is Lauren's statement that Freescale's preference is
> Option 2.
>
> As always, the key bits are those which we don't control (closed
> source binaries), and I suspect that the kernel support for those
> is fairly easy to backport to a 3.10.17 kernel if a vendor wants
> to stay there.

Should be.

> Back-ports to 3.0.35 will naturally be harder, but we don't solve
> this with Option 1 either.

3.0.35 should be easy to update to kernel GPU, if you look at their Git:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.1.0&id=5e5f0d6d0d9c022c93e4a8c3680b682e2b8f6b4f

So vendors wishing to use 3.0.35 with 3.10.17 GPU is very possible.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750