* Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm @ 2013-10-01 16:34 Post Lauren-RAA013 2013-10-02 13:06 ` Diego 0 siblings, 1 reply; 14+ messages in thread From: Post Lauren-RAA013 @ 2013-10-01 16:34 UTC (permalink / raw) To: meta-freescale@yoctoproject.org [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-01 16:34 Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm Post Lauren-RAA013 @ 2013-10-02 13:06 ` Diego 2013-10-02 13:55 ` Otavio Salvador 0 siblings, 1 reply; 14+ messages in thread From: Diego @ 2013-10-02 13:06 UTC (permalink / raw) To: meta-freescale > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 13:06 ` Diego @ 2013-10-02 13:55 ` Otavio Salvador 2013-10-02 13:56 ` Daiane Angolini ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Otavio Salvador @ 2013-10-02 13:55 UTC (permalink / raw) To: Diego; +Cc: meta-freescale@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 13:55 ` Otavio Salvador @ 2013-10-02 13:56 ` Daiane Angolini 2013-10-02 14:51 ` Eric Nelson 2013-10-02 14:01 ` John Weber 2013-10-02 14:24 ` Eric Nelson 2 siblings, 1 reply; 14+ messages in thread From: Daiane Angolini @ 2013-10-02 13:56 UTC (permalink / raw) To: Otavio Salvador, Diego; +Cc: meta-freescale@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 13:56 ` Daiane Angolini @ 2013-10-02 14:51 ` Eric Nelson 2013-10-02 15:11 ` Otavio Salvador 0 siblings, 1 reply; 14+ messages in thread From: Eric Nelson @ 2013-10-02 14:51 UTC (permalink / raw) To: Daiane Angolini, Otavio Salvador, Diego; +Cc: meta-freescale@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 14:51 ` Eric Nelson @ 2013-10-02 15:11 ` Otavio Salvador 2013-10-02 15:41 ` Post Lauren-RAA013 2013-10-02 16:28 ` Eric Nelson 0 siblings, 2 replies; 14+ messages in thread From: Otavio Salvador @ 2013-10-02 15:11 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale@yoctoproject.org, Diego 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 15:11 ` Otavio Salvador @ 2013-10-02 15:41 ` Post Lauren-RAA013 2013-10-02 16:51 ` Eric Nelson 2013-10-02 16:28 ` Eric Nelson 1 sibling, 1 reply; 14+ messages in thread From: Post Lauren-RAA013 @ 2013-10-02 15:41 UTC (permalink / raw) To: meta-freescale@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 15:41 ` Post Lauren-RAA013 @ 2013-10-02 16:51 ` Eric Nelson 0 siblings, 0 replies; 14+ messages in thread From: Eric Nelson @ 2013-10-02 16:51 UTC (permalink / raw) To: Post Lauren-RAA013, meta-freescale@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 15:11 ` Otavio Salvador 2013-10-02 15:41 ` Post Lauren-RAA013 @ 2013-10-02 16:28 ` Eric Nelson 2013-10-02 16:56 ` Eric Nelson 1 sibling, 1 reply; 14+ messages in thread From: Eric Nelson @ 2013-10-02 16:28 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale@yoctoproject.org, Diego 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 16:28 ` Eric Nelson @ 2013-10-02 16:56 ` Eric Nelson 2013-10-02 18:40 ` Post Lauren-RAA013 0 siblings, 1 reply; 14+ messages in thread From: Eric Nelson @ 2013-10-02 16:56 UTC (permalink / raw) To: Otavio Salvador Cc: meta-freescale@yoctoproject.org, Diego, Post Lauren-RAA013 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 16:56 ` Eric Nelson @ 2013-10-02 18:40 ` Post Lauren-RAA013 2013-10-22 13:09 ` Gonzalez, Alex 0 siblings, 1 reply; 14+ messages in thread From: Post Lauren-RAA013 @ 2013-10-02 18:40 UTC (permalink / raw) To: meta-freescale@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 18:40 ` Post Lauren-RAA013 @ 2013-10-22 13:09 ` Gonzalez, Alex 0 siblings, 0 replies; 14+ messages in thread From: Gonzalez, Alex @ 2013-10-22 13:09 UTC (permalink / raw) To: Post Lauren-RAA013, meta-freescale@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 13:55 ` Otavio Salvador 2013-10-02 13:56 ` Daiane Angolini @ 2013-10-02 14:01 ` John Weber 2013-10-02 14:24 ` Eric Nelson 2 siblings, 0 replies; 14+ messages in thread From: John Weber @ 2013-10-02 14:01 UTC (permalink / raw) To: meta-freescale 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm 2013-10-02 13:55 ` Otavio Salvador 2013-10-02 13:56 ` Daiane Angolini 2013-10-02 14:01 ` John Weber @ 2013-10-02 14:24 ` Eric Nelson 2 siblings, 0 replies; 14+ messages in thread From: Eric Nelson @ 2013-10-02 14:24 UTC (permalink / raw) To: Otavio Salvador, Diego; +Cc: meta-freescale@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-10-22 13:09 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-10-01 16:34 Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm Post Lauren-RAA013 2013-10-02 13:06 ` Diego 2013-10-02 13:55 ` Otavio Salvador 2013-10-02 13:56 ` Daiane Angolini 2013-10-02 14:51 ` Eric Nelson 2013-10-02 15:11 ` Otavio Salvador 2013-10-02 15:41 ` Post Lauren-RAA013 2013-10-02 16:51 ` Eric Nelson 2013-10-02 16:28 ` Eric Nelson 2013-10-02 16:56 ` Eric Nelson 2013-10-02 18:40 ` Post Lauren-RAA013 2013-10-22 13:09 ` Gonzalez, Alex 2013-10-02 14:01 ` John Weber 2013-10-02 14:24 ` Eric Nelson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.