Dear Holger,
in message 200211131007.24226.h.schurig@mn-logistik.de you wrote:
For booting a Linux zImage, you simply jump to it's location (after setting up the registers). And you have to set up registers and jump to some extracted code anyway, no matter if you if the zImage is already there or if it just got extracted out of some mkimage-made image. Setting up the rigth registers with the right info is OS dependend anyway.
What is the reason for this, why do you think the image approach is better --- or even necessary?
This approach is the result of recurring customer requirements. Our customers ask:
* How can I identify an image I have stored in flash? Which version is it? ==> Approach: Name String
* How can I find out when the image was built? ==> Approach: Time stamp
* How can I make sure an image is OK, i. e. that it was neither corrupted during download or by erasing / overwriting parts of the flash where I stroed it? ==> Approach: CRC32 checksum
* How can I make sure I don't try booting a valid image, which is in fact not a Linux kernel but something else (ramdisk, xxxOS image, ...)? ==> Approach: Tags for OS, type, architecture, etc.
All these issues are required byu many embedded projects where reliability, software updates etc. play a role. That's why we wrap the images (Linux kernel, ramdisk, multi-file images, scripts, firmware, ...) with a special header containing all the required metadata and checksums.
Don't read this as a critique, I really don't understand the motivation behind this.
There is no technical need for the header if all you want to do is booting a Linux kernel. But if you have to organize production of sortware and hardware and set up all the processes for software updates you will appreciate such mechanisms.
Best regards,
Wolfgang Denk