Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Eric Nelson <eric.nelson@boundarydevices.com>]

Hi Otavio,

On 08/19/2014 10:24 AM, Otavio Salvador wrote:
> On Tue, Aug 19, 2014 at 12:55 PM, Eric Nelson
>> Thanks Otavio,
>>
>> On 08/19/2014 06:59 AM, Otavio Salvador wrote:
>>> Hello everyone,
>>>
>>> <snip>
>>>
>>> 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.
> 

This isn't the first time I've been wrong!

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

Customers will be reluctant (and slow) to move to 1.7 for the same
reason as with moving from one kernel to the next. Full regression
testing takes time, and most of our customers will only do this
annually or semi-annually, driven by features and bug fixes.

>
> 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.
>

1.6 isn't going away when 1.7 arrives, so it's not as if this is
a hard deadline.

The 3.10.17 -> 3.10.31 jump will also be much easier than 3.0.35->3.10.

>>> 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.
> 

In many ways, I think we lose a lot when we talk of Freescale kernel
versions here. It seems more to the point to discuss ABI versions
for the closed-source packages, and those are the bits that I'm
particularly interested in pushing forward, since there have been
many bug fixes and enhancements in the latest releases (see Lauren's
list).

>>> 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.
> 

;) See what I mean? You're referring to "3.10.17 GPU" instead of
a GPU version. IMHO, it would be best if these had independent
version references.

To your point about 3.0.35 and the 3.10.17 GPU binaries, I suspect that
the same is true of the 3.10.31 binaries.

Regards,


Eric