Code for v2.6.39 merge window frozen, patches archived

Code for v2.6.39 merge window frozen, patches archived

[Tony Lindgren]

Hi all,

I've applied few random fix like patches today into omap-for-linus
but that's it for this merge window.

So let's do some testing with with Stephen's for-next and
omap-for-linus and start queueing up fixes for the -rc cycle.

I've also moved all the patchwork.kernel.org patches into
archived-v2.6.39 bundle and marked them as archived:

https://patchwork.kernel.org/user/bundle/1381/

You can still find the patches there if you click on Filters
and changed Archived from No to Both.

Looks like there's one smartreflex patch that does not seem
to exist in patchwork though.. So that one is still lurking
around on the patchwork list of patches until the issue has
been fixed in patchwork.kernel.org.

Cheers,

Tony

Re: Code for v2.6.39 merge window frozen, patches archived

[Nishanth Menon]

Tony Lindgren wrote, on 03/15/2011 12:55 AM:
[..]
> Looks like there's one smartreflex patch that does not seem
> to exist in patchwork though.. So that one is still lurking
> around on the patchwork list of patches until the issue has
> been fixed in patchwork.kernel.org.
Guess it is too late, but am curious:
http://marc.info/?l=linux-omap&m=129933897910785&w=2
Why has it been dropped from .39(aka archived out)? I dont see any 
review comments to the contrary from any maintainers explaining why we 
should'nt take it.

-- 
Regards,
Nishanth Menon

Re: Code for v2.6.39 merge window frozen, patches archived

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Tony Lindgren wrote, on 03/15/2011 12:55 AM:
> [..]
>> Looks like there's one smartreflex patch that does not seem
>> to exist in patchwork though.. So that one is still lurking
>> around on the patchwork list of patches until the issue has
>> been fixed in patchwork.kernel.org.
> Guess it is too late, but am curious:
> http://marc.info/?l=linux-omap&m=129933897910785&w=2
> Why has it been dropped from .39(aka archived out)? I dont see any
> review comments to the contrary from any maintainers explaining why we
> should'nt take it.

It didn't make this merge window because I did not get to do a final
review in time.  It has been a very busy development cycle, and I ran
out of time.

Kevin

Re: Code for v2.6.39 merge window frozen, patches archived

[Menon, Nishanth]

On Tue, Mar 15, 2011 at 20:39, Kevin Hilman <khilman@ti.com> wrote:
> Nishanth Menon <nm@ti.com> writes:
>
>> Tony Lindgren wrote, on 03/15/2011 12:55 AM:
>> [..]
>>> Looks like there's one smartreflex patch that does not seem
>>> to exist in patchwork though.. So that one is still lurking
>>> around on the patchwork list of patches until the issue has
>>> been fixed in patchwork.kernel.org.
>> Guess it is too late, but am curious:
>> http://marc.info/?l=linux-omap&m=129933897910785&w=2
>> Why has it been dropped from .39(aka archived out)? I dont see any
>> review comments to the contrary from any maintainers explaining why we
>> should'nt take it.
>
> It didn't make this merge window because I did not get to do a final
> review in time.  It has been a very busy development cycle, and I ran
> out of time.

Am guessing i will have to repost again since the old series have been
archived out on patchworks. and I suppose the same goes for all as
well.

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Code for v2.6.39 merge window frozen, patches archived

[Aaro Koskinen]

Hi,

On Mon, 14 Mar 2011, Tony Lindgren wrote:
> I've applied few random fix like patches today into omap-for-linus
> but that's it for this merge window.
>
> So let's do some testing with with Stephen's for-next and
> omap-for-linus and start queueing up fixes for the -rc cycle.

I did some quick testing:

linux-omap/master, omap2plus_defconfig:

 	- RM-680 hangs after uncompressing kernel. earlyprintk shows:

 	[    0.293395] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_core
 	[    0.300903] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per
 	[    0.308288] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup
 	[    0.316101] omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.

 	(then some garbage)

 	- With RX-51 I get the same messages, but no hang.

omap-for-linux, omap2plus_defconfig:

 	- Pretty much the same. RM-680 hangs and the first bad commit is
 	ce722d269ff85ab11aa680784bcc6eff06e3e3ea and earlyprintk shows
 	"external abort on non-linefetch" in omap_hwmod_read() after
 	above messages.

Mainline kernel (v2.6.38) boots fine.

A.

Re: Code for v2.6.39 merge window frozen, patches archived

[Cousson, Benoit]

Hi Aaro,

On 3/15/2011 6:54 PM, Aaro Koskinen wrote:
> Hi,
>
> On Mon, 14 Mar 2011, Tony Lindgren wrote:
>> I've applied few random fix like patches today into omap-for-linus
>> but that's it for this merge window.
>>
>> So let's do some testing with with Stephen's for-next and
>> omap-for-linus and start queueing up fixes for the -rc cycle.
>
> I did some quick testing:
>
> linux-omap/master, omap2plus_defconfig:
>
>   	- RM-680 hangs after uncompressing kernel. earlyprintk shows:
>
>   	[    0.293395] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_core
>   	[    0.300903] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per
>   	[    0.308288] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup
>   	[    0.316101] omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
>
>   	(then some garbage)
>
>   	- With RX-51 I get the same messages, but no hang.

Mmm, that looks like an access to a secure timer from hwmod code on a HS 
device. Could you comment out the timer12 entry 
(&omap3xxx_timer12_hwmod) in the omap3 hwmod list at the end of 
omap_hwmod_3xxx_data.c to check that?

Thanks
Benoit

>
> omap-for-linux, omap2plus_defconfig:
>
>   	- Pretty much the same. RM-680 hangs and the first bad commit is
>   	ce722d269ff85ab11aa680784bcc6eff06e3e3ea and earlyprintk shows
>   	"external abort on non-linefetch" in omap_hwmod_read() after
>   	above messages.
>
> Mainline kernel (v2.6.38) boots fine.
>
> A.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Code for v2.6.39 merge window frozen, patches archived

[aaro.koskinen]

Hi,

From: Cousson, Benoit [b-cousson@ti.com]:
>On 3/15/2011 6:54 PM, Aaro Koskinen wrote:
>> On Mon, 14 Mar 2011, Tony Lindgren wrote:
>>> I've applied few random fix like patches today into omap-for-linus
>>> but that's it for this merge window.
>>>
>>> So let's do some testing with with Stephen's for-next and
>>> omap-for-linus and start queueing up fixes for the -rc cycle.
>>
>> I did some quick testing:
>>
>> linux-omap/master, omap2plus_defconfig:
>>
>>       - RM-680 hangs after uncompressing kernel. earlyprintk shows:
>>
>>       [    0.293395] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_core
>>       [    0.300903] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per
>>       [    0.308288] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup
>>       [    0.316101] omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
>>
>>       (then some garbage)
>>
>>       - With RX-51 I get the same messages, but no hang.
>
> Mmm, that looks like an access to a secure timer from hwmod code on a HS
> device. Could you comment out the timer12 entry
> (&omap3xxx_timer12_hwmod) in the omap3 hwmod list at the end of
> omap_hwmod_3xxx_data.c to check that?

Yes, it's a HS device. I actually tried that already, with a debug print in _enable
and it was timer 12. When commented out, it got a bit further, but there was another
hang again in hwmod code, this time I think it was i2c3. I have to check that again
properly when I get back to the lab.

A.

Re: Code for v2.6.39 merge window frozen, patches archived

[Aaro Koskinen]

Hi,

On Tue, 15 Mar 2011, Cousson, Benoit wrote:
> Mmm, that looks like an access to a secure timer from hwmod code on a HS 
> device. Could you comment out the timer12 entry (&omap3xxx_timer12_hwmod) in 
> the omap3 hwmod list at the end of omap_hwmod_3xxx_data.c to check that?

With timer12 entry commented out and omap_hwmod debugs enabled, it now
hangs here:

[...]

[    4.306549] OMAP GPIO hardware version 2.5
[    4.310913] omap_hwmod: gpio4: enabling
[    4.314971] omap_hwmod: gpio4: enabling clocks
[    4.320037] OMAP GPIO hardware version 2.5
[    4.324401] omap_hwmod: gpio5: enabling
[    4.328460] omap_hwmod: gpio5: enabling clocks
[    4.333526] OMAP GPIO hardware version 2.5
[    4.337921] omap_hwmod: gpio6: enabling
[    4.341949] omap_hwmod: gpio6: enabling clocks
[    4.347015] OMAP GPIO hardware version 2.5

then nothing. Also, with RX-51 the boot breaks (or at least the serial
console) when earlyprintk is enabled. The last thing seen is:

[    0.996124] omap_hwmod: mmc1: enabling
[    1.000122] omap_hwmod: mmc1: enabling clocks
[    1.004760] omap_hwmod: mmc1: resetting
[    1.008850] omap_hwmod: mmc1: resetting via OCP SOFTRESET
[    1.014526] omap_hwmod: mmc1: softreset in 0 usec
[    1.019500] omap_hwmod: mmc1: idling
[    1.023315] omap_hwmod: mmc1: disabling clocks

I can see that mmc is followed by uart enable, so it seems that won't
work well with earlyprintk enabled.

A.

Re: Code for v2.6.39 merge window frozen, patches archived

[G, Manjunath Kondaiah]

On Mon, Mar 14, 2011 at 12:25:38PM -0700, Tony Lindgren wrote:
> Hi all,
> 
> I've applied few random fix like patches today into omap-for-linus
> but that's it for this merge window.
> 
> So let's do some testing with with Stephen's for-next and
> omap-for-linus and start queueing up fixes for the -rc cycle.
omap-for-linus boots on:
OMAP3430-Zoom2
OMAP3630-Zoom3
OMAP4430-Blaze

With OMAP3 and OMAP4 disabled, it boots successfully on:
OMAP2420-H4
OMAP2430-SDP

-Manjunath

> 
> I've also moved all the patchwork.kernel.org patches into
> archived-v2.6.39 bundle and marked them as archived:
> 
> https://patchwork.kernel.org/user/bundle/1381/
> 
> You can still find the patches there if you click on Filters
> and changed Archived from No to Both.
> 
> Looks like there's one smartreflex patch that does not seem
> to exist in patchwork though.. So that one is still lurking
> around on the patchwork list of patches until the issue has
> been fixed in patchwork.kernel.org.
> 
> Cheers,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Code for v2.6.39 merge window frozen, patches archived

[G, Manjunath Kondaiah]

On Wed, Mar 16, 2011 at 07:37:10PM +0530, G, Manjunath Kondaiah wrote:
> On Mon, Mar 14, 2011 at 12:25:38PM -0700, Tony Lindgren wrote:
> > Hi all,
> > 
> > I've applied few random fix like patches today into omap-for-linus
> > but that's it for this merge window.
> > 
> > So let's do some testing with with Stephen's for-next and
> > omap-for-linus and start queueing up fixes for the -rc cycle.
> omap-for-linus boots on:
> OMAP3430-Zoom2
> OMAP3630-Zoom3
> OMAP4430-Blaze
> 
> With OMAP3 and OMAP4 disabled, it boots successfully on:
> OMAP2420-H4
> OMAP2430-SDP

Also boots on OMAP1710-H3

-Manjunath

> 
> -Manjunath
> 
> > 
> > I've also moved all the patchwork.kernel.org patches into
> > archived-v2.6.39 bundle and marked them as archived:
> > 
> > https://patchwork.kernel.org/user/bundle/1381/
> > 
> > You can still find the patches there if you click on Filters
> > and changed Archived from No to Both.
> > 
> > Looks like there's one smartreflex patch that does not seem
> > to exist in patchwork though.. So that one is still lurking
> > around on the patchwork list of patches until the issue has
> > been fixed in patchwork.kernel.org.
> > 
> > Cheers,
> > 
> > Tony
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Code for v2.6.39 merge window frozen, patches archived

[Cousson, Benoit]

Hi Aaro,

On 3/16/2011 2:49 PM, Aaro Koskinen wrote:
> Hi,
>
> On Tue, 15 Mar 2011, Cousson, Benoit wrote:
>> Mmm, that looks like an access to a secure timer from hwmod code on a HS
>> device. Could you comment out the timer12 entry (&omap3xxx_timer12_hwmod) in
>> the omap3 hwmod list at the end of omap_hwmod_3xxx_data.c to check that?
>
> With timer12 entry commented out and omap_hwmod debugs enabled, it now
> hangs here:

Do you need that timer BTW?

>
> [...]
>
> [    4.306549] OMAP GPIO hardware version 2.5
> [    4.310913] omap_hwmod: gpio4: enabling
> [    4.314971] omap_hwmod: gpio4: enabling clocks
> [    4.320037] OMAP GPIO hardware version 2.5
> [    4.324401] omap_hwmod: gpio5: enabling
> [    4.328460] omap_hwmod: gpio5: enabling clocks
> [    4.333526] OMAP GPIO hardware version 2.5
> [    4.337921] omap_hwmod: gpio6: enabling
> [    4.341949] omap_hwmod: gpio6: enabling clocks
> [    4.347015] OMAP GPIO hardware version 2.5

GPIO are now initialized during postcore_initcall, so it is hard to know 
what will happen after that:-(

Could you try with initcall_debug in your command line?

Regards,
Benoit

Re: Code for v2.6.39 merge window frozen, patches archived

[Kishore Kadiyala]

On Wed, Mar 16, 2011 at 7:50 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
> On Wed, Mar 16, 2011 at 07:37:10PM +0530, G, Manjunath Kondaiah wrote:
>> On Mon, Mar 14, 2011 at 12:25:38PM -0700, Tony Lindgren wrote:
>> > Hi all,
>> >
>> > I've applied few random fix like patches today into omap-for-linus
>> > but that's it for this merge window.
>> >
>> > So let's do some testing with with Stephen's for-next and
>> > omap-for-linus and start queueing up fixes for the -rc cycle.
>> omap-for-linus boots on:
>> OMAP3430-Zoom2
>> OMAP3630-Zoom3
>> OMAP4430-Blaze
>>
>> With OMAP3 and OMAP4 disabled, it boots successfully on:
>> OMAP2420-H4
>> OMAP2430-SDP
>
> Also boots on OMAP1710-H3

boots fine on OMAP4430SDP as well

Regards,
Kishore

>
> -Manjunath
>
>>
>> -Manjunath
>>
>> >
>> > I've also moved all the patchwork.kernel.org patches into
>> > archived-v2.6.39 bundle and marked them as archived:
>> >
>> > https://patchwork.kernel.org/user/bundle/1381/
>> >
>> > You can still find the patches there if you click on Filters
>> > and changed Archived from No to Both.
>> >
>> > Looks like there's one smartreflex patch that does not seem
>> > to exist in patchwork though.. So that one is still lurking
>> > around on the patchwork list of patches until the issue has
>> > been fixed in patchwork.kernel.org.
>> >
>> > Cheers,
>> >
>> > Tony
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Code for v2.6.39 merge window frozen, patches archived

[Tony Lindgren]

* Cousson, Benoit <b-cousson@ti.com> [110316 07:31]:
> Hi Aaro,
> 
> On 3/16/2011 2:49 PM, Aaro Koskinen wrote:
> >Hi,
> >
> >On Tue, 15 Mar 2011, Cousson, Benoit wrote:
> >>Mmm, that looks like an access to a secure timer from hwmod code on a HS
> >>device. Could you comment out the timer12 entry (&omap3xxx_timer12_hwmod) in
> >>the omap3 hwmod list at the end of omap_hwmod_3xxx_data.c to check that?
> >
> >With timer12 entry commented out and omap_hwmod debugs enabled, it now
> >hangs here:
> 
> Do you need that timer BTW?
> 
> >
> >[...]
> >
> >[    4.306549] OMAP GPIO hardware version 2.5
> >[    4.310913] omap_hwmod: gpio4: enabling
> >[    4.314971] omap_hwmod: gpio4: enabling clocks
> >[    4.320037] OMAP GPIO hardware version 2.5
> >[    4.324401] omap_hwmod: gpio5: enabling
> >[    4.328460] omap_hwmod: gpio5: enabling clocks
> >[    4.333526] OMAP GPIO hardware version 2.5
> >[    4.337921] omap_hwmod: gpio6: enabling
> >[    4.341949] omap_hwmod: gpio6: enabling clocks
> >[    4.347015] OMAP GPIO hardware version 2.5
> 
> GPIO are now initialized during postcore_initcall, so it is hard to
> know what will happen after that:-(
> 
> Could you try with initcall_debug in your command line?

FYI, my rx51 boots fine with omap2plus defconfig, also with
earlyprintk. Sounds like it's some HS omap issue on both
your boards.

I think you have ttyO in your CONFIG_CMDLINE if you're
using omap2plus_defconfig. Then for rm680 you'll probably
need also:

CONFIG_CMDLINE_FORCE=y

Regards,

Tony

Re: Code for v2.6.39 merge window frozen, patches archived

[Aaro Koskinen]

Hi,

On Wed, 16 Mar 2011, Cousson, Benoit wrote:
> On 3/16/2011 2:49 PM, Aaro Koskinen wrote:
>> On Tue, 15 Mar 2011, Cousson, Benoit wrote:
>>> Mmm, that looks like an access to a secure timer from hwmod code on a HS
>>> device. Could you comment out the timer12 entry (&omap3xxx_timer12_hwmod) 
>>> in
>>> the omap3 hwmod list at the end of omap_hwmod_3xxx_data.c to check that?
>> 
>> With timer12 entry commented out and omap_hwmod debugs enabled, it now
>> hangs here:
>
> Do you need that timer BTW?

Probably no at the moment. :-)

>> [    4.347015] OMAP GPIO hardware version 2.5
>
> GPIO are now initialized during postcore_initcall, so it is hard to know what 
> will happen after that:-(
>
> Could you try with initcall_debug in your command line?

Somehow I figured this out, the patch "arm: mach-omap2: omap_l3_smx:
fix irq handler setup" fixes the hang for me (and of course I still need
to comment out timer 12).

A.

Re: Code for v2.6.39 merge window frozen, patches archived

[Aaro Koskinen]

Hi,

On Wed, 16 Mar 2011, Tony Lindgren wrote:
> FYI, my rx51 boots fine with omap2plus defconfig, also with
> earlyprintk.

For the RX-51 earlyprintk problem I need to enable pr_debug()s in
omap_hwmod.c. Otherwise it won't trigger. Of course that's a pretty
artificial test case, so I guess we can forget that for a time being.

A.

Re: Code for v2.6.39 merge window frozen, patches archived

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@nokia.com> [110316 10:10]:
> 
> Somehow I figured this out, the patch "arm: mach-omap2: omap_l3_smx:
> fix irq handler setup" fixes the hang for me (and of course I still need
> to comment out timer 12).

FYI, looks like we've started hitting some booter -l kernel size limit
in addition to booter -f size limit.. Now kernels built with
omap2plus_defconfig won't boot on n900 any longer.

I guess the way around that is to install the u-boot loader package.

Regards,

Tony

Re: Code for v2.6.39 merge window frozen, patches archived

[Kevin Hilman]

Tony Lindgren <tony@atomide.com> writes:

> * Aaro Koskinen <aaro.koskinen@nokia.com> [110316 10:10]:
>> 
>> Somehow I figured this out, the patch "arm: mach-omap2: omap_l3_smx:
>> fix irq handler setup" fixes the hang for me (and of course I still need
>> to comment out timer 12).
>
> FYI, looks like we've started hitting some booter -l kernel size limit
> in addition to booter -f size limit.. Now kernels built with
> omap2plus_defconfig won't boot on n900 any longer.
>
> I guess the way around that is to install the u-boot loader package.

Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back
within size limits that will boot on n900.

Kevin

Re: Code for v2.6.39 merge window frozen, patches archived

[Aaro Koskinen]

Hi,

On Wed, 30 Mar 2011, Kevin Hilman wrote:
> Tony Lindgren <tony@atomide.com> writes:
>> FYI, looks like we've started hitting some booter -l kernel size limit
>> in addition to booter -f size limit.. Now kernels built with
>> omap2plus_defconfig won't boot on n900 any longer.

I guess you are seeing it just hanging at "Uncompressing Linux... done,
booting the kernel."?

>> I guess the way around that is to install the u-boot loader package.
>
> Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back
> within size limits that will boot on n900.

Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I
can't see any "special" limit exceeded. Also LZMA is broken:

 	Uncompressing Linux...

 	LZMA data is corrupt

 	-- System halted

I did some bisecting, and with the following commit reverted -rc1 works:

 	commit d239b1dc093d551046a909920b5310c1d1e308c1
 	Author: Nicolas Pitre <nicolas.pitre@linaro.org>
 	Date:   Mon Feb 21 04:57:38 2011 +0100

 	ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel

With the revert, also bigger gzipped kernel works.

A.

Re: Code for v2.6.39 merge window frozen, patches archived

[Nicolas Pitre]

On Thu, 31 Mar 2011, Aaro Koskinen wrote:

> Hi,
> 
> On Wed, 30 Mar 2011, Kevin Hilman wrote:
> > Tony Lindgren <tony@atomide.com> writes:
> > > FYI, looks like we've started hitting some booter -l kernel size limit
> > > in addition to booter -f size limit.. Now kernels built with
> > > omap2plus_defconfig won't boot on n900 any longer.
> 
> I guess you are seeing it just hanging at "Uncompressing Linux... done,
> booting the kernel."?
> 
> > > I guess the way around that is to install the u-boot loader package.
> > 
> > Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back
> > within size limits that will boot on n900.
> 
> Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I
> can't see any "special" limit exceeded. Also LZMA is broken:
> 
> 	Uncompressing Linux...
> 
> 	LZMA data is corrupt
> 
> 	-- System halted
> 
> I did some bisecting, and with the following commit reverted -rc1 works:
> 
> 	commit d239b1dc093d551046a909920b5310c1d1e308c1
> 	Author: Nicolas Pitre <nicolas.pitre@linaro.org>
> 	Date:   Mon Feb 21 04:57:38 2011 +0100
> 
> 	ARM: 6746/1: remove the 4x expansion presumption while decompressing
> the kernel
> 
> With the revert, also bigger gzipped kernel works.

OK I will have a look.


Nicolas

Re: Code for v2.6.39 merge window frozen, patches archived

[Tony Lindgren]

* Nicolas Pitre <nicolas.pitre@linaro.org> [110402 05:40]:
> On Thu, 31 Mar 2011, Aaro Koskinen wrote:
> 
> > Hi,
> > 
> > On Wed, 30 Mar 2011, Kevin Hilman wrote:
> > > Tony Lindgren <tony@atomide.com> writes:
> > > > FYI, looks like we've started hitting some booter -l kernel size limit
> > > > in addition to booter -f size limit.. Now kernels built with
> > > > omap2plus_defconfig won't boot on n900 any longer.
> > 
> > I guess you are seeing it just hanging at "Uncompressing Linux... done,
> > booting the kernel."?
> > 
> > > > I guess the way around that is to install the u-boot loader package.
> > > 
> > > Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back
> > > within size limits that will boot on n900.
> > 
> > Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I
> > can't see any "special" limit exceeded. Also LZMA is broken:
> > 
> > 	Uncompressing Linux...
> > 
> > 	LZMA data is corrupt
> > 
> > 	-- System halted
> > 
> > I did some bisecting, and with the following commit reverted -rc1 works:
> > 
> > 	commit d239b1dc093d551046a909920b5310c1d1e308c1
> > 	Author: Nicolas Pitre <nicolas.pitre@linaro.org>
> > 	Date:   Mon Feb 21 04:57:38 2011 +0100
> > 
> > 	ARM: 6746/1: remove the 4x expansion presumption while decompressing
> > the kernel
> > 
> > With the revert, also bigger gzipped kernel works.
> 
> OK I will have a look.

Hmm while playing with the device tree append patch, decompress_kernel
trashes the first 16 bytes of the device tree data. Now I wonder if these
issues are related..

Aaro, you mentioned to me that reverting commit 
6d7d0ae51574943bf571d269da3243257a2d15db helps too?

With the device tree append patch reverting commit
d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting
6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging..

Anyways, that might be another way to reproduce the problem if these
issues are related.

Regards,

Tony

Re: Code for v2.6.39 merge window frozen, patches archived

[Aaro Koskinen]

Hi,

On Wed, 13 Apr 2011, Tony Lindgren wrote:
> * Nicolas Pitre <nicolas.pitre@linaro.org> [110402 05:40]:
>> On Thu, 31 Mar 2011, Aaro Koskinen wrote:
>>> On Wed, 30 Mar 2011, Kevin Hilman wrote:
>>>> Tony Lindgren <tony@atomide.com> writes:
>>>>> FYI, looks like we've started hitting some booter -l kernel size limit
>>>>> in addition to booter -f size limit.. Now kernels built with
>>>>> omap2plus_defconfig won't boot on n900 any longer.
>>>
>>> I guess you are seeing it just hanging at "Uncompressing Linux... done,
>>> booting the kernel."?
>>>
>>>>> I guess the way around that is to install the u-boot loader package.
>>>>
>>>> Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back
>>>> within size limits that will boot on n900.
>>>
>>> Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I
>>> can't see any "special" limit exceeded. Also LZMA is broken:
>>>
>>> 	Uncompressing Linux...
>>>
>>> 	LZMA data is corrupt
>>>
>>> 	-- System halted
>>>
>>> I did some bisecting, and with the following commit reverted -rc1 works:
>>>
>>> 	commit d239b1dc093d551046a909920b5310c1d1e308c1
>>> 	Author: Nicolas Pitre <nicolas.pitre@linaro.org>
>>> 	Date:   Mon Feb 21 04:57:38 2011 +0100
>>>
>>> 	ARM: 6746/1: remove the 4x expansion presumption while decompressing
>>> the kernel
>>>
>>> With the revert, also bigger gzipped kernel works.
>>
>> OK I will have a look.
>
> Hmm while playing with the device tree append patch, decompress_kernel
> trashes the first 16 bytes of the device tree data. Now I wonder if these
> issues are related..
>
> Aaro, you mentioned to me that reverting commit
> 6d7d0ae51574943bf571d269da3243257a2d15db helps too?
>
> With the device tree append patch reverting commit
> d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting
> 6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging..

Yes, with -rc1, reverting also 6d7d0ae51574943bf571d269da3243257a2d15db
(ARM: 6750/1: improvements to compressed/head.S) helps. I haven't tried
with newer kernels.

A.

Re: Code for v2.6.39 merge window frozen, patches archived

[Nicolas Pitre]

On Wed, 13 Apr 2011, Tony Lindgren wrote:

> * Nicolas Pitre <nicolas.pitre@linaro.org> [110402 05:40]:
> > On Thu, 31 Mar 2011, Aaro Koskinen wrote:
> > 
> > > Hi,
> > > 
> > > On Wed, 30 Mar 2011, Kevin Hilman wrote:
> > > > Tony Lindgren <tony@atomide.com> writes:
> > > > > FYI, looks like we've started hitting some booter -l kernel size limit
> > > > > in addition to booter -f size limit.. Now kernels built with
> > > > > omap2plus_defconfig won't boot on n900 any longer.
> > > 
> > > I guess you are seeing it just hanging at "Uncompressing Linux... done,
> > > booting the kernel."?
> > > 
> > > > > I guess the way around that is to install the u-boot loader package.
> > > > 
> > > > Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back
> > > > within size limits that will boot on n900.
> > > 
> > > Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I
> > > can't see any "special" limit exceeded. Also LZMA is broken:
> > > 
> > > 	Uncompressing Linux...
> > > 
> > > 	LZMA data is corrupt
> > > 
> > > 	-- System halted
> > > 
> > > I did some bisecting, and with the following commit reverted -rc1 works:
> > > 
> > > 	commit d239b1dc093d551046a909920b5310c1d1e308c1
> > > 	Author: Nicolas Pitre <nicolas.pitre@linaro.org>
> > > 	Date:   Mon Feb 21 04:57:38 2011 +0100
> > > 
> > > 	ARM: 6746/1: remove the 4x expansion presumption while decompressing
> > > the kernel
> > > 
> > > With the revert, also bigger gzipped kernel works.
> > 
> > OK I will have a look.
> 
> Hmm while playing with the device tree append patch, decompress_kernel
> trashes the first 16 bytes of the device tree data. Now I wonder if these
> issues are related..
> 
> Aaro, you mentioned to me that reverting commit 
> 6d7d0ae51574943bf571d269da3243257a2d15db helps too?
> 
> With the device tree append patch reverting commit
> d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting
> 6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging..

You cannot use the DT append patch without 6d7d0ae515 in place.  The 
later is a prerequisite for the former.

> Anyways, that might be another way to reproduce the problem if these
> issues are related.

I've started to instrument the problematic CONFIG_KERNEL_LZMA case.  So 
far this is still a mystery.

Do you have problems with the DT append patch even with 
CONFIG_KERNEL_GZIP=y?


Nicolas

Re: Code for v2.6.39 merge window frozen, patches archived

[Tony Lindgren]

* Nicolas Pitre <nicolas.pitre@linaro.org> [110413 17:46]:
> On Wed, 13 Apr 2011, Tony Lindgren wrote:
> > 
> > With the device tree append patch reverting commit
> > d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting
> > 6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging..
> 
> You cannot use the DT append patch without 6d7d0ae515 in place.  The 
> later is a prerequisite for the former.

OK.
 
> > Anyways, that might be another way to reproduce the problem if these
> > issues are related.
> 
> I've started to instrument the problematic CONFIG_KERNEL_LZMA case.  So 
> far this is still a mystery.
> 
> Do you have problems with the DT append patch even with 
> CONFIG_KERNEL_GZIP=y?

Yup. The devicetree data gets trashed by decompress_kernel
with CONFIG_KERNEL_GZIP too with the append patch.

DT data before decompress_kernel:
edfe0dd0 2c010000 38000000 f0000000

DT data after decompress_kernel:
10000000 00000001 38000000 f0000000

So first 8 (not 16 bytes like I mentioned earlier) get trashed.

Regards,

Tony

Re: Code for v2.6.39 merge window frozen, patches archived

[Jarkko Nikula]

On Wed, 13 Apr 2011 17:34:24 +0300 (EEST)
Aaro Koskinen <aaro.koskinen@nokia.com> wrote:

> > Aaro, you mentioned to me that reverting commit
> > 6d7d0ae51574943bf571d269da3243257a2d15db helps too?
> >
> > With the device tree append patch reverting commit
> > d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting
> > 6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging..
> 
> Yes, with -rc1, reverting also 6d7d0ae51574943bf571d269da3243257a2d15db
> (ARM: 6750/1: improvements to compressed/head.S) helps. I haven't tried
> with newer kernels.
> 
Same note here from -rc3. For me it was enough to revert
6d7d0ae51574943bf571d269da3243257a2d15db.

I was struggling with some of my own configs that didn't boot on Nokia
N900 and config differences between working one and not working looked
like a random.

E.g. if one config had CONFIG_KALLSYMS_ALL=y, it didn't boot but booted
if CONFIG_DEBUG_SPINLOCK=y was also enabled and so forth.
CONFIG_KERNEL_LZMA=y either didn't make it booting. But revert made
those unworking configs booting.

-- 
Jarkko

Re: Code for v2.6.39 merge window frozen, patches archived

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [110413 08:06]:
> * Nicolas Pitre <nicolas.pitre@linaro.org> [110413 17:46]:
> > On Wed, 13 Apr 2011, Tony Lindgren wrote:
> > > 
> > > With the device tree append patch reverting commit
> > > d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting
> > > 6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging..
> > 
> > You cannot use the DT append patch without 6d7d0ae515 in place.  The 
> > later is a prerequisite for the former.
> 
> OK.
>  
> > > Anyways, that might be another way to reproduce the problem if these
> > > issues are related.
> > 
> > I've started to instrument the problematic CONFIG_KERNEL_LZMA case.  So 
> > far this is still a mystery.
> > 
> > Do you have problems with the DT append patch even with 
> > CONFIG_KERNEL_GZIP=y?
> 
> Yup. The devicetree data gets trashed by decompress_kernel
> with CONFIG_KERNEL_GZIP too with the append patch.
> 
> DT data before decompress_kernel:
> edfe0dd0 2c010000 38000000 f0000000
> 
> DT data after decompress_kernel:
> 10000000 00000001 38000000 f0000000
> 
> So first 8 (not 16 bytes like I mentioned earlier) get trashed.

Aaro and I speculated that boards using u-boot with uImage work,
while n900 is using zImage and fails with the same kernel probably
because of the different placement of compressed image in the
memory.

Also boards using u-boot with uImage fail with the DT append
patch if some DT data is appended to zImage before mkimage.

Hardcoding the uncompressed image size about 2MB larger in
arch/arm/boot/Makefile makes booting n900 work. This will not
solve the DT append problem, or at least would require padding
the uncompressed image size accordingly before appending DT
data..

Tony

Re: Code for v2.6.39 merge window frozen, patches archived

[Nicolas Pitre]

On Tue, 19 Apr 2011, Tony Lindgren wrote:

> Aaro and I speculated that boards using u-boot with uImage work,
> while n900 is using zImage and fails with the same kernel probably
> because of the different placement of compressed image in the
> memory.

Could you try the following (by changing the argument to mkimage 
accordingly).
Try to load the kernel at the following offsets:

- 0x8000 from start of memory

- 0x100000 from start of memory

- 0x3000000 from start of memory

and tell me if any of those behaves differently?


Nicolas

Re: Code for v2.6.39 merge window frozen, patches archived

[Tony Lindgren]

* Nicolas Pitre <nicolas.pitre@linaro.org> [110419 06:24]:
> On Tue, 19 Apr 2011, Tony Lindgren wrote:
> 
> > Aaro and I speculated that boards using u-boot with uImage work,
> > while n900 is using zImage and fails with the same kernel probably
> > because of the different placement of compressed image in the
> > memory.
> 
> Could you try the following (by changing the argument to mkimage 
> accordingly).
>
> Try to load the kernel at the following offsets:
> 
> - 0x8000 from start of memory
> 
> - 0x100000 from start of memory
> 
> - 0x3000000 from start of memory
> 
> and tell me if any of those behaves differently?

Hmm good idea, but no luck so far :( Did the tests with
setenv loadaddr in u-boot as that's what it seems to use.

v2.6.39-rc4 boots uImage with all those just fine. And with
the DT append and related patches, it always fails if DT data
is appended.

So for some reason loading a kernel on n900 with flasher -l
always fails (except for smaller kernels) and DT append with
data appended always fails.

Regards,

Tony