[PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload

[u.kleine-koenig@pengutronix.de (Uwe Kleine-König)]

On Thu, Mar 01, 2012 at 09:25:12AM +1300, Andre Renaud wrote:
> Hi Russell,
> >> 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,
> > 
> > Most certainly not.  We've had the data cache enabled for years and
> > years.  And I mean 10+ years.  We may have been lacking support on
> > some CPUs, but that was because of lack of contributions.
> > 
> >> 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?
> > 
> > That's pure FUD.
> 
> I don't want to open a can of worms on this, and I certainly haven't
> looked into the image decompressor within the Linux kernel, but from a
> boot speed point of view we certainly see a significant speed
> improvement switching from zImage to gzipped-Image. Do you know which
> platforms include the data-cache support in the decompressor?
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.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |