* Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> [110402 05:40]: > On Thu, 31 Mar 2011, Aaro Koskinen wrote: > > > Hi, > > > > On Wed, 30 Mar 2011, Kevin Hilman wrote: > > > Tony Lindgren <tony@xxxxxxxxxxx> 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@xxxxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
