Dear Simon Glass,
In message CAPnjgZ2aRP5Hn-3jREa=OfGs0K7Ny9b2mWP3pwPBRW5svL3Aew@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