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

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

[Post Lauren-RAA013]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

Yocto i.MX community,

We are preparing a 3.10.9-1.0.0 alpha release to replace the 3.5.7-1.0.0 alpha release.   I'd like to get this merged into the dora branch and wish to submit patches this week before the master/dora branches are forked.   Our release will support all mx6 freescale boards including imx6slevk

Since the Yocto i.MX community has a 3.10 fslc community kernel, parts of our 3.10.9 release will probably fix issues that have been posted regarding builds that need the uapi header include.

I've done a small sanity test and verified the 3.10.9-1.0.0 graphics packages from this release on mx6 work on 3.0.35 mx6 with the community uboot.  This graphics package supports improvements in window performance beyond the 3.5.7 and 3.0.35-4.1.0 releases.

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.

Thanks,
Lauren Post
i.MX Yocto Team Lead

[-- Attachment #2: Type: text/html, Size: 3202 bytes --]

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

[Diego]

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

Bests,
Diego

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

[Otavio Salvador]

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.

When 3.10.9 turns GA we may make it default or not. 3.0.35 needs to be
kept around due backward support.

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

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

[Daiane Angolini]

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

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

-- 
Daiane

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

[John Weber]

On 10/2/13 8: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.
>
> When 3.10.9 turns GA we may make it default or not. 3.0.35 needs to be
> kept around due backward support.
>
Agreed, at this stage 3.10.9 looks very appealing and it would be good to get 
into Yocto as an alternative so that people can start testing it (and more 
platforms can start adding support for it).

John

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

[Eric Nelson]

Hi Otavio,

On 10/02/2013 06: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.
>
> When 3.10.9 turns GA we may make it default or not. 3.0.35 needs to be
> kept around due backward support.
>

Has anyone done a gap-analysis that shows which features
are available on 3.10?

We've been tracking the progress of our testing against
3.5.7 in this blog post, and there are significant gaps
in functionality for our boards vs. 3.0.35:

	http://boundarydevices.com/i-mx6-3-5-7

For us, the primary gaps are support for Solo/Dual-Lite
processor variants and camera/video input support.

It seems that the same sort of test is appropriate for
the Freescale boards.

OTOH, perhaps the quickest way to get the gaps fixed
is to jump...

Regards,


Eric

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

[Eric Nelson]

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.

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.

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.

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.

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.

Regards,


Eric

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

[Otavio Salvador]

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.

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

> 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

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

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

[Post Lauren-RAA013]

3.10.9 will be a GA kernel by early next year.

3.5.7-alpha2 is just graphics package (fixes beyond 3.0.35-4.1.0 based on p12 version)
3.10.9-1.0.0_alpha graphics is still p12 based with additional fixes beyond 3.5.7-alpha2 so it should replace 3.5.7-alpha2.  3.10.9 also provides full Weston-wayland support.

We understand that 3.0.35-4.1.0 is the current GA current and is preferred by those wanting a stable kernel.  Just note that the non-kernel packages are pretty close to the 3.0.35-4.1.0 release that just came out in August so I'm not that worried about stability.  I built with community 3.0.35 and community uboot 2013.10 and had no problems with non-kernel 3.10.9 components.  Unfortunately we don't have test resources to test 3.0.35-4.1.0 with 3.10.9-1.0.0 non-kernel components but my sanity test showed it worked.  Imx-test requires one update for a header name change between the kernels that I've sent to Otavio.

The 3.10.9 release has all the imx6 boards including imx6 solo lite and it went through a full test cycle for our alpha release (and will go through more test cycles for beta and ga).

The goal is to get this integrated so that our GA 3.10.9 kernel will be on a stable yocto branch.  Our future 3.10.9 beta and GA will be based on the dora branch not the master branch.

Our other option is just release on our release layer meta-fsl-bsp-release and that is normally our plan but since dora is just coming out we asked for an exception for this time since our GA will be complete far before Yocto 1.6 is available.

Lauren
i.MX Yocto Team Lead

-----Original Message-----
From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Otavio Salvador
Sent: Wednesday, October 02, 2013 10:11 AM
To: Eric Nelson
Cc: meta-freescale@yoctoproject.org; Diego
Subject: Re: [meta-freescale] Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm

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.

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

> 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

-- 
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
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

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

[Eric Nelson]

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

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

[Eric Nelson]

Thanks Lauren,

These details are very helpful.

On 10/02/2013 08:41 AM, Post Lauren-RAA013 wrote:
> 3.10.9 will be a GA kernel by early next year.
>
> 3.5.7-alpha2 is just graphics package (fixes beyond 3.0.35-4.1.0
 > based on p12 version)
 >
And Device-tree support... This clearly made major strides leading to
3.10 and main-line.

> 3.10.9-1.0.0_alpha graphics is still p12 based with additional fixes
 > beyond 3.5.7-alpha2 so it should replace 3.5.7-alpha2.

Thanks again. We should be able to examine the changes and
look for ABI-compatibility.

 > 3.10.9 also provides full Weston-wayland support.
>
> We understand that 3.0.35-4.1.0 is the current GA current and is preferred
 > by those wanting a stable kernel.  Just note that the non-kernel
 > packages are pretty close to the 3.0.35-4.1.0 release that just
 > came out in August so I'm not that worried about stability.
 >

Stability hasn't been an issue with our testing of 3.5.7, but
there were significant gaps for things like PCIe, cameras, and
such (at least for us).

 > I built with community 3.0.35 and community uboot 2013.10 and
 > had no problems with non-kernel 3.10.9 components.
 >
> Unfortunately  we don't have test resources to test 3.0.35-4.1.0
 > with 3.10.9-1.0.0 non-kernel components but my sanity test showed
 > it worked.  Imx-test requires one update for a header name change
 > between the kernels that I've sent to Otavio.
>

We should be able to help here. After all, "community" is a two-way
street, right?

> The 3.10.9 release has all the imx6 boards including imx6 solo
 > lite and it went through a full test cycle for our alpha release
 > (and will go through more test cycles for beta and ga).
>
> The goal is to get this integrated so that our GA 3.10.9 kernel
 > will be on a stable yocto branch.
 >
 > Our future 3.10.9 beta and GA will be based on the dora branch
 > not the master branch.
>
> Our other option is just release on our release layer
 > meta-fsl-bsp-release and that is normally our plan but since
 > dora is just coming out we asked for an exception for this
 > time since our GA will be complete far before Yocto 1.6 is available.
>
Sounds good to me.

Regards,


Eric

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

[Eric Nelson]

On 10/02/2013 09:28 AM, Eric Nelson wrote:
> Thanks Otavio,
> On 10/02/2013 08:11 AM, Otavio Salvador wrote:
 >
>> On Wed, Oct 2, 2013 at 11:51 AM, Eric Nelson
>>> 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?

Based on Lauren's comments that the 3.10.9 binaries are ABI-compatible
with the 3.0.35_4.1.0 release, and to allow testing of things,
perhaps this is more appropriate:

	PREFERRED_VERSION_blah ?= 3.10.9-1.0.0-alpha

Regards,


Eric

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

[Post Lauren-RAA013]

Just to be clear.

3.0.35 is not going to be removed.

3.10.9-1.0.0_alpha will replace 3.5.7-1.0.0_alpha on the dora branch.

At some point in 2014 after community consensus and 3.10 is a GA kernel we hope to replace 3.0.35 with 3.10 but that is next year and we'll have this alpha, beta release to make sure it is acceptable to transition.   Unfortunately we don't have resources internally to test the community 3.0.35 kernel with non-kernel 3.10.9-1.0.0 packages.  I've done just a sanity test to make sure it works.

Components that are updated
- Multimedia upgraded to 3.0.9 and vpu wrapper upgraded to 1.0.40
- Graphics packages updated with Weston and window performance fixes on p12
- Kernel for 3.10.9
- uboot-imx - fixes and updates to support imx6slevk (yes I know this is forked)
- imx-test updated to fix build breaks on Yocto  
(note there is one epdc test that requires a name change to build on 3.0.35 - 
Otavio has this change).
- imx-lib has vpu removed so is back to LGPLv2 license
(this change was part of 3.0.35-4.1.0 release)
- imx-vpu created as separate component because it has different licensing.
(Daiane is working on mx53 similar solution)
- machine files updated for additional device trees for various pin configurations
- wayland-Weston, cogl and clutter updated for Weston-wayland builds

Most of the patches have been submitted and are undergoing review process.

Lauren Post
i.MX Yocto Team Lead

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

[Gonzalez, Alex]

Hi,

After reading this I decided to make a sanity check on the 3.10.9 kernel from the fsl-linux-2.6-imx/imx_3.10.9_1.0.0_alpha branch [1]. I am using a Sabre SD board.

With the default kernel configuration (imx_v6_v7_defconfig) and the sabre SD device tree (imx6q-sabresd.dts) I am seeing a crash on gpu_init. If I compile without GPU support it boots fine. Some debug shows the first register write in gckHARDWARE_Construct() is causing the crash:

    gcmkONERROR(gckOS_WriteRegisterEx(Os,                                       
                                      Core,                                     
                                      0x00000,                                  
                                      0x00000900));

This code hasn't changed much from 3.5 and it worked there.

Is anyone seeing this or is it only me?

Thanks,
Alex

[1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.10.9_1.0.0_alpha

-----Original Message-----
From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Post Lauren-RAA013
Sent: miércoles, 02 de octubre de 2013 20:41
To: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm

Just to be clear.

3.0.35 is not going to be removed.

3.10.9-1.0.0_alpha will replace 3.5.7-1.0.0_alpha on the dora branch.

At some point in 2014 after community consensus and 3.10 is a GA kernel we hope to replace 3.0.35 with 3.10 but that is next year and we'll have this alpha, beta release to make sure it is acceptable to transition.   Unfortunately we don't have resources internally to test the community 3.0.35 kernel with non-kernel 3.10.9-1.0.0 packages.  I've done just a sanity test to make sure it works.

Components that are updated
- Multimedia upgraded to 3.0.9 and vpu wrapper upgraded to 1.0.40
- Graphics packages updated with Weston and window performance fixes on p12
- Kernel for 3.10.9
- uboot-imx - fixes and updates to support imx6slevk (yes I know this is forked)
- imx-test updated to fix build breaks on Yocto  
(note there is one epdc test that requires a name change to build on 3.0.35 - 
Otavio has this change).
- imx-lib has vpu removed so is back to LGPLv2 license
(this change was part of 3.0.35-4.1.0 release)
- imx-vpu created as separate component because it has different licensing.
(Daiane is working on mx53 similar solution)
- machine files updated for additional device trees for various pin configurations
- wayland-Weston, cogl and clutter updated for Weston-wayland builds

Most of the patches have been submitted and are undergoing review process.

Lauren Post
i.MX Yocto Team Lead

_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale