Code for v2.6.39 merge window frozen, patches archived

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.

Tony Lindgren wrote, on 03/15/2011 12:55 AM:
[..]

Quoted 4 lines

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.

Quoted 11 lines · Nishanth Menon

Tony Lindgren wrote, on 03/15/2011 12:55 AM:
[..]

Quoted 4 lines

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.

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.

Hi,

Quoted 5 lines · Tony Lindgren

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 18 lines · Tony Lindgren

Quoted 5 lines

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.

Quoted 3 lines

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

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?

Hi,

Quoted 3 lines · Benoit

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

Hi Aaro,

Quoted 9 lines · Aaro Koskinen

Hi,

Quoted 3 lines · Benoit

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?

Quoted 13 lines

[...]

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

Quoted 7 lines · Aaro Koskinen

Quoted 3 lines · Benoit

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?

Quoted 1 line

[    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).

Quoted 4 lines · Aaro Koskinen

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.

Quoted 3 lines · Tony Lindgren

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.

Quoted 1 line

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.

Hi,

Quoted 4 lines · Kevin Hilman

Quoted 3 lines · Tony Lindgren

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."?

Quoted 4 lines

Quoted 1 line

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 <[email protected]>
	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.

Quoted 31 lines · Aaro Koskinen

Hi,

Quoted 4 lines · Kevin Hilman

Quoted 3 lines · Tony Lindgren

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."?

Quoted 4 lines

Quoted 1 line

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 <[email protected]>
	Date:   Mon Feb 21 04:57:38 2011 +0100

Quoted 4 lines

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.

Quoted 30 lines · Nicolas Pitre

Quoted 29 lines · Aaro Koskinen

Quoted 4 lines · Kevin Hilman

Quoted 3 lines · Tony Lindgren

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."?

Quoted 4 lines

Quoted 1 line

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 <[email protected]>
	Date:   Mon Feb 21 04:57:38 2011 +0100

Quoted 6 lines

Quoted 4 lines

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

Quoted 6 lines

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.

Quoted 33 lines · Nicolas Pitre

Quoted 31 lines · Aaro Koskinen

Hi,

Quoted 4 lines · Kevin Hilman

Quoted 3 lines · Tony Lindgren

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."?

Quoted 4 lines

Quoted 1 line

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 <[email protected]>
	Date:   Mon Feb 21 04:57:38 2011 +0100

Quoted 6 lines

Quoted 4 lines

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.

Quoted 4 lines · Tony Lindgren

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.

Quoted 2 lines

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?

Quoted 8 lines · Nicolas Pitre

Quoted 4 lines · Tony Lindgren

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 4 lines · Tony Lindgren

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?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 7 lines · 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.

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

Quoted 21 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 13 lines · Manjunath Kondaiah

Quoted 7 lines · 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.

omap-for-linus boots on:
OMAP3430-Zoom2
OMAP3630-Zoom3
OMAP4430-Blaze

Quoted 3 lines

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

Also boots on OMAP1710-H3

-Manjunath

Quoted 24 lines

-Manjunath

Quoted 21 lines

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 [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html