* i.MX 3.10.31-1.1.0_beta release - community feedback requested [not found] ` <8f1e8166115a4a4381ded78a5536c001@BY2PR03MB379.namprd03.prod.outlook.com> @ 2014-08-18 15:32 ` Lauren Post 2014-08-18 15:54 ` Alfonso Tamés ` (3 more replies) 0 siblings, 4 replies; 28+ messages in thread From: Lauren Post @ 2014-08-18 15:32 UTC (permalink / raw) To: meta-freescale 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. This release has the following new features - Kernel upgrade to 3.10.31 - Supports new i.MX6 SoloX SabreSD machine - U-Boot-imx upgrade to 2014.04 version - New GPU Vivante version v5 o Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs. o DirectFB 1.7.1 o Wayland 1.5 o Xorg 1.15 o Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU. o i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends. o fsl-gpu-sdk version 1.2 supporting all backends. - Multimedia Features o Freescale Gstreamer 1.0 support o Gstreamer 0.1 Fixes o Upgraded VPU firmware and wrapper software o G2D integration 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. Thanks, Lauren Post Yocto Project i.MX Team Lead ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-18 15:32 ` i.MX 3.10.31-1.1.0_beta release - community feedback requested Lauren Post @ 2014-08-18 15:54 ` Alfonso Tamés 2014-08-18 17:28 ` Eric Nelson 2014-08-18 19:35 ` Carlos Rafael Giani 2014-08-19 2:32 ` Sébastien Taylor ` (2 subsequent siblings) 3 siblings, 2 replies; 28+ messages in thread From: Alfonso Tamés @ 2014-08-18 15:54 UTC (permalink / raw) To: Lauren Post; +Cc: meta-freescale Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace the future in master branch. Thanks, Alfonso > On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@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. > > This release has the following new features > - Kernel upgrade to 3.10.31 > - Supports new i.MX6 SoloX SabreSD machine > - U-Boot-imx upgrade to 2014.04 version > - New GPU Vivante version v5 > o Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs. > o DirectFB 1.7.1 > o Wayland 1.5 > o Xorg 1.15 > o Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU. > o i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends. > o fsl-gpu-sdk version 1.2 supporting all backends. > - Multimedia Features > o Freescale Gstreamer 1.0 support > o Gstreamer 0.1 Fixes > o Upgraded VPU firmware and wrapper software > o G2D integration > > 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. > > Thanks, > Lauren Post > Yocto Project i.MX Team Lead > > -- > _______________________________________________ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-18 15:54 ` Alfonso Tamés @ 2014-08-18 17:28 ` Eric Nelson 2014-08-18 19:35 ` Carlos Rafael Giani 1 sibling, 0 replies; 28+ messages in thread From: Eric Nelson @ 2014-08-18 17:28 UTC (permalink / raw) To: Alfonso Tamés, Lauren Post; +Cc: meta-freescale On 08/18/2014 08:54 AM, Alfonso Tamés wrote: > Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace the future in master branch. > +1 > Thanks, > > Alfonso > >> On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@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. >> >> This release has the following new features >> - Kernel upgrade to 3.10.31 >> - Supports new i.MX6 SoloX SabreSD machine >> - U-Boot-imx upgrade to 2014.04 version >> - New GPU Vivante version v5 >> o Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs. >> o DirectFB 1.7.1 >> o Wayland 1.5 >> o Xorg 1.15 >> o Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU. >> o i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends. >> o fsl-gpu-sdk version 1.2 supporting all backends. >> - Multimedia Features >> o Freescale Gstreamer 1.0 support >> o Gstreamer 0.1 Fixes >> o Upgraded VPU firmware and wrapper software >> o G2D integration >> >> 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. >> ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-18 15:54 ` Alfonso Tamés 2014-08-18 17:28 ` Eric Nelson @ 2014-08-18 19:35 ` Carlos Rafael Giani 2014-08-18 21:14 ` John Weber 2014-08-19 0:34 ` Alfonso Tamés 1 sibling, 2 replies; 28+ messages in thread From: Carlos Rafael Giani @ 2014-08-18 19:35 UTC (permalink / raw) To: meta-freescale The EGL backend is broken? I didn't notice. I ran chromium with EGL and GLESv2 based rendering successfully with it. I vote for option 1. Option 2 means there wouldn't be an FSL supported kernel in master until January, which is a rather strange situation. I understand FSL wants to maximize the feedback they get, but isn't it important to have a FSL supported kernel available? Yes, it is there in daisy, but master is a reviewed branch, so customers can actually use it. Instead, I'd keep 3.10.17 , but encourage customers and hobbyists to try out the beta, since they would benefit from this as well. On 08/18/2014 05:54 PM, Alfonso Tamés wrote: > Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace the future in master branch. > > Thanks, > > Alfonso > >> On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@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. >> >> This release has the following new features >> - Kernel upgrade to 3.10.31 >> - Supports new i.MX6 SoloX SabreSD machine >> - U-Boot-imx upgrade to 2014.04 version >> - New GPU Vivante version v5 >> o Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs. >> o DirectFB 1.7.1 >> o Wayland 1.5 >> o Xorg 1.15 >> o Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU. >> o i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends. >> o fsl-gpu-sdk version 1.2 supporting all backends. >> - Multimedia Features >> o Freescale Gstreamer 1.0 support >> o Gstreamer 0.1 Fixes >> o Upgraded VPU firmware and wrapper software >> o G2D integration >> >> 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. >> >> Thanks, >> Lauren Post >> Yocto Project i.MX Team Lead >> >> -- >> _______________________________________________ >> meta-freescale mailing list >> meta-freescale@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-freescale ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-18 19:35 ` Carlos Rafael Giani @ 2014-08-18 21:14 ` John Weber 2014-08-19 0:34 ` Alfonso Tamés 1 sibling, 0 replies; 28+ messages in thread From: John Weber @ 2014-08-18 21:14 UTC (permalink / raw) To: Carlos Rafael Giani; +Cc: meta-freescale [-- Attachment #1: Type: text/plain, Size: 4370 bytes --] The beta will be around for 3+ months after the release of 1.7, I don't think we have an option but to keep 3.10.17 the preferred version. Unless it was really good. And even it it was great, I wouldn't want to remove 3.10.17 recipes as that could be a fallback for users. On Mon, Aug 18, 2014 at 2:35 PM, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: > The EGL backend is broken? I didn't notice. I ran chromium with EGL and > GLESv2 based rendering successfully with it. > > I vote for option 1. Option 2 means there wouldn't be an FSL supported > kernel in master until January, which is a rather strange situation. I > understand FSL wants to maximize the feedback they get, but isn't it > important to have a FSL supported kernel available? Yes, it is there in > daisy, but master is a reviewed branch, so customers can actually use it. > Instead, I'd keep 3.10.17 , but encourage customers and hobbyists to try > out the beta, since they would benefit from this as well. > > > On 08/18/2014 05:54 PM, Alfonso Tamés wrote: > >> Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace >> the future in master branch. >> >> Thanks, >> >> Alfonso >> >> On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@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. >>> >>> This release has the following new features >>> - Kernel upgrade to 3.10.31 >>> - Supports new i.MX6 SoloX SabreSD machine >>> - U-Boot-imx upgrade to 2014.04 version >>> - New GPU Vivante version v5 >>> o Supports OpenGLES 3.0 APIs with backward compatibility with >>> earlier version APIs. >>> o DirectFB 1.7.1 >>> o Wayland 1.5 >>> o Xorg 1.15 >>> o Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX >>> parts containing 3D GPU. >>> o i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer >>> backends. >>> o fsl-gpu-sdk version 1.2 supporting all backends. >>> - Multimedia Features >>> o Freescale Gstreamer 1.0 support >>> o Gstreamer 0.1 Fixes >>> o Upgraded VPU firmware and wrapper software >>> o G2D integration >>> >>> 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. >>> >>> Thanks, >>> Lauren Post >>> Yocto Project i.MX Team Lead >>> >>> -- >>> _______________________________________________ >>> meta-freescale mailing list >>> meta-freescale@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/meta-freescale >>> >> > -- > _______________________________________________ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale > [-- Attachment #2: Type: text/html, Size: 5477 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-18 19:35 ` Carlos Rafael Giani 2014-08-18 21:14 ` John Weber @ 2014-08-19 0:34 ` Alfonso Tamés 1 sibling, 0 replies; 28+ messages in thread From: Alfonso Tamés @ 2014-08-19 0:34 UTC (permalink / raw) To: Carlos Rafael Giani; +Cc: meta-freescale Qt5 and the Vivante demos fail in EGL: https://community.freescale.com/thread/326402 On Aug 18, 2014, at 2:35 PM, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: > The EGL backend is broken? I didn't notice. I ran chromium with EGL and GLESv2 based rendering successfully with it. > > I vote for option 1. Option 2 means there wouldn't be an FSL supported kernel in master until January, which is a rather strange situation. I understand FSL wants to maximize the feedback they get, but isn't it important to have a FSL supported kernel available? Yes, it is there in daisy, but master is a reviewed branch, so customers can actually use it. Instead, I'd keep 3.10.17 , but encourage customers and hobbyists to try out the beta, since they would benefit from this as well. > > On 08/18/2014 05:54 PM, Alfonso Tamés wrote: >> Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace the future in master branch. >> >> Thanks, >> >> Alfonso >> >>> On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@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. >>> >>> This release has the following new features >>> - Kernel upgrade to 3.10.31 >>> - Supports new i.MX6 SoloX SabreSD machine >>> - U-Boot-imx upgrade to 2014.04 version >>> - New GPU Vivante version v5 >>> o Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs. >>> o DirectFB 1.7.1 >>> o Wayland 1.5 >>> o Xorg 1.15 >>> o Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU. >>> o i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends. >>> o fsl-gpu-sdk version 1.2 supporting all backends. >>> - Multimedia Features >>> o Freescale Gstreamer 1.0 support >>> o Gstreamer 0.1 Fixes >>> o Upgraded VPU firmware and wrapper software >>> o G2D integration >>> >>> 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. >>> >>> Thanks, >>> Lauren Post >>> Yocto Project i.MX Team Lead >>> >>> -- >>> _______________________________________________ >>> meta-freescale mailing list >>> meta-freescale@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/meta-freescale > > -- > _______________________________________________ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-18 15:32 ` i.MX 3.10.31-1.1.0_beta release - community feedback requested Lauren Post 2014-08-18 15:54 ` Alfonso Tamés @ 2014-08-19 2:32 ` Sébastien Taylor 2014-08-19 6:56 ` Carlos Rafael Giani 2014-08-19 13:59 ` Otavio Salvador 2014-08-20 22:53 ` Alexander Holler 3 siblings, 1 reply; 28+ messages in thread From: Sébastien Taylor @ 2014-08-19 2:32 UTC (permalink / raw) To: Lauren Post; +Cc: meta-freescale Option 2. Though I fail to see why 3.10.17 would need to be removed Yocto has no issues supporting multiple versions of packages. Seems to me supporting both options is win/win for everyone. On Aug 18, 2014, at 9:32 AM, Lauren Post <lauren.post@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. > > This release has the following new features > - Kernel upgrade to 3.10.31 > - Supports new i.MX6 SoloX SabreSD machine > - U-Boot-imx upgrade to 2014.04 version > - New GPU Vivante version v5 > o Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs. > o DirectFB 1.7.1 > o Wayland 1.5 > o Xorg 1.15 > o Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU. > o i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends. > o fsl-gpu-sdk version 1.2 supporting all backends. > - Multimedia Features > o Freescale Gstreamer 1.0 support > o Gstreamer 0.1 Fixes > o Upgraded VPU firmware and wrapper software > o G2D integration > > 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. > > Thanks, > Lauren Post > Yocto Project i.MX Team Lead > > -- > _______________________________________________ > meta-freescale mailing list > meta-freescale@yoctoproject.org > https://lists.yoctoproject.org/listinfo/meta-freescale ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 2:32 ` Sébastien Taylor @ 2014-08-19 6:56 ` Carlos Rafael Giani 0 siblings, 0 replies; 28+ messages in thread From: Carlos Rafael Giani @ 2014-08-19 6:56 UTC (permalink / raw) To: meta-freescale From my understanding, several parts would be upgraded to 3.10.31-1-1.0 , not just the kernel. I suppose other drivers would be as well. You'd have to keep all of them around. Which is OK for me, but probably not OK for the layer maintainers. Comments? On 08/19/2014 04:32 AM, Sébastien Taylor wrote: > Option 2. Though I fail to see why 3.10.17 would need to be removed Yocto has no issues supporting multiple versions of packages. Seems to me supporting both options is win/win for everyone. > > On Aug 18, 2014, at 9:32 AM, Lauren Post <lauren.post@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. >> >> This release has the following new features >> - Kernel upgrade to 3.10.31 >> - Supports new i.MX6 SoloX SabreSD machine >> - U-Boot-imx upgrade to 2014.04 version >> - New GPU Vivante version v5 >> o Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs. >> o DirectFB 1.7.1 >> o Wayland 1.5 >> o Xorg 1.15 >> o Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU. >> o i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends. >> o fsl-gpu-sdk version 1.2 supporting all backends. >> - Multimedia Features >> o Freescale Gstreamer 1.0 support >> o Gstreamer 0.1 Fixes >> o Upgraded VPU firmware and wrapper software >> o G2D integration >> >> 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. >> >> Thanks, >> Lauren Post >> Yocto Project i.MX Team Lead >> >> -- >> _______________________________________________ >> meta-freescale mailing list >> meta-freescale@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-freescale ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-18 15:32 ` i.MX 3.10.31-1.1.0_beta release - community feedback requested Lauren Post 2014-08-18 15:54 ` Alfonso Tamés 2014-08-19 2:32 ` Sébastien Taylor @ 2014-08-19 13:59 ` Otavio Salvador 2014-08-19 15:55 ` Eric Nelson 2014-08-20 22:53 ` Alexander Holler 3 siblings, 1 reply; 28+ messages in thread From: Otavio Salvador @ 2014-08-19 13:59 UTC (permalink / raw) To: Lauren Post; +Cc: meta-freescale Hello everyone, (Included all people who replied in Cc) On Mon, Aug 18, 2014 at 12:32 PM, Lauren Post <Lauren.Post@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. So before I do a clear statement about my preferred option I would like to extern some thoughts about what I think it is important to ponder when choosing either option. Since the creation of FSL Community BSP we (here I include the most active contributors in the community) been working in to make the user experience as good as possible: code quality, stability and flexibility has always been our goals. 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. 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? 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. 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. Best Regards, -- 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] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 13:59 ` Otavio Salvador @ 2014-08-19 15:55 ` Eric Nelson 2014-08-19 16:01 ` Carlos Rafael Giani 2014-08-19 17:24 ` Otavio Salvador 0 siblings, 2 replies; 28+ messages in thread From: Eric Nelson @ 2014-08-19 15:55 UTC (permalink / raw) To: Otavio Salvador, Lauren Post; +Cc: meta-freescale 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@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". > > So before I do a clear statement about my preferred option I would > like to extern some thoughts about what I think it is important to > ponder when choosing either option. > > Since the creation of FSL Community BSP we (here I include the most > active contributors in the community) been working in to make the user > experience as good as possible: code quality, stability and > flexibility has always been our goals. > Many thanks for this! > 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. > 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. > 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. > 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. Back-ports to 3.0.35 will naturally be harder, but we don't solve this with Option 1 either. Regards, Eric ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 15:55 ` Eric Nelson @ 2014-08-19 16:01 ` Carlos Rafael Giani 2014-08-19 16:22 ` Eric Nelson 2014-08-19 17:24 ` Otavio Salvador 1 sibling, 1 reply; 28+ messages in thread From: Carlos Rafael Giani @ 2014-08-19 16:01 UTC (permalink / raw) To: Eric Nelson, Otavio Salvador, Lauren Post; +Cc: meta-freescale Well, of course Freescale is interested in option 2, since it helps with their kernel development :) But think about it this way: you are a customer, and are using the beta kernel, because that's what is in Yocto Project 1.7. Something goes wrong. You contact your Freescale FAE. Response: "we can't help you, because you are using an unsupported kernel". This is the main problem. Not necessarily the stability of the beta kernel, but the lack of Freescale support. On 2014-08-19 17:55, Eric Nelson 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@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". > >> So before I do a clear statement about my preferred option I would >> like to extern some thoughts about what I think it is important to >> ponder when choosing either option. >> >> Since the creation of FSL Community BSP we (here I include the most >> active contributors in the community) been working in to make the user >> experience as good as possible: code quality, stability and >> flexibility has always been our goals. >> > Many thanks for this! > >> 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. > >> 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. > >> 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. > >> 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. > > Back-ports to 3.0.35 will naturally be harder, but we don't solve > this with Option 1 either. > > Regards, > > > Eric ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 16:01 ` Carlos Rafael Giani @ 2014-08-19 16:22 ` Eric Nelson 2014-08-19 17:21 ` Otavio Salvador 0 siblings, 1 reply; 28+ messages in thread From: Eric Nelson @ 2014-08-19 16:22 UTC (permalink / raw) To: Carlos Rafael Giani, Otavio Salvador, Lauren Post; +Cc: meta-freescale Hi Otavio, On 08/19/2014 09:01 AM, Carlos Rafael Giani wrote: > Well, of course Freescale is interested in option 2, since it helps with > their kernel development :) > Which is a good thing! > But think about it this way: > > you are a customer, and are using the beta kernel, because that's what > is in Yocto Project 1.7. Something goes wrong. You contact your > Freescale FAE. Response: "we can't help you, because you are using an > unsupported kernel". This is the main problem. Not necessarily the > stability of the beta kernel, but the lack of Freescale support. > My experience is that getting support on the latest is easier, since that's where developers tend to live. When Freescale is asked to investigate a bug, they will likely ask that it be reproduced on Freescale hardware and using a Freescale supplied kernel and userspace (i.e. not from the Community BSP). For users of other hardware and kernels (i.e. most of the world), these tend to be the biggest hurdles. By placing the latest (-beta) kernel in master-next now and master in October, we're placing a big hurdle on adoption of 3.10.31. Breakage is common in master and this generally has nothing to do with the kernel or Freescale bits. This is clearly all gray area, and these are just my 2c. Regards, Eric ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 16:22 ` Eric Nelson @ 2014-08-19 17:21 ` Otavio Salvador 2014-08-19 18:25 ` Eric Nelson 0 siblings, 1 reply; 28+ messages in thread From: Otavio Salvador @ 2014-08-19 17:21 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale On Tue, Aug 19, 2014 at 1:22 PM, Eric Nelson <eric.nelson@boundarydevices.com> wrote: > On 08/19/2014 09:01 AM, Carlos Rafael Giani wrote: >> Well, of course Freescale is interested in option 2, since it helps with >> their kernel development :) >> > > Which is a good thing! > >> But think about it this way: >> >> you are a customer, and are using the beta kernel, because that's what >> is in Yocto Project 1.7. Something goes wrong. You contact your >> Freescale FAE. Response: "we can't help you, because you are using an >> unsupported kernel". This is the main problem. Not necessarily the >> stability of the beta kernel, but the lack of Freescale support. >> > > My experience is that getting support on the latest is easier, since > that's where developers tend to live. > > When Freescale is asked to investigate a bug, they will likely ask > that it be reproduced on Freescale hardware and using a Freescale > supplied kernel and userspace (i.e. not from the Community BSP). > > For users of other hardware and kernels (i.e. most of the world), these > tend to be the biggest hurdles. > > By placing the latest (-beta) kernel in master-next now and > master in October, we're placing a big hurdle on adoption of > 3.10.31. Breakage is common in master and this generally has > nothing to do with the kernel or Freescale bits. > > This is clearly all gray area, and these are just my 2c. Just to clarify. What should we do with boards which: a) including in master now means getting 3.10.31 in next stable, in October. b) does not update or fix their kernel to work with newer GPU stack? b is very critical in my point of view as this impacts user experience and if we don't remove broken boards their images will segfault in the boards. What is your view on this? -- 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] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 17:21 ` Otavio Salvador @ 2014-08-19 18:25 ` Eric Nelson 0 siblings, 0 replies; 28+ messages in thread From: Eric Nelson @ 2014-08-19 18:25 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale Hi Otavio, On 08/19/2014 10:21 AM, Otavio Salvador wrote: > On Tue, Aug 19, 2014 at 1:22 PM, Eric Nelson > <eric.nelson@boundarydevices.com> wrote: >> On 08/19/2014 09:01 AM, Carlos Rafael Giani wrote: >>> Well, of course Freescale is interested in option 2, since it helps with >>> their kernel development :) >>> >> >> Which is a good thing! >> >>> But think about it this way: >>> >>> you are a customer, and are using the beta kernel, because that's what >>> is in Yocto Project 1.7. Something goes wrong. You contact your >>> Freescale FAE. Response: "we can't help you, because you are using an >>> unsupported kernel". This is the main problem. Not necessarily the >>> stability of the beta kernel, but the lack of Freescale support. >>> >> >> My experience is that getting support on the latest is easier, since >> that's where developers tend to live. >> >> When Freescale is asked to investigate a bug, they will likely ask >> that it be reproduced on Freescale hardware and using a Freescale >> supplied kernel and userspace (i.e. not from the Community BSP). >> >> For users of other hardware and kernels (i.e. most of the world), these >> tend to be the biggest hurdles. >> >> By placing the latest (-beta) kernel in master-next now and >> master in October, we're placing a big hurdle on adoption of >> 3.10.31. Breakage is common in master and this generally has >> nothing to do with the kernel or Freescale bits. >> >> This is clearly all gray area, and these are just my 2c. > > Just to clarify. > > What should we do with boards which: > > a) including in master now means getting 3.10.31 in next stable, in October. > b) does not update or fix their kernel to work with newer GPU stack? > > b is very critical in my point of view as this impacts user experience > and if we don't remove broken boards their images will segfault in the > boards. > > What is your view on this? > Let 'em use Dora or Daisy. While I'm pulling for the aggressive option in the Community BSP, many of our customers will (and should be) very conservative, and we'll work with them to decide whether they want to back-port updates to the kernel or other packages to their build. The Community BSP should not be viewed as a production distribution. It's purpose should be to provide an easy on-ramp for new users and avenue for pushing things forward. Before shipping product, versions should be locked down as is done in the Freescale "official" releases. Regards, Eric ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 15:55 ` Eric Nelson 2014-08-19 16:01 ` Carlos Rafael Giani @ 2014-08-19 17:24 ` Otavio Salvador 2014-08-19 18:44 ` Eric Nelson 1 sibling, 1 reply; 28+ messages in thread From: Otavio Salvador @ 2014-08-19 17:24 UTC (permalink / raw) To: Eric Nelson; +Cc: meta-freescale On Tue, Aug 19, 2014 at 12:55 PM, Eric Nelson <eric.nelson@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@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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 17:24 ` Otavio Salvador @ 2014-08-19 18:44 ` Eric Nelson 2014-08-19 19:23 ` Lauren Post 0 siblings, 1 reply; 28+ messages in thread From: Eric Nelson @ 2014-08-19 18:44 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 18:44 ` Eric Nelson @ 2014-08-19 19:23 ` Lauren Post 2014-08-19 20:00 ` Otavio Salvador 0 siblings, 1 reply; 28+ messages in thread From: Lauren Post @ 2014-08-19 19:23 UTC (permalink / raw) To: meta-freescale Keeping this short to make it easier to read. Below are my thoughts in responses to the other comments on this thread. - 3.10.31-1.1.0_Beta is released on top of Daisy 1.6. Our process is to build and test on top of the last Yocto Project release. Our GA release will also be based on Daisy because our code freeze for GA is too close to the Yocto Project release for 1.7 to make the upgrade. - 3.10.31 is 3.10.17 plus fixes for existing i.mx6 hardware (but there is new graphics update that is not GA quality) - i.MX6 SoloX is a new hardware which is still beta quality and only supported in 3.10.31 (will not be backported) - Soon 3.10.17 and 3.10.31 graphics will be independent from kernel and would be able to be mixed with each kernel meaning you could use 3.10.31 kernel with v4 graphics (3.10.17) - Eric's point about upgraded proprietary packages is a good one in that our next chance to update them will only be the 3.10.31 GA release so bugs reported earlier help us get these fixed for GA. - There is a higher chance of getting bugs fixed NOW for GA then after GA. Please submit bugs via bugzilla and forward me so I can forward to the teams to investigate. - Everything for 3.10.31-1.1.0_beta is public on our external git - http://git.freescale.com/ and you can build using our release layer on top of daisy http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_beta Try it before making a final decision. Our patches will not be upstreamed until after our field trial concludes this week. Lauren Post Yocto Project i.MX Team Lead ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 19:23 ` Lauren Post @ 2014-08-19 20:00 ` Otavio Salvador 2014-08-19 20:13 ` Eric Bénard ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Otavio Salvador @ 2014-08-19 20:00 UTC (permalink / raw) To: Lauren Post; +Cc: meta-freescale Hello folks, On Tue, Aug 19, 2014 at 4:23 PM, Lauren Post <Lauren.Post@freescale.com> wrote: ... > - Soon 3.10.17 and 3.10.31 graphics will be independent from kernel and would be able to be mixed with each kernel meaning you could use 3.10.31 kernel with v4 graphics (3.10.17) This is a great step in the right direction. So this alleviate part of the trouble we have across vendors. So is it going to be done for the 3.10.31 GA? or still for the Beta? What about the VPU? Is 3.10.31 VPU packages compatible with 3.10.17? > - Eric's point about upgraded proprietary packages is a good one in that our next chance to update them will only be the 3.10.31 GA release so bugs reported earlier help us get these fixed for GA. Eric concern, in my understanding, is about the ABI between the binary blobs and the compatibility against kernel releases. What has changed? What is needed to backport? > - There is a higher chance of getting bugs fixed NOW for GA then after GA. Please submit bugs via bugzilla and forward me so I can forward to the teams to investigate. Please subscribe to the Bugzilla so I can assign the current issues to your account. This easy tracking of reported issues. > - Everything for 3.10.31-1.1.0_beta is public on our external git - http://git.freescale.com/ and you can build using our release layer on top of daisy http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_beta Try it before making a final decision. Our patches will not be upstreamed until after our field trial concludes this week. So folks, one question remain open: Considering we go with option 2, as seem most people prefer, what to do regarding the non-updated boards in meta-fsl-arm-extra? -- 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] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 20:00 ` Otavio Salvador @ 2014-08-19 20:13 ` Eric Bénard 2014-08-19 20:20 ` John Weber 2014-08-20 17:32 ` Sébastien Taylor 2 siblings, 0 replies; 28+ messages in thread From: Eric Bénard @ 2014-08-19 20:13 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale Hi Otavio, Le Tue, 19 Aug 2014 17:00:23 -0300, Otavio Salvador <otavio@ossystems.com.br> a écrit : > So folks, one question remain open: > > Considering we go with option 2, as seem most people prefer, what to > do regarding the non-updated boards in meta-fsl-arm-extra? > simply drop them and let vendors upgrade the support later if their customers ask for it. There is no reason for meta-fsl-arm-extra to block meta-fsl-arm because a vendor pushed a board one time ago expecting community will maintain it for ever. Best regards, Eric ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 20:00 ` Otavio Salvador 2014-08-19 20:13 ` Eric Bénard @ 2014-08-19 20:20 ` John Weber 2014-08-20 13:31 ` Daiane Angolini 2014-08-20 17:32 ` Sébastien Taylor 2 siblings, 1 reply; 28+ messages in thread From: John Weber @ 2014-08-19 20:20 UTC (permalink / raw) To: meta-freescale Hi Otavio, On 8/19/14, 3:00 PM, Otavio Salvador wrote: > Hello folks, > > On Tue, Aug 19, 2014 at 4:23 PM, Lauren Post <Lauren.Post@freescale.com> wrote: > ... >> - Soon 3.10.17 and 3.10.31 graphics will be independent from kernel and would be able to be mixed with each kernel meaning you could use 3.10.31 kernel with v4 graphics (3.10.17) > This is a great step in the right direction. So this alleviate part of > the trouble we have across vendors. So is it going to be done for the > 3.10.31 GA? or still for the Beta? > > What about the VPU? Is 3.10.31 VPU packages compatible with 3.10.17? > >> - Eric's point about upgraded proprietary packages is a good one in that our next chance to update them will only be the 3.10.31 GA release so bugs reported earlier help us get these fixed for GA. > Eric concern, in my understanding, is about the ABI between the binary > blobs and the compatibility against kernel releases. > > What has changed? What is needed to backport? > >> - There is a higher chance of getting bugs fixed NOW for GA then after GA. Please submit bugs via bugzilla and forward me so I can forward to the teams to investigate. > Please subscribe to the Bugzilla so I can assign the current issues to > your account. This easy tracking of reported issues. > >> - Everything for 3.10.31-1.1.0_beta is public on our external git - http://git.freescale.com/ and you can build using our release layer on top of daisy http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_beta Try it before making a final decision. Our patches will not be upstreamed until after our field trial concludes this week. > So folks, one question remain open: > > Considering we go with option 2, as seem most people prefer, what to > do regarding the non-updated boards in meta-fsl-arm-extra? > I am for Option 1, though I see Lauren's point concerning the chances of getting bugs fixed before the release of GA if the kernels are being adopted and tested by the community prior to release. I think this will happen as a matter of course if improvements are made. Let developers work with master-next if they want to work with 3.10.31. I only think that a handful of -extra boards adopting 3.10.31, those currently supporting 3.10.17, before 1.7 lockdown. If updates to the proprietary packages break 3.10.17, you'll get a lot of broken machines in the stable release, with a kernel that is beta quality. One comment on the relative quality of beta vs. GA releases. I found that 3.10.17_beta had a number of issues that were fixed in GA. Just my experience. John ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 20:20 ` John Weber @ 2014-08-20 13:31 ` Daiane Angolini 0 siblings, 0 replies; 28+ messages in thread From: Daiane Angolini @ 2014-08-20 13:31 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale I think a lot has been said, and I agree with arguments from both sides. I´ve been talking to Otavio and Lauren directly as well, and I decided to be the last one to say something. As community, we must think about ourselves, what are the guidelines that (hum) guides us. And I´ve been trying to factor the most important goals we would have. I don´t know if it´s right or complete, but I made my list: * stable branch is stable * we are part of Yocto Project We are part of Yocto Project. Freescale release/layer is not part of Yocto Project. meta-fsl-bsp-release does not need to follow the Yocto Project release schedule. We do. I remember this is not the first time we discuss how stable should we keep our next stable branch with the price of having the latest. And, I don´t think this is the last. One can say we must decide each release, case by case. However, I don´t want to spend my time again talking about this again next release. Again. For me, it´s clear that Freescale not being part of Yocto Project is what causes this mismatch of release dates, and until they realize we follow YP release timing, we will keep spending time in the same discussion. I really prefer chocolate cake, seriously. Otavio, I think everyone gave the 2 cents needed. We have already money for a coxinha here. With my 2 cents we can buy the refri and make a party. Can you, please, start a new clean thread for us to formalize the votes and count it precisely? (only votes, please, more arguments can be shared in this thread) I formalize my vote there. Please, let me know what you think. Daiane ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-19 20:00 ` Otavio Salvador 2014-08-19 20:13 ` Eric Bénard 2014-08-19 20:20 ` John Weber @ 2014-08-20 17:32 ` Sébastien Taylor 2 siblings, 0 replies; 28+ messages in thread From: Sébastien Taylor @ 2014-08-20 17:32 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale On Aug 19, 2014, at 2:00 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > Hello folks, > > On Tue, Aug 19, 2014 at 4:23 PM, Lauren Post <Lauren.Post@freescale.com> wrote: > ... >> - Soon 3.10.17 and 3.10.31 graphics will be independent from kernel and would be able to be mixed with each kernel meaning you could use 3.10.31 kernel with v4 graphics (3.10.17) > > This is a great step in the right direction. So this alleviate part of > the trouble we have across vendors. So is it going to be done for the > 3.10.31 GA? or still for the Beta? > > What about the VPU? Is 3.10.31 VPU packages compatible with 3.10.17? > To me this is the biggest push for 3.10.31. GPU driver/library updates are few and far between, and are badly needed. Keeping the two separate would make it easier to pull in GPU updates without having to do the full kernel updates. As a bonus, RELEASE NOTES for GPU driver/library updates would be greatly appreciated. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-18 15:32 ` i.MX 3.10.31-1.1.0_beta release - community feedback requested Lauren Post ` (2 preceding siblings ...) 2014-08-19 13:59 ` Otavio Salvador @ 2014-08-20 22:53 ` Alexander Holler 2014-08-20 23:04 ` Lauren Post 3 siblings, 1 reply; 28+ messages in thread From: Alexander Holler @ 2014-08-20 22:53 UTC (permalink / raw) To: Lauren Post, meta-freescale Am 18.08.2014 17:32, schrieb Lauren Post: Hello, I'm new to i.MX6 and don't use yocto, so pelase forgive me if I ask a maybe stupid question. > - Kernel upgrade to 3.10.31 3.10.y is already at 3.10.52. Is there any reason why the current stable version of the longterm 3.10.y branch isn't used as a base? Because I've run into a problem with 3.10.17 which was fixed with v3.10.22 (december last year) I've recently rebased those 1200+ patches myself on top of 3.10.52, without any problems (took me around 15 minutes to solve 3 conflicts, testing excluded). So merging the current stable version of 3.10.y, if prefered, should be equally easy. My understanding of the stable trees is that they are especially used to provide security fixes (besides bugfixes). So I don't really understand why about 20 minor releases of maybe import fixes are ignored. Regards, Alexander Holler ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-20 22:53 ` Alexander Holler @ 2014-08-20 23:04 ` Lauren Post 2014-08-20 23:29 ` Alexander Holler 0 siblings, 1 reply; 28+ messages in thread From: Lauren Post @ 2014-08-20 23:04 UTC (permalink / raw) To: Alexander Holler, meta-freescale Our policy is to be at LTSI kernel which is 3.10.31 http://ltsi.linuxfoundation.org/ -----Original Message----- From: Alexander Holler [mailto:holler@ahsoftware.de] Sent: Wednesday, August 20, 2014 5:54 PM To: Post Lauren-RAA013; meta-freescale@yoctoproject.org Subject: Re: [meta-freescale] i.MX 3.10.31-1.1.0_beta release - community feedback requested Am 18.08.2014 17:32, schrieb Lauren Post: Hello, I'm new to i.MX6 and don't use yocto, so pelase forgive me if I ask a maybe stupid question. > - Kernel upgrade to 3.10.31 3.10.y is already at 3.10.52. Is there any reason why the current stable version of the longterm 3.10.y branch isn't used as a base? Because I've run into a problem with 3.10.17 which was fixed with v3.10.22 (december last year) I've recently rebased those 1200+ patches myself on top of 3.10.52, without any problems (took me around 15 minutes to solve 3 conflicts, testing excluded). So merging the current stable version of 3.10.y, if prefered, should be equally easy. My understanding of the stable trees is that they are especially used to provide security fixes (besides bugfixes). So I don't really understand why about 20 minor releases of maybe import fixes are ignored. Regards, Alexander Holler ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-20 23:04 ` Lauren Post @ 2014-08-20 23:29 ` Alexander Holler 0 siblings, 0 replies; 28+ messages in thread From: Alexander Holler @ 2014-08-20 23:29 UTC (permalink / raw) To: Lauren Post, meta-freescale Am 21.08.2014 01:04, schrieb Lauren Post: > Our policy is to be at LTSI kernel which is 3.10.31 http://ltsi.linuxfoundation.org/ Oh, another longterm stable tree. Thanks for enlighten me. > > -----Original Message----- > From: Alexander Holler [mailto:holler@ahsoftware.de] > Sent: Wednesday, August 20, 2014 5:54 PM > To: Post Lauren-RAA013; meta-freescale@yoctoproject.org > Subject: Re: [meta-freescale] i.MX 3.10.31-1.1.0_beta release - community feedback requested > > Am 18.08.2014 17:32, schrieb Lauren Post: > > Hello, > > I'm new to i.MX6 and don't use yocto, so pelase forgive me if I ask a maybe stupid question. > >> - Kernel upgrade to 3.10.31 > > 3.10.y is already at 3.10.52. Is there any reason why the current stable version of the longterm 3.10.y branch isn't used as a base? > > Because I've run into a problem with 3.10.17 which was fixed with > v3.10.22 (december last year) I've recently rebased those 1200+ patches myself on top of 3.10.52, without any problems (took me around 15 minutes to solve 3 conflicts, testing excluded). So merging the current stable version of 3.10.y, if prefered, should be equally easy. > > My understanding of the stable trees is that they are especially used to provide security fixes (besides bugfixes). So I don't really understand why about 20 minor releases of maybe import fixes are ignored. > > Regards, > > Alexander Holler > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested @ 2014-08-20 18:12 xxiao8 2014-08-20 19:41 ` Otavio Salvador 0 siblings, 1 reply; 28+ messages in thread From: xxiao8 @ 2014-08-20 18:12 UTC (permalink / raw) To: meta-freescale I would have hoped Freescale stuck with 3.10.17 instead of 3.10.31 to make 3.10.17 solid in the first place, unless 3.10.31 brought in something that is a must-to-have I don't see the reason to make things unnecessarily complicated. Customer can always patch to whatever 3.10.x when they want to as those incremental patches are normally independent of Freescale's code changes. Not to mention nowadays it's 3.10.53 now. Backport 3.10.31-beta to 3.10.17 and make this a gold release kernel is the best option in my opinion. I again don't see the point to diverge at all. xxiao ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-20 18:12 xxiao8 @ 2014-08-20 19:41 ` Otavio Salvador 2014-08-20 23:11 ` xxiao8 0 siblings, 1 reply; 28+ messages in thread From: Otavio Salvador @ 2014-08-20 19:41 UTC (permalink / raw) To: xxiao8; +Cc: meta-freescale On Wed, Aug 20, 2014 at 3:12 PM, xxiao8 <xxiao8@fosiao.com> wrote: > I would have hoped Freescale stuck with 3.10.17 instead of 3.10.31 to make > 3.10.17 solid in the first place, unless 3.10.31 brought in something that > is a must-to-have I don't see the reason to make things unnecessarily > complicated. Customer can always patch to whatever 3.10.x when they want to > as those incremental patches are normally independent of Freescale's code > changes. Not to mention nowadays it's 3.10.53 now. > > Backport 3.10.31-beta to 3.10.17 and make this a gold release kernel is the > best option in my opinion. I again don't see the point to diverge at all. Please, if you want your vote to be considered do it in the another thread and inform your full name (as your name is not in from). -- 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] 28+ messages in thread
* Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested 2014-08-20 19:41 ` Otavio Salvador @ 2014-08-20 23:11 ` xxiao8 0 siblings, 0 replies; 28+ messages in thread From: xxiao8 @ 2014-08-20 23:11 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale Just switched from digest mode to single email mode and waiting for whoever does the next vote, then I will have the thread to vote on... xxiao On 08/20/2014 02:41 PM, Otavio Salvador wrote: > On Wed, Aug 20, 2014 at 3:12 PM, xxiao8 <xxiao8@fosiao.com> wrote: >> I would have hoped Freescale stuck with 3.10.17 instead of 3.10.31 to make >> 3.10.17 solid in the first place, unless 3.10.31 brought in something that >> is a must-to-have I don't see the reason to make things unnecessarily >> complicated. Customer can always patch to whatever 3.10.x when they want to >> as those incremental patches are normally independent of Freescale's code >> changes. Not to mention nowadays it's 3.10.53 now. >> >> Backport 3.10.31-beta to 3.10.17 and make this a gold release kernel is the >> best option in my opinion. I again don't see the point to diverge at all. > Please, if you want your vote to be considered do it in the another > thread and inform your full name (as your name is not in from). > ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2014-08-20 23:30 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <b82299f1e1374ceea2a54dc92a7edc83@DM2PR0301MB0701.namprd03.prod.outlook.com> [not found] ` <8f1e8166115a4a4381ded78a5536c001@BY2PR03MB379.namprd03.prod.outlook.com> 2014-08-18 15:32 ` i.MX 3.10.31-1.1.0_beta release - community feedback requested Lauren Post 2014-08-18 15:54 ` Alfonso Tamés 2014-08-18 17:28 ` Eric Nelson 2014-08-18 19:35 ` Carlos Rafael Giani 2014-08-18 21:14 ` John Weber 2014-08-19 0:34 ` Alfonso Tamés 2014-08-19 2:32 ` Sébastien Taylor 2014-08-19 6:56 ` Carlos Rafael Giani 2014-08-19 13:59 ` Otavio Salvador 2014-08-19 15:55 ` Eric Nelson 2014-08-19 16:01 ` Carlos Rafael Giani 2014-08-19 16:22 ` Eric Nelson 2014-08-19 17:21 ` Otavio Salvador 2014-08-19 18:25 ` Eric Nelson 2014-08-19 17:24 ` Otavio Salvador 2014-08-19 18:44 ` Eric Nelson 2014-08-19 19:23 ` Lauren Post 2014-08-19 20:00 ` Otavio Salvador 2014-08-19 20:13 ` Eric Bénard 2014-08-19 20:20 ` John Weber 2014-08-20 13:31 ` Daiane Angolini 2014-08-20 17:32 ` Sébastien Taylor 2014-08-20 22:53 ` Alexander Holler 2014-08-20 23:04 ` Lauren Post 2014-08-20 23:29 ` Alexander Holler 2014-08-20 18:12 xxiao8 2014-08-20 19:41 ` Otavio Salvador 2014-08-20 23:11 ` xxiao8
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.