Dear Simon Glass, In message <CAPnjgZ2aRP5Hn-3jREa=ofgs0k7ny9b2mwp3pwpbrw5svl3...@mail.gmail.com> you wrote: > > > Firstly, there is not just u-Boot out there. And since the layout > > optimization for Linux when decompressing is by definition Linux > > specific, this better live in zImage than be duplicated in every > > bootloaders. > > Actually I was talking about the case where U-Boot does the > decompression. You have said it is supported above. I don't suggest > that it be the only option, only that it be an option. Perhaps only > U-Boot will use it, but that is fine. U-Boot is a popular boot loader.
Thanks a lot for bringing up these arguments. > If the boot loader puts the pieces in the right place, decompressed > and ready to go, we could presumably avoid this code in the kernel: > > 1096 4860 27129 arch/arm/boot/compressed/head.S > 13 53 304 arch/arm/boot/compressed/big-endian.S > 50 153 1267 arch/arm/boot/compressed/decompress.c > 1096 4860 27129 arch/arm/boot/compressed/head.S > 47 214 1238 arch/arm/boot/compressed/head-sa1100.S > 139 650 3537 arch/arm/boot/compressed/head-shark.S > 150 619 3564 arch/arm/boot/compressed/head-sharpsl.S > 53 263 1685 arch/arm/boot/compressed/head-shmobile.S > 41 179 992 arch/arm/boot/compressed/head-xscale.S > 134 571 2868 arch/arm/boot/compressed/ll_char_wr.S > 124 324 3011 arch/arm/boot/compressed/Makefile > 208 589 3812 arch/arm/boot/compressed/misc.c > 260 604 5289 arch/arm/boot/compressed/ofw-shark.c > 6 10 145 arch/arm/boot/compressed/piggy.gzip.S > 6 10 145 arch/arm/boot/compressed/piggy.lzma.S > 6 10 144 arch/arm/boot/compressed/piggy.lzo.S > 70 226 1481 arch/arm/boot/compressed/vmlinux.lds.in > 2403 9335 56611 total I think you can even add the actual (de-) compressor routines. > That gives the kernel what it wants. How can we give U-Boot what it > wants, which is apparently the ability to decompress the kernel itself > and arrange everything in memory at the right place? Wolfgang > complains that patches to do this have been repeatedly rejected in the > kernel. If this is the FIT image, how about adding a 'fitImage' make > target? It would not only be FIT images. Why not support old uImage format in a "proper" way? In most cases people do not need the features provided by FIT images, and they prefer the simplicity of uImages. Thanks again. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Crash programs fail because they are based on the theory that, with nine women pregnant, you can get a baby a month. - Wernher von Braun _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
