Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm

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

Thanks Otavio,

On 10/02/2013 08:11 AM, Otavio Salvador wrote:
> On Wed, Oct 2, 2013 at 11:51 AM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> On 10/02/2013 06:56 AM, Daiane Angolini wrote:
>>>
>>> On 10/02/2013 10:55 AM, Otavio Salvador wrote:
>>>>
>>>> On Wed, Oct 2, 2013 at 10:06 AM, Diego <diego.ml@zoho.com> wrote:
>>>>>>
>>>>>> Otavio requested for the community to approve this change since the
>>>>>> dora
>>>>>> branch is being finalized in next 2 weeks.  I'll be upstreaming
>>>>>> patches to
>>>>>> master-next this week so they can be tested by end of the week.  Please
>>>>>> reply to this email if you have a concern with integrating 3.10.9-1.0.0
>>>>>> into the dora branch.
>>>>>
>>>>>
>>>>> Hi Lauren.
>>>>>
>>>>> I think there's no objection for merge if that won't be the default.
>>>>>
>>>>> What would be the kernel state for dora then?
>>>>> - 3.0.35 with Vivante 4.6.9p12 patches as default
>>>>> - 3.5.7 alpha2 as an option
>>>>> - 3.10.9 alpha as an option
>>>>>
>>>>> Is that what you were thinking?
>>>>
>>>> I'd prefer to replace 3.5.7 with 3.10.9.
>>>
>>> +1
>>
>> -1 (comments below)
>>
>>>>
>>>> When 3.10.9 turns GA we may make it default or not. 3.0.35 needs to be
>>>> kept around due backward support.
>>>
>>> Do not forget that 3.10.9-1.0.0 is not only kernel. It's all BSP packages
>>>
>> Thanks for pointing this out. I had assumed backward-compatibility with
>> 3.5.7/3.0.35_4.1.0 packages.
>>
>> Patches haven't yet been submitted for the other bits, have they?
>>
>> It would be really nice if this update came with a bit more commentary
>> about ABI and functional compatibility rather than a single patch
>> submission and a new branch magically appearing on git.freescale.com.
>
> +1
>
>> I'd really like to see Dora become a stable platform for those wanting
>> to test the full functionality of their boards. We never really had
>> that for kernel versions 3.0.35_4.0.0, and only have that for
>> 3.0.35_4.1.0 on Dora.
>
> +1
>
>> If there isn't some form of PREFERRED_VERSION_ support for 3.0.35_4.1.0
>> that allows a stable, fully-functional build, I think that 3.10.9 should
>> be pushed into either "master" or a "next" branch.
>
> Yes; the idea is to keep 3.0.35-4.1.0 as default until 3.10.9 turns
> GA. After that I think we ought to support 3.0.35-4.1.0 for Dora along
> with 3.10.9-1.0.0 (be it default or not) and for 1.6 plan to drop
> 3.0.35-4.1.0.
>

That's a relief! I was very happy to see that things "just worked"
with the latest kernel with the Dora release and twitched a bit
when I thought a 3.10 upgrade was going to break things.

BTW, thanks for all your efforts getting Dora ready for prime-time!

>> What's more, I think it's very important for different boards to be
>> able to specify which kernel version is recommended for each, since
>> the efforts behind them progress along different time-lines.
>
> Yes; this can be done. We does it already and Bondary's boards also
> use a different kernel.
>

Kernel, yes.

But at the moment, there's no way for a board/kernel to select
the revision of binaries, right?
	https://github.com/Freescale/meta-fsl-arm/blob/dora/recipes-multimedia/libfslvpuwrap/libfslvpuwrap_1.0.38.bb

Or can we, for instance, have two recipes for the components,
e.g.
	gpu-viv-bin-mx6q_3.5.7-1.0.0-alpha.2-hfp.bb
	gpu-viv-bin-mx6q_3.10.9-1.0.0-alpha-hfp.bb

and express PREFERRED_VERSION_gpu-viv-bin-mx6q=3.5.7-1.0.0-alpha.2
in the linux-boundary_3.0.35.bb recipe and then set
PREFERRED_VERSION_gpu-viv-bin-mx6q=3.10.9-1.0.0-alpha.2 in a
linux-boundary_3.10.9.bb recipe?

If this is possible, then I retract my nack and the only
concern is that the patches for gstreamer/vpu/imx-lib/GPU
are still missing for 3.10.9.

>> If we don't have the structure to support this, each board vendor
>> will (and should) probably plan on forking meta-freescale for their
>> own efforts, which would be a shame.
>
> Please don't. Or it will turn to be LTIB 2.0 :P
>
I don't want to go there!

Regards,


Eric