Andre Renaud wrote at Wednesday, February 29, 2012 1:12 PM: > 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. OK, there probably are multiple different issues affecting the performance, and this patch only affects the one that applies once you've decided to use uImage to wrap a zImage in the first place. -- nvpublic -- 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
