From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christophe PLAGNIOL-VILLARD Subject: Re: [PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload Date: Thu, 1 Mar 2012 05:55:43 +0100 Message-ID: <20120301045543.GL3318@game.jcrosoft.org> References: <20120229191209.GN14173@pengutronix.de> <74CDBE0F657A3D45AFBB94109FB122FF17BDDF2122@HQMAIL01.nvidia.com> <20120229194409.GO14173@pengutronix.de> <74CDBE0F657A3D45AFBB94109FB122FF17BDDF2155@HQMAIL01.nvidia.com> <4F4E86A1.8010506@bluewatersys.com> <20120229201938.GB16999@n2100.arm.linux.org.uk> <4F4E89A8.4080909@bluewatersys.com> <20120229203958.GQ14173@pengutronix.de> <20120229204527.GD16999@n2100.arm.linux.org.uk> <20120229205901.GR14173@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <20120229205901.GR14173@pengutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Cc: Stephen Warren , Nicolas Pitre , Peter De Schrijver , Olof Johansson , Andre Renaud , Tim Bird , Colin Cross , "linux-tegra@vger.kernel.org" , Russell King - ARM Linux , "linux-arm-kernel@lists.infradead.org" List-Id: linux-tegra@vger.kernel.org On 21:59 Wed 29 Feb , Uwe Kleine-K=F6nig wrote: > On Wed, Feb 29, 2012 at 08:45:27PM +0000, Russell King - ARM Linux wrote: > > On Wed, Feb 29, 2012 at 09:39:58PM +0100, Uwe Kleine-K=F6nig wrote: > > > I'd bet your platform has cache support in the decompressor without > > > knowing which platform you use. I suggest commenting out > > > = > > > bl cache_on > > > = > > > in arch/arm/boot/compressed/head.S to see the difference. > > > = > > > How do you build the uImage containing the zImage? If you use the > > > in-kernel uImage target booting that usually means: > > > = > > > - move the zImage to ZRELADDR > > > - jump into zImage > > > - decompress zImage to somewhere else > > > - move decompressed image to ZRELADDR > > > - jump to ZRELADDR > > > = > > > That is you have two relocations because the first location for sure > > > conflicts with the decompressed image. > > = > > Actually, we do this slightly differently nowadays. Inside zImage: > > = > > - if zImage location conflicts, move the decompressed data > s/de// > = > > and decompressor to another location > > - decompress zImage to ZRELADDR > > - jump to ZRELADDR > > = > > That reduces the size required for copying. Of course, that copy can > > (as it's always been the case) be totally eliminated by ensuring that > > you load the zImage out of the way of the decompressed image. > > = > > So, really, comparing a standard uImage produced by the standard kernel > > with gzipped Image is far from a fair comparison. And that's actually > > another argument for getting rid of the uImage target... it may make > > people think a bit about what they're doing rather than accepting > > whatever default location someone else chose for their kernel. > I'm all in favour to remove the uImage target because back in 2007 we > already had a similar discussion[1]. (Back then I still thought that > improving the uImage support would be a good idea.) > = > That said I think *in general* having support for U-Boot in the kernel > is fine because I think U-Boot is the bootloader used most. But if you > need some Kconfig settings or more than one Makefile target I think just > building an Image or zImage and doing the U-Boot wrapping without the > help of Linux' build system is preferable. Agreed at 200% Best Regards, J.