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/ | -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
