* Tony Lindgren <tony@xxxxxxxxxxx> [110413 08:06]: > * Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> [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 -- 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
