Freescale Linux kernel 3.10.17_1.0.0_beta

Freescale Linux kernel 3.10.17_1.0.0_beta

[Diego]

Hi,

I've noticed a new 3.10 beta kernel popped up in Freescale's git:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.10.17_1.0.0_beta

Is it already in the works for Yocto?

Bests,
Diego

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Daiane.Angolini]

> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Diego
> Sent: Monday, December 30, 2013 6:37 AM
> To: meta-freescale@yoctoproject.org
> Subject: [meta-freescale] Freescale Linux kernel 3.10.17_1.0.0_beta
> 
> Hi,
> 
> I've noticed a new 3.10 beta kernel popped up in Freescale's git:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-
> imx.git/log/?h=imx_3.10.17_1.0.0_beta
> 
> Is it already in the works for Yocto?

I´m sorry, what do you mean?

We are working on the upgrade patchset, but the patches are not ready yet, do you want to participate in tests?

Daiane
> 
> Bests,
> Diego
> 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
> 

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[John Weber]

Testing this now.  Looks like it boots and talks to the network, USB, and serial 
ports on Wandboard Dual, but changes might be needed for U-boot to use a zImage 
by default, as well as changing the default fdt load address.  I had problems 
booting with the DTB using a uImage.

Also, do not use imx_v6_v7_defconfig.  Here, I believe that v6 and v7 refer to 
the ARM instruction set.  The new kernel seems to include some v7-specific 
instructions in some assembly code (specifically some lpddr2 code).  I'm using 
imx_v7_defconfig instead, which actually has more i.MX6-specific options 
included by default.

As an side question - is there an issue with defaulting to using zImage instead 
of uImage for Yocto/u-boot?

John

On 12/30/13 7:27 AM, Daiane.Angolini@freescale.com wrote:
>
>> -----Original Message-----
>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>> bounces@yoctoproject.org] On Behalf Of Diego
>> Sent: Monday, December 30, 2013 6:37 AM
>> To: meta-freescale@yoctoproject.org
>> Subject: [meta-freescale] Freescale Linux kernel 3.10.17_1.0.0_beta
>>
>> Hi,
>>
>> I've noticed a new 3.10 beta kernel popped up in Freescale's git:
>> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-
>> imx.git/log/?h=imx_3.10.17_1.0.0_beta
>>
>> Is it already in the works for Yocto?
> I´m sorry, what do you mean?
>
> We are working on the upgrade patchset, but the patches are not ready yet, do you want to participate in tests?
>
> Daiane
>> Bests,
>> Diego
>>
>> _______________________________________________
>> 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

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Fabio Estevam]

On Mon, Dec 30, 2013 at 2:46 PM, John Weber <rjohnweber@gmail.com> wrote:
> Testing this now.  Looks like it boots and talks to the network, USB, and
> serial ports on Wandboard Dual, but changes might be needed for U-boot to
> use a zImage by default, as well as changing the default fdt load address.
> I had problems booting with the DTB using a uImage.

Can you try with fdt_addr=0x18000000 ?

>
> Also, do not use imx_v6_v7_defconfig.  Here, I believe that v6 and v7 refer
> to the ARM instruction set.  The new kernel seems to include some
> v7-specific instructions in some assembly code (specifically some lpddr2
> code).  I'm using imx_v7_defconfig instead, which actually has more
> i.MX6-specific options included by default.
>
> As an side question - is there an issue with defaulting to using zImage
> instead of uImage for Yocto/u-boot?

No, I also think we should switch to zImage format. We only need to
update the script to call 'bootz' instead of 'bootm'.

Regards,

Fabio Estevam

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[John Weber]

Hi Fabio -

On 12/30/13 11:17 AM, Fabio Estevam wrote:
> On Mon, Dec 30, 2013 at 2:46 PM, John Weber <rjohnweber@gmail.com> wrote:
>> Testing this now.  Looks like it boots and talks to the network, USB, and
>> serial ports on Wandboard Dual, but changes might be needed for U-boot to
>> use a zImage by default, as well as changing the default fdt load address.
>> I had problems booting with the DTB using a uImage.
> Can you try with fdt_addr=0x18000000 ?
I had problems with uImage when the DTB is loaded at 0x18000000.  It would give 
me errors like the following (note this was yesterday using 3.10.9):

reading uImage
4565936 bytes read in 238 ms (18.3 MiB/s)
Booting from mmc ...
reading imx6dl-wandboard.dtb
34153 bytes read in 19 ms (1.7 MiB/s)
## Booting kernel from Legacy Image at 10008000 ...
    Image Name:   Linux-3.10.9+
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    4565872 Bytes = 4.4 MiB
    Load Address: 10008000
    Entry Point:  10008000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
    Booting using the fdt blob at 0x18000000
    XIP Kernel Image ... OK
    Using Device Tree in place at 18000000, end 1800b568

Starting kernel ...

undefined instruction
pc : [<10008028>]          lr : [<4ff7ffe8>]
sp : 4f57c8c8  ip : ffffffff     fp : 4ffb9bd4
r10: 4ffba2a4  r9 : 4f57cf38     r8 : 4f57e2fc
r7 : 00000000  r6 : 10008000     r5 : 4ffba2a4  r4 : 00002c8d
r3 : 00008569  r2 : 18000000     r1 : 0000113c  r0 : 18000000
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

Loading the zImage in the same place and using bootz worked.  I'm not sure if I 
have made a mistake somewhere else.

>
>> Also, do not use imx_v6_v7_defconfig.  Here, I believe that v6 and v7 refer
>> to the ARM instruction set.  The new kernel seems to include some
>> v7-specific instructions in some assembly code (specifically some lpddr2
>> code).  I'm using imx_v7_defconfig instead, which actually has more
>> i.MX6-specific options included by default.
>>
>> As an side question - is there an issue with defaulting to using zImage
>> instead of uImage for Yocto/u-boot?
> No, I also think we should switch to zImage format. We only need to
> update the script to call 'bootz' instead of 'bootm'.
OK, is this something that we should stage for v1.6?
>
> Regards,
>
> Fabio Estevam

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Fabio Estevam]

Hi John,

On Mon, Dec 30, 2013 at 3:34 PM, John Weber <rjohnweber@gmail.com> wrote:

>> No, I also think we should switch to zImage format. We only need to
>> update the script to call 'bootz' instead of 'bootm'.
>
> OK, is this something that we should stage for v1.6?

I think this would be nice.

If you have a chance, please send a patch that makes the conversion to
zImage usage.

Thanks,

Fabio Estevam

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Otavio Salvador]

On Mon, Dec 30, 2013 at 3:17 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Dec 30, 2013 at 2:46 PM, John Weber <rjohnweber@gmail.com> wrote:
>> As an side question - is there an issue with defaulting to using zImage
>> instead of uImage for Yocto/u-boot?
>
> No, I also think we should switch to zImage format. We only need to
> update the script to call 'bootz' instead of 'bootm'.

I think this is a great idea but I believe we ought to make this for
all boards so we have it uniform across the boards; otherwise we'll
have a mix and it makes the support harder.

Considering we'd target this for 1.6, what would be the conversion plan?

Who could be responsible for each board for converting/testing?

-- 
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 kernel 3.10.17_1.0.0_beta

[John Weber]

On 12/30/13 1:22 PM, Otavio Salvador wrote:
> On Mon, Dec 30, 2013 at 3:17 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Mon, Dec 30, 2013 at 2:46 PM, John Weber <rjohnweber@gmail.com> wrote:
>>> As an side question - is there an issue with defaulting to using zImage
>>> instead of uImage for Yocto/u-boot?
>> No, I also think we should switch to zImage format. We only need to
>> update the script to call 'bootz' instead of 'bootm'.
> I think this is a great idea but I believe we ought to make this for
> all boards so we have it uniform across the boards; otherwise we'll
> have a mix and it makes the support harder.
>
> Considering we'd target this for 1.6, what would be the conversion plan?
>
> Who could be responsible for each board for converting/testing?
>
Not sure, my thought was to leave it to the board maintainers. Unless I'm 
mistaken (which is a possibility), for some reason uImage does not work when 
booting with the 3.10.X kernels.  It that is the case then we either need to 
figure out the problem with uImages or others will be forced to use zImage anyway.

Here are the steps I've considered:
A) Send two patches to meta-freescale for meta-fsl-arm-extra to make the conversion:
    1) bbappend for u-boot to patch the include/configs/<board>.h file to use 
and boot from zImage
    2) Patch conf/machine/include/<board>.inc to set KERNEL_IMAGETYPE to zImage

B) Test the current stable kernels with these settings

c) Upstream the U-boot patch to u-boot-imx

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Fabio Estevam]

On Mon, Dec 30, 2013 at 5:37 PM, John Weber <rjohnweber@gmail.com> wrote:

>> I think this is a great idea but I believe we ought to make this for
>> all boards so we have it uniform across the boards; otherwise we'll
>> have a mix and it makes the support harder.

Yes, in mainline U-boot I plan to convert them all at once.

>>
>> Considering we'd target this for 1.6, what would be the conversion plan?
>>
>> Who could be responsible for each board for converting/testing?
>>
> Not sure, my thought was to leave it to the board maintainers. Unless I'm
> mistaken (which is a possibility), for some reason uImage does not work when
> booting with the 3.10.X kernels.  It that is the case then we either need to
> figure out the problem with uImages or others will be forced to use zImage
> anyway.

I managed to boot FSL imx_3.10.9_1.0.0_alpha with mainline U-boot.

Haven't tested imx_3.10.17_1.0.0_beta yet, but I can try it next week.

Even if we manage to get imx_3.10.17_1.0.0_beta booting fine with
uImage, I still think that booting the zImage makes sense, as it can
avoid user errors by passing incorrect LOADADDR.


> Here are the steps I've considered:
> A) Send two patches to meta-freescale for meta-fsl-arm-extra to make the
> conversion:
>    1) bbappend for u-boot to patch the include/configs/<board>.h file to use
> and boot from zImage
>    2) Patch conf/machine/include/<board>.inc to set KERNEL_IMAGETYPE to
> zImage
>
> B) Test the current stable kernels with these settings
>
> c) Upstream the U-boot patch to u-boot-imx

Looks like a good plan.

Regards,

Fabio Estevam

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Otavio Salvador]

On Mon, Dec 30, 2013 at 5:51 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Dec 30, 2013 at 5:37 PM, John Weber <rjohnweber@gmail.com> wrote:
>
>>> I think this is a great idea but I believe we ought to make this for
>>> all boards so we have it uniform across the boards; otherwise we'll
>>> have a mix and it makes the support harder.
>
> Yes, in mainline U-boot I plan to convert them all at once.

Please do one commit per board; so it is easier to revert (if needed).

>>> Considering we'd target this for 1.6, what would be the conversion plan?
>>>
>>> Who could be responsible for each board for converting/testing?
>>>
>> Not sure, my thought was to leave it to the board maintainers. Unless I'm
>> mistaken (which is a possibility), for some reason uImage does not work when
>> booting with the 3.10.X kernels.  It that is the case then we either need to
>> figure out the problem with uImages or others will be forced to use zImage
>> anyway.
>
> I managed to boot FSL imx_3.10.9_1.0.0_alpha with mainline U-boot.

Me too; All customer-kernels I've been doing (based on 3.10) been
using zImage and it works quite well. Did you test older kernels
(3.0.35 and 2.6.35, for example)?

> Haven't tested imx_3.10.17_1.0.0_beta yet, but I can try it next week.
>
> Even if we manage to get imx_3.10.17_1.0.0_beta booting fine with
> uImage, I still think that booting the zImage makes sense, as it can
> avoid user errors by passing incorrect LOADADDR.

I like this as a goal but this is not a simple change for the BSP; we
need to make it work for both supported kernels and test both. The
ideal would be to have all boards using zImage but we have a long way
for this...

Even if we convert all boards to zImage we need to keep support for
uImage as customers may be using it for their internal boards.

-- 
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 kernel 3.10.17_1.0.0_beta

[Fabio Estevam]

On Mon, Dec 30, 2013 at 6:17 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:


> Please do one commit per board; so it is easier to revert (if needed).

Yes, by "convert them all at once" I mean to send a series of patches
doing the conversion for several boards.

> Me too; All customer-kernels I've been doing (based on 3.10) been
> using zImage and it works quite well. Did you test older kernels
> (3.0.35 and 2.6.35, for example)?

Booting a zImage is something that is really kernel version independent.

>> Haven't tested imx_3.10.17_1.0.0_beta yet, but I can try it next week.
>>
>> Even if we manage to get imx_3.10.17_1.0.0_beta booting fine with
>> uImage, I still think that booting the zImage makes sense, as it can
>> avoid user errors by passing incorrect LOADADDR.
>
> I like this as a goal but this is not a simple change for the BSP; we
> need to make it work for both supported kernels and test both. The
> ideal would be to have all boards using zImage but we have a long way
> for this...
>
> Even if we convert all boards to zImage we need to keep support for
> uImage as customers may be using it for their internal boards.

Then this defeats the whole purpose of the zImage transition then.

Regards,

Fabio Estevam

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Otavio Salvador]

Hello Fabio,

On Mon, Dec 30, 2013 at 6:24 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Dec 30, 2013 at 6:17 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> Please do one commit per board; so it is easier to revert (if needed).
>
> Yes, by "convert them all at once" I mean to send a series of patches
> doing the conversion for several boards.

Good.

>> Me too; All customer-kernels I've been doing (based on 3.10) been
>> using zImage and it works quite well. Did you test older kernels
>> (3.0.35 and 2.6.35, for example)?
>
> Booting a zImage is something that is really kernel version independent.

Sure but this does not mean we can convert all without proper testing, right?

>>> Haven't tested imx_3.10.17_1.0.0_beta yet, but I can try it next week.
>>>
>>> Even if we manage to get imx_3.10.17_1.0.0_beta booting fine with
>>> uImage, I still think that booting the zImage makes sense, as it can
>>> avoid user errors by passing incorrect LOADADDR.
>>
>> I like this as a goal but this is not a simple change for the BSP; we
>> need to make it work for both supported kernels and test both. The
>> ideal would be to have all boards using zImage but we have a long way
>> for this...
>>
>> Even if we convert all boards to zImage we need to keep support for
>> uImage as customers may be using it for their internal boards.
>
> Then this defeats the whole purpose of the zImage transition then.

It does not; I think we must be a safe bed for our customers and we
cannot shove down their throats a change like that. We must support
this at least for one more release to keep some time for them to
convert and adapt.

-- 
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 kernel 3.10.17_1.0.0_beta

[John Weber]

Hi Otavio -

On 12/30/13 2:17 PM, Otavio Salvador wrote:
> On Mon, Dec 30, 2013 at 5:51 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> On Mon, Dec 30, 2013 at 5:37 PM, John Weber <rjohnweber@gmail.com> wrote:
>>
>>>> I think this is a great idea but I believe we ought to make this for
>>>> all boards so we have it uniform across the boards; otherwise we'll
>>>> have a mix and it makes the support harder.
>> Yes, in mainline U-boot I plan to convert them all at once.
> Please do one commit per board; so it is easier to revert (if needed).
>
>>>> Considering we'd target this for 1.6, what would be the conversion plan?
>>>>
>>>> Who could be responsible for each board for converting/testing?
>>>>
>>> Not sure, my thought was to leave it to the board maintainers. Unless I'm
>>> mistaken (which is a possibility), for some reason uImage does not work when
>>> booting with the 3.10.X kernels.  It that is the case then we either need to
>>> figure out the problem with uImages or others will be forced to use zImage
>>> anyway.
>> I managed to boot FSL imx_3.10.9_1.0.0_alpha with mainline U-boot.
> Me too; All customer-kernels I've been doing (based on 3.10) been
> using zImage and it works quite well. Did you test older kernels
> (3.0.35 and 2.6.35, for example)?
Right now, all my zImage attempts have been made using 3.10.17 beta, but I plan 
to go back and do 3.0.35.  I shall stay away from 2.6.35.  :-)
>> Haven't tested imx_3.10.17_1.0.0_beta yet, but I can try it next week.
>>
>> Even if we manage to get imx_3.10.17_1.0.0_beta booting fine with
>> uImage, I still think that booting the zImage makes sense, as it can
>> avoid user errors by passing incorrect LOADADDR.
> I like this as a goal but this is not a simple change for the BSP; we
> need to make it work for both supported kernels and test both. The
> ideal would be to have all boards using zImage but we have a long way
> for this...
It does seem like a rather large change.  For each board, the changes are fairly 
minimal (as long as it works), but when you figure in 30+ boards, and for custom 
boards, that is a whole different problem.  I'd like to know what other 
maintainers think here.
>
> Even if we convert all boards to zImage we need to keep support for
> uImage as customers may be using it for their internal boards.
>
Assuming that the default images filenames would be 'uImage' and 'zImage' one 
could do a hack-ish thing like test to see which file is present and then either 
bootz or bootm based on that.  I actually did half of this earlier today (minus 
the testing which file is present), by selecting bootz when image=zImage, and 
bootm when image=uImage.  While this would be nice to make it work by default 
with uImage or zImage, it is not very elegant and would need to repeated for 
each board config file, therefore it is a hack.  It would be much better for a 
simple 'bootany' command to test which type of image is loaded into memory and 
pick the appropriate one.

John

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Otavio Salvador]

John,

On Mon, Dec 30, 2013 at 6:32 PM, John Weber <rjohnweber@gmail.com> wrote:
> On 12/30/13 2:17 PM, Otavio Salvador wrote:
>>
>> On Mon, Dec 30, 2013 at 5:51 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>>
>>> On Mon, Dec 30, 2013 at 5:37 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>
>>>>> I think this is a great idea but I believe we ought to make this for
>>>>> all boards so we have it uniform across the boards; otherwise we'll
>>>>> have a mix and it makes the support harder.
>>>
>>> Yes, in mainline U-boot I plan to convert them all at once.
>>
>> Please do one commit per board; so it is easier to revert (if needed).
>>
>>>>> Considering we'd target this for 1.6, what would be the conversion
>>>>> plan?
>>>>>
>>>>> Who could be responsible for each board for converting/testing?
>>>>>
>>>> Not sure, my thought was to leave it to the board maintainers. Unless
>>>> I'm
>>>> mistaken (which is a possibility), for some reason uImage does not work
>>>> when
>>>> booting with the 3.10.X kernels.  It that is the case then we either
>>>> need to
>>>> figure out the problem with uImages or others will be forced to use
>>>> zImage
>>>> anyway.
>>>
>>> I managed to boot FSL imx_3.10.9_1.0.0_alpha with mainline U-boot.
>>
>> Me too; All customer-kernels I've been doing (based on 3.10) been
>> using zImage and it works quite well. Did you test older kernels
>> (3.0.35 and 2.6.35, for example)?
>
> Right now, all my zImage attempts have been made using 3.10.17 beta, but I
> plan to go back and do 3.0.35.  I shall stay away from 2.6.35.  :-)

Good; this would be 'good enough' for us to consider the migration of
Wandboard for zImage.

>>> Haven't tested imx_3.10.17_1.0.0_beta yet, but I can try it next week.
>>>
>>> Even if we manage to get imx_3.10.17_1.0.0_beta booting fine with
>>> uImage, I still think that booting the zImage makes sense, as it can
>>> avoid user errors by passing incorrect LOADADDR.
>>
>> I like this as a goal but this is not a simple change for the BSP; we
>> need to make it work for both supported kernels and test both. The
>> ideal would be to have all boards using zImage but we have a long way
>> for this...
>
> It does seem like a rather large change.  For each board, the changes are
> fairly minimal (as long as it works), but when you figure in 30+ boards, and
> for custom boards, that is a whole different problem.  I'd like to know what
> other maintainers think here.

Yes; I fully agree. We cannot underestimate this change as it has a
high impact the BSP.

>> Even if we convert all boards to zImage we need to keep support for
>> uImage as customers may be using it for their internal boards.
>>
> Assuming that the default images filenames would be 'uImage' and 'zImage'
> one could do a hack-ish thing like test to see which file is present and
> then either bootz or bootm based on that.  I actually did half of this
> earlier today (minus the testing which file is present), by selecting bootz
> when image=zImage, and bootm when image=uImage.  While this would be nice to
> make it work by default with uImage or zImage, it is not very elegant and
> would need to repeated for each board config file, therefore it is a hack.
> It would be much better for a simple 'bootany' command to test which type of
> image is loaded into memory and pick the appropriate one.

Yes; this was the ugly hack I was talking about ;-)

-- 
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 kernel 3.10.17_1.0.0_beta

[Otavio Salvador]

Hello John,

On Mon, Dec 30, 2013 at 5:37 PM, John Weber <rjohnweber@gmail.com> wrote:
> On 12/30/13 1:22 PM, Otavio Salvador wrote:
>> On Mon, Dec 30, 2013 at 3:17 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>>
>>> On Mon, Dec 30, 2013 at 2:46 PM, John Weber <rjohnweber@gmail.com> wrote:
>>>>
>>>> As an side question - is there an issue with defaulting to using zImage
>>>> instead of uImage for Yocto/u-boot?
>>>
>>> No, I also think we should switch to zImage format. We only need to
>>> update the script to call 'bootz' instead of 'bootm'.
>>
>> I think this is a great idea but I believe we ought to make this for
>> all boards so we have it uniform across the boards; otherwise we'll
>> have a mix and it makes the support harder.
>>
>> Considering we'd target this for 1.6, what would be the conversion plan?
>>
>> Who could be responsible for each board for converting/testing?
>>
> Not sure, my thought was to leave it to the board maintainers. Unless I'm
> mistaken (which is a possibility), for some reason uImage does not work when
> booting with the 3.10.X kernels.  It that is the case then we either need to
> figure out the problem with uImages or others will be forced to use zImage
> anyway.

As I said earlier, I am fine with moving to zImage but we need to keep
3.0.35 and 3.10 working.

Another thing we need to consider is if we can migrate other SoCs too
(does 2.6.35 works with zImage?).

> Here are the steps I've considered:
> A) Send two patches to meta-freescale for meta-fsl-arm-extra to make the
> conversion:
>    1) bbappend for u-boot to patch the include/configs/<board>.h file to use
> and boot from zImage

This may be done in our U-Boot fork, as we keep it backporting
mainline patches. BUT this means both 3.0.35 and 3.10 need to use
zImage as we cannot do conditional environment depending on the kernel
version without very ugly hacks.

>    2) Patch conf/machine/include/<board>.inc to set KERNEL_IMAGETYPE to
> zImage

Yes, but read above.

> B) Test the current stable kernels with these settings
>
> c) Upstream the U-boot patch to u-boot-imx

Good.

-- 
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 kernel 3.10.17_1.0.0_beta

[Mats Kärrman]

Hi,

I'm also pressed to start using the new kernel (on i.MX6 / Sabre to begin with).
Are you sharing your work so far somewhere?

BR // Mats

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Eric Nelson]

Hi Mats,

On 01/08/2014 05:04 AM, Mats Kärrman wrote:
> Hi,
>
> I'm also pressed to start using the new kernel (on i.MX6 / Sabre to begin with).
> Are you sharing your work so far somewhere?
>

For those interested in early testing on SABRE Lite or Nitrogen6x,
we've pushed a branch to our Github repository:

	https://github.com/boundarydevices/linux-imx6/tree/boundary-imx_3.10.17_1.0.0_beta

Regards,


Eric

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Gary Thomas]

On 2014-01-08 06:57, Eric Nelson wrote:
> Hi Mats,
>
> On 01/08/2014 05:04 AM, Mats Kärrman wrote:
>> Hi,
>>
>> I'm also pressed to start using the new kernel (on i.MX6 / Sabre to begin with).
>> Are you sharing your work so far somewhere?
>>
>
> For those interested in early testing on SABRE Lite or Nitrogen6x,
> we've pushed a branch to our Github repository:
>
>      https://github.com/boundarydevices/linux-imx6/tree/boundary-imx_3.10.17_1.0.0_beta

Any guidance on how to boot this?  (device trees on ARM/U-Boot still baffle me)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Eric Nelson]

On 01/08/2014 07:02 AM, Gary Thomas wrote:
> On 2014-01-08 06:57, Eric Nelson wrote:
>> Hi Mats,
>>
>> On 01/08/2014 05:04 AM, Mats Kärrman wrote:
>>> Hi,
>>>
>>> I'm also pressed to start using the new kernel (on i.MX6 / Sabre to
>>> begin with).
>>> Are you sharing your work so far somewhere?
>>>
>>
>> For those interested in early testing on SABRE Lite or Nitrogen6x,
>> we've pushed a branch to our Github repository:
>>
>>
>> https://github.com/boundarydevices/linux-imx6/tree/boundary-imx_3.10.17_1.0.0_beta
>>

Hi Gary,

Bear with us. We're doing some more testing and finding some issues.

We'll post patches to the ML when things are in a more workable state
(in coming days).

Regards,


Eric

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Lauren Post]

We are in field trial right now almost complete for 3.10.17-1.0.0_beta but it is live with the manifest on the meta-fsl-bsp-release layer for those interested in trying it out.   I'll add user's guide once I have final version after field trial is complete.

As for work on master, I'm upstreaming the patches now and waiting on reviews from Otavio before it gets pushed into master-next.  

If you want to use our release in field trial start with the meta-fsl-bsp-release layer which was tested on top of the dora branches.  GA will be coming very quickly for 3.10.17-1.0.0.

Our meta-fsl-bsp-release has updates to components I have to upstream into poky and meta-oe so not all of it will be part of meta-fsl-arm.

Note this has a new graphics version that is not compatible with 3.0.35 kernel without kernel updates for 3.0.35 (Otavio has the patches).     The new graphics version allows us to support webGL in chromium.  We also provide support for the manufacturing tool in this release.

Lauren Post
Yocto i.MX Team Lead

-----Original Message-----
From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of Mats Kärrman
Sent: Wednesday, January 08, 2014 6:05 AM
To: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Freescale Linux kernel 3.10.17_1.0.0_beta

Hi,

I'm also pressed to start using the new kernel (on i.MX6 / Sabre to begin with).
Are you sharing your work so far somewhere?

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

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Mats Kärrman]

Thank you, I'm looking at it now!

BR // Mats

> From: Lauren Post [Lauren.Post@freescale.com]
> Sent: Wednesday, January 08, 2014 8:37 PM
> To: Mats Kärrman; meta-freescale@yoctoproject.org
> Subject: RE: [meta-freescale] Freescale Linux kernel 3.10.17_1.0.0_beta
> 
> We are in field trial right now almost complete for 3.10.17-1.0.0_beta but it is live with the manifest on the meta-fsl-bsp-release layer for those interested in trying it out.   I'll add user's guide once I have final version after field trial is complete.
> 
> As for work on master, I'm upstreaming the patches now and waiting on reviews from Otavio before it gets pushed into master-next.
> 
> If you want to use our release in field trial start with the meta-fsl-bsp-release layer which was tested on top of the dora branches.  GA will be coming very quickly for 3.10.17-1.0.0.
> 
> Our meta-fsl-bsp-release has updates to components I have to upstream into poky and meta-oe so not all of it will be part of meta-fsl-arm.
> 
> Note this has a new graphics version that is not compatible with 3.0.35 kernel without kernel updates for 3.0.35 (Otavio has the patches).     The new graphics version allows us to support webGL in chromium.  We also provide support for the manufacturing tool in this release.
> 
> Lauren Post
> Yocto i.MX Team Lead

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Diego]

In data lunedì 30 dicembre 2013 13:27:36, Daiane.Angolini@freescale.com ha 
scritto:
> > -----Original Message-----
> > From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> > bounces@yoctoproject.org] On Behalf Of Diego
> > Sent: Monday, December 30, 2013 6:37 AM
> > To: meta-freescale@yoctoproject.org
> > Subject: [meta-freescale] Freescale Linux kernel 3.10.17_1.0.0_beta
> > 
> > Hi,
> > 
> > I've noticed a new 3.10 beta kernel popped up in Freescale's git:
> > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-> > imx.git/log/?h=imx_3.10.17_1.0.0_beta
> > 
> > Is it already in the works for Yocto?
> 
> I´m sorry, what do you mean?
> 
> We are working on the upgrade patchset, but the patches are not ready yet,
> do you want to participate in tests?
> 

Yeah, I was referring to the patchset. I'd be glad to participate to the 
tests, but I think I need to wait for Nitrogen6x boards adaptations. 

Diego

Re: Freescale Linux kernel 3.10.17_1.0.0_beta

[Eric Nelson]

Hi Diego,

On 12/31/2013 10:20 AM, Diego wrote:
> In data lunedì 30 dicembre 2013 13:27:36, Daiane.Angolini@freescale.com ha
> scritto:
>>> -----Original Message-----
>>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>>> bounces@yoctoproject.org] On Behalf Of Diego
>>> Sent: Monday, December 30, 2013 6:37 AM
>>> To: meta-freescale@yoctoproject.org
>>> Subject: [meta-freescale] Freescale Linux kernel 3.10.17_1.0.0_beta
>>>
>>> Hi,
>>>
>>> I've noticed a new 3.10 beta kernel popped up in Freescale's git:
>>> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-> > imx.git/log/?h=imx_3.10.17_1.0.0_beta
>>>
>>> Is it already in the works for Yocto?
>>
>> I´m sorry, what do you mean?
>>
>> We are working on the upgrade patchset, but the patches are not ready yet,
>> do you want to participate in tests?
>>
>
> Yeah, I was referring to the patchset. I'd be glad to participate to the
> tests, but I think I need to wait for Nitrogen6x boards adaptations.
>

Coming soon.

With the holidays, I just noticed the 3.10.17_1.0.0_beta kernel in
yesterday's thread.

Regards,


Eric