Freescale Linux 3.10.31-1.1.0_alpha release is online

Freescale Linux 3.10.31-1.1.0_alpha release is online

[Lauren Post]

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

This is our release layer with readme describing how to download at
http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_alpha

This release includes

-          Upgrades the Vivante graphics to 5.0.11.

-          Upgrade to kernel version 3.10.31

-          Release also includes Freescale's Gstreamer 1.0 version.

-          New imx6sxsabresd i.MX 6 SoloX SABRE-SD board .

-          Upgrade to Wayland version 1.4

-          Upgrade to Direct FB version 1.7

-          Freescale Gstreamer 1.0 support

-          QT5 support for X11, FB and Wayland backends

-          New image recipes for building without QT and with QT that work on all backends.

Please note that graphics are alpha quality and should not replace the 3.10.17 GA graphics.  The kernel links to 3.10.31 alpha graphics so if you plan to use new kernel with 3.10.17 graphics you need to at least revert the 1fc33c819ab3bea79f0faf75e6daf9583ca9beec<http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.31_1.1.0_alpha&id=1fc33c819ab3bea79f0faf75e6daf9583ca9beec>.

We are aware of some regressions in this new graphics which is why we are only upstreaming this release into the master branch.

Let me know if you have any questions.

And for those looking for documentation, now that GA is out our 3.10.17 documentation is out on freescale.com.   We are currently working on revamping the documentation for 3.10.31.   What is on freescale.com does not include information on SoloX yet.

Lauren

Yocto Project i.MX Team Lead




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

Re: Freescale Linux 3.10.31-1.1.0_alpha release is online

[Christian Betz]

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

On Thu, May 29, 2014 at 3:25 PM, Lauren Post <Lauren.Post@freescale.com>
wrote:

> -          Upgrades the Vivante graphics to 5.0.11.
>
Can freescale offer any guidance on what changes 5.0.11 includes? I'm
having some trouble finding something like release notes for the GPU
related changes. I realize this might not be possible for any number of
reasons. So i will understand if the answer is "no"  (or some variation
thereof). this leads to my next question...


>  And for those looking for documentation, now that GA is out our 3.10.17
> documentation is out on freescale.com.   We are currently working on
> revamping the documentation for 3.10.31.   What is on freescale.com does
> not include information on SoloX yet.
>

If you are implying the 3.10.31 docs are on freescale.com, i cannot find
them. Would you mind providing a link? This is where i wanted to look for
info about the vivante 5.0.11 changes.

I was able to locate the 3.10.17 docs quite easily on freescale.com.

thank you,
christian

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

Re: Freescale Linux 3.10.31-1.1.0_alpha release is online

[Lauren Post]

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

> Can freescale offer any guidance on what changes 5.0.11 includes? I'm having some trouble finding something like release notes for the GPU > related changes. I realize this might not be possible for any number of reasons. So i will understand if the answer is "no"  (or some variation
>  thereof). this leads to my next question...

For graphics,  the biggest new feature is supporting GLES 3.0 but with backward compatibility for GLES 2.0.

>>If you are implying the 3.10.31 docs are on freescale.com<http://freescale.com>, i cannot find them. Would you mind providing a link? This is where i wanted to  >> look for info about the vivante 5.0.11 changes.

No my email stated only 3.10.17 docs are on freescale.com (not 3.10.31).  We do not upload documentation to freescale.com until we release GA.

Regards,
Lauren Post
Yocto Project i.MX Team Lead

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

Re: Freescale Linux 3.10.31-1.1.0_alpha release is online

[Xh Xiao]

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

On Thu, May 29, 2014 at 6:27 PM, Lauren Post <Lauren.Post@freescale.com>
wrote:

>    > Can freescale offer any guidance on what changes 5.0.11 includes?
> I'm having some trouble finding something like release notes for the GPU >
> related changes. I realize this might not be possible for any number of
> reasons. So i will understand if the answer is "no"  (or some variation
>
> >  thereof). this leads to my next question...
>
>
>
> For graphics,  the biggest new feature is supporting GLES 3.0 but with
> backward compatibility for GLES 2.0.
>
>
>
> >>If you are implying the 3.10.31 docs are on freescale.com, i cannot
> find them. Would you mind providing a link? This is where i wanted to  >> look
> for info about the vivante 5.0.11 changes.
>
>
>
> No my email stated only 3.10.17 docs are on freescale.com (not 3.10.31).
> We do not upload documentation to freescale.com until we release GA.
>
>
>
> Regards,
>
> Lauren Post
>
> Yocto Project i.MX Team Lead
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
> It's a pain to chase the minor version changes(i.e. from 3.10.17 to
3.10.31), why not just focus on 3.10.17 and let the customer to apply any
.17~.31 difference themselves? the same way as 3.0.35 did.

It's also a logistic headache for product development.

xxiao

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

Re: Freescale Linux 3.10.31-1.1.0_alpha release is online

[Otavio Salvador]

On Thu, May 29, 2014 at 9:15 PM, Xh Xiao <xxiao8@fosiao.com> wrote:
> It's a pain to chase the minor version changes(i.e. from 3.10.17 to
> 3.10.31), why not just focus on 3.10.17 and let the customer to apply any
> .17~.31 difference themselves? the same way as 3.0.35 did.
>
> It's also a logistic headache for product development.

The GIT tag is exactly for that. It is your option to stay in one
revision and never update.

The Linux kernel development, of stable releases, is very rigid about
the fixes that are merged. The 3.10 version is even a LTSI kernel
which includes Long Term support for bugfixes and it is very advisable
products to /update/ their kernels as bugfixes may even involve
security fixes which is something few embedded product pay attention
for and is critical in a time every product is connected to the
Internet (IoT).

The process of constant update, with stable releases, reduces
drastically the amount of debugging, fixing and development of
products.

You can use the Daisy (or an older) branch which will stick to GA
release and never update your product ... it is your call but don't
expect support for old versions, forever. It is costly, so impossible
to support same version without someone paying for it. You can see
what this behavior leaded Freescale in past with the LTIB tool (which
only works in Ubuntu 10.04, a dead one).

3.10.31-1.1.0 alpha release is NOT production ready and shouldn't be
used for products. The alpha and beta releases are for integrators and
technology vendors to start their work (test, report regressions,
integration in their specific platforms and like).
When 3.10.xx-1.1.0 GA goes out all this background work is complete
and you can use a solid BSP release, with fewer known issues.

All this development work is core for the upcoming technologies (as
newer Wayland, Qt and like) and build systems improvements to enhance
every product cycle and developers workflow. This is critical for us
to keep our pace in this innovation time.

So please don't push for the wrong direction.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Freescale Linux 3.10.31-1.1.0_alpha release is online

[Bob Cochran]

On 05/29/2014 03:25 PM, Lauren Post wrote:
> This is our release layer with readme describing how to download at
>
> http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_alpha
>

Hi Lauren,

For the repo manifest file (default.xml), can you use tag names (e.g., 
yocto-1.6) when possible instead of the SHA for your revision attribute 
inside of the project tag?  It would save some time of having to do a 
reverse lookup for each revision attribute (commit) and make the 
manifest more friendly.

And how would I figure out why you chose a particular commit that wasn't 
otherwise notable / tagged (e.g., you're not using the 1.6 tag in 
meta-fsl-arm)?

I looked through the commits in fsl-arm-yocto-bsp.git, but I didn't find 
anything to help me with this.

Lastly, I'm not able to clone fsl-arm-yocto-bsp.git.  When I run:

git clone git://git.freescale.com/imx/fsl-arm-yocto-bsp.git


I get "warning: remote HEAD refers to nonexistent ref, unable to 
checkout".  Is this a bug?  If so, where would I log it for this project?


Thank you,

Bob

Re: Freescale Linux 3.10.31-1.1.0_alpha release is online

[Lauren Post]

> For the repo manifest file (default.xml), can you use tag names (e.g.,
> yocto-1.6) when possible instead of the SHA for your revision attribute inside of the project tag?  It 
> would save some time of having to do a reverse lookup for each revision attribute (commit) and make the > manifest more friendly.
> And how would I figure out why you chose a particular commit that wasn't otherwise notable / tagged 
> (e.g., you're not using the 1.6 tag in meta-fsl-arm)?
> I looked through the commits in fsl-arm-yocto-bsp.git, but I didn't find anything to help me with this.

When we do code freeze for a release we lock our manifest to specific commit on all layers - many times it is a mid point on the branches past the release.  So unfortunately we can't use a tag or branch name in the manifest.  After we release we go back to the tip and use that for development so our beta release will have more fixes from community from daisy branch.  We always release based on latest official Yocto Project release so 3.10.31 is based off of daisy but will be upstreamed to be part of Yocto Project 1.7.

> Lastly, I'm not able to clone fsl-arm-yocto-bsp.git.  When I run:
> git clone git://git.freescale.com/imx/fsl-arm-yocto-bsp.git

The manifest is only meant for repo init - not for git cloning.  It is a just a basic repo so that we don't have to package our manifest in a release package as we did for earlier releases with i.MX with Yocto Project.

Lauren Post
Freescale i.MX Yocto Project team lead

Re: Freescale Linux 3.10.31-1.1.0_alpha release is online

[Bob Cochran]

On 05/30/2014 09:53 AM, Lauren Post wrote:
>
>> For the repo manifest file (default.xml), can you use tag names (e.g.,
>> yocto-1.6) when possible instead of the SHA for your revision attribute inside of the project tag?  It
>> would save some time of having to do a reverse lookup for each revision attribute (commit) and make the > manifest more friendly.
>> And how would I figure out why you chose a particular commit that wasn't otherwise notable / tagged
>> (e.g., you're not using the 1.6 tag in meta-fsl-arm)?
>> I looked through the commits in fsl-arm-yocto-bsp.git, but I didn't find anything to help me with this.
>
> When we do code freeze for a release we lock our manifest to specific commit on all layers - many times it is a mid point on the branches past the release.  So unfortunately we can't use a tag or branch name in the manifest.  After we release we go back to the tip and use that for development so our beta release will have more fixes from community from daisy branch.  We always release based on latest official Yocto Project release so 3.10.31 is based off of daisy but will be upstreamed to be part of Yocto Project 1.7.

Thanks for the reply Lauren.  I see that you point to the poky revision 
that is indeed at the yocto-1.6 tag, but the meta-fsl-arm revision is 
not at the 1.6 tag.  Other than combing through the mail lists, is there 
anything documented that would help me understand why you picked this 
particular commit for your release?  (the answer is probably obvious to 
those that aren't playing catch up like me).

>
>> Lastly, I'm not able to clone fsl-arm-yocto-bsp.git.  When I run:
>> git clone git://git.freescale.com/imx/fsl-arm-yocto-bsp.git
>
> The manifest is only meant for repo init - not for git cloning.

If you can, you might want to remove the git clone instructions at the 
bottom of the page: 
http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/?h=imx-3.10.31-1.1.0_alpha


It is a just a basic repo so that we don't have to package our manifest 
in a release package as we did for earlier releases with i.MX with Yocto 
Project.
>
> Lauren Post
> Freescale i.MX Yocto Project team lead
>
>

Re: Freescale Linux 3.10.31-1.1.0_alpha release is online

[Otavio Salvador]

On Fri, May 30, 2014 at 11:17 AM, Bob Cochran <yocto@mindchasers.com> wrote:
> On 05/30/2014 09:53 AM, Lauren Post wrote:
>>
>>
>>> For the repo manifest file (default.xml), can you use tag names (e.g.,
>>> yocto-1.6) when possible instead of the SHA for your revision attribute
>>> inside of the project tag?  It
>>> would save some time of having to do a reverse lookup for each revision
>>> attribute (commit) and make the > manifest more friendly.
>>> And how would I figure out why you chose a particular commit that wasn't
>>> otherwise notable / tagged
>>> (e.g., you're not using the 1.6 tag in meta-fsl-arm)?
>>> I looked through the commits in fsl-arm-yocto-bsp.git, but I didn't find
>>> anything to help me with this.
>>
>>
>> When we do code freeze for a release we lock our manifest to specific
>> commit on all layers - many times it is a mid point on the branches past the
>> release.  So unfortunately we can't use a tag or branch name in the
>> manifest.  After we release we go back to the tip and use that for
>> development so our beta release will have more fixes from community from
>> daisy branch.  We always release based on latest official Yocto Project
>> release so 3.10.31 is based off of daisy but will be upstreamed to be part
>> of Yocto Project 1.7.
>
>
> Thanks for the reply Lauren.  I see that you point to the poky revision that
> is indeed at the yocto-1.6 tag, but the meta-fsl-arm revision is not at the
> 1.6 tag.  Other than combing through the mail lists, is there anything
> documented that would help me understand why you picked this particular
> commit for your release?  (the answer is probably obvious to those that
> aren't playing catch up like me).

This is just the point their did the code freeze; there is no 'reason'
to choose one commit on top of another, just a matter of timing.

meta-fsl-arm was tagged after as we were with some ongoing work being
finished. So it was not in 'sync' with YP 1.6 tag.

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