From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Tue, 22 Jan 2013 09:52:18 +0000 Subject: OMAP baseline test results for v3.8-rc4 In-Reply-To: <87ham95zdt.fsf@dell.be.48ers.dk> References: <50FD6D8D.6030106@mimc.co.uk> <20130121164510.GA18905@kahuna> <20130121182419.GE10020@beef> <87boci9str.fsf@dell.be.48ers.dk> <1358846666.3996.3.camel@coredoba.hi.pengutronix.de> <87ham95zdt.fsf@dell.be.48ers.dk> Message-ID: <20130122095218.GD2637@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Jan 22, 2013 at 10:40:46AM +0100, Peter Korsgaard wrote: > >>>>> "Jan" == Jan L?bbe writes: > > Jan> On Tue, 2013-01-22 at 02:24 +0000, Paul Walmsley wrote: > >> Regarding the AM33xx test failures with appended DTBs, it would be very > >> helpful if especially the TI people could try reproducing the problem. > >> Otherwise it's going to cause problems with merging any new AM33xx > >> patches, since I won't be able to test them without additional work. > >> Plus, this is something that used to work up until d01e4afd, so something > >> isn't right. > > Jan> Just a guess, but there can be problems when the appended DTB > Jan> crosses an 1MB boundary. See this mail for details and a patch: > Jan> http://www.spinics.net/lists/arm-kernel/msg216898.html > > True, but that doesn't seem to be the case here: > ls -la arch/arm/boot/uImage > -rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage > > E.G. far from the 1MB boundary. Don't rely on that. Remember, if the compressed image occupies the same location as the decompressed kernel, the decompressor will copy the data to a different location in RAM first - I think at RAM offset + 32K + decompressed kernel size. So yes, please try the patch in the link above.