From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Renaud Subject: Re: [PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload Date: Thu, 01 Mar 2012 09:12:17 +1300 Message-ID: <4F4E86A1.8010506@bluewatersys.com> References: <1330473804-23348-1-git-send-email-swarren@nvidia.com> <20120229122942.GF3318@game.jcrosoft.org> <74CDBE0F657A3D45AFBB94109FB122FF17BDDF206A@HQMAIL01.nvidia.com> <20120229181430.GI3318@game.jcrosoft.org> <4F4E6F96.8080907@am.sony.com> <20120229191209.GN14173@pengutronix.de> <74CDBE0F657A3D45AFBB94109FB122FF17BDDF2122@HQMAIL01.nvidia.com> <20120229194409.GO14173@pengutronix.de> <74CDBE0F657A3D45AFBB94109FB122FF17BDDF2155@HQMAIL01.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF17BDDF2155-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Stephen Warren Cc: =?ISO-8859-1?Q?Uwe_Kleine-K=F6nig?= , Russell King , Nicolas Pitre , Peter De Schrijver , Olof Johansson , Tim Bird , Colin Cross , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Jean-Christophe PLAGNIOL-VILLARD , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: linux-tegra@vger.kernel.org On 01/03/12 08:59, Stephen Warren wrote: > Uwe Kleine-K=F6nig wrote at Wednesday, February 29, 2012 12:44 PM: > ... >> If you want to give incentive for U-Boot to improve, drop the target >> today. And note that at least people caring about boot time must not= use >> the kernel's uImage target anyhow. >=20 > If you enable the new config option in this patch, then the performan= ce > issue is solved; U-Boot doesn't copy the kernel image any more, and t= he > kernel decompressor can write directly to the appropriate location wi= thout > moving the image first (assuming your board boot script loads the uIm= age > to a non-conflicting address). I may have missed part of this, but isn't one of the points regarding this that the zImage decompressor always runs with data cache disabled, resulting in a slow decompress, where as if the U-Boot decompressor is used (ie, gzipping the Image, and telling U-Boot to decompress), then i= t can run with caches enabled, improving boot speed? Thus the relocation issue is not really the speed hit, rather it is the image decompression. Regards, Andre From mboxrd@z Thu Jan 1 00:00:00 1970 From: andre@bluewatersys.com (Andre Renaud) Date: Thu, 01 Mar 2012 09:12:17 +1300 Subject: [PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF17BDDF2155@HQMAIL01.nvidia.com> References: <1330473804-23348-1-git-send-email-swarren@nvidia.com> <20120229122942.GF3318@game.jcrosoft.org> <74CDBE0F657A3D45AFBB94109FB122FF17BDDF206A@HQMAIL01.nvidia.com> <20120229181430.GI3318@game.jcrosoft.org> <4F4E6F96.8080907@am.sony.com> <20120229191209.GN14173@pengutronix.de> <74CDBE0F657A3D45AFBB94109FB122FF17BDDF2122@HQMAIL01.nvidia.com> <20120229194409.GO14173@pengutronix.de> <74CDBE0F657A3D45AFBB94109FB122FF17BDDF2155@HQMAIL01.nvidia.com> Message-ID: <4F4E86A1.8010506@bluewatersys.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/03/12 08:59, Stephen Warren wrote: > Uwe Kleine-K?nig wrote at Wednesday, February 29, 2012 12:44 PM: > ... >> If you want to give incentive for U-Boot to improve, drop the target >> today. And note that at least people caring about boot time must not use >> the kernel's uImage target anyhow. > > If you enable the new config option in this patch, then the performance > issue is solved; U-Boot doesn't copy the kernel image any more, and the > kernel decompressor can write directly to the appropriate location without > moving the image first (assuming your board boot script loads the uImage > to a non-conflicting address). I may have missed part of this, but isn't one of the points regarding this that the zImage decompressor always runs with data cache disabled, resulting in a slow decompress, where as if the U-Boot decompressor is used (ie, gzipping the Image, and telling U-Boot to decompress), then it can run with caches enabled, improving boot speed? Thus the relocation issue is not really the speed hit, rather it is the image decompression. Regards, Andre