On Thu, Sep 09, 2010, Wolfgang Denk wrote: > > These are indeed nice features of uImages (checksums + > > build date information); but they are not needed in all use cases for > > U-Boot. Distributions are shipping zImage for ARM nowadays and when > > shipping zImage files withing packages (.deb for instance), there are > > already checksums, file timestamps, public build logs etc. as part of > > the distro toolkit. > > Hm... the checksum of the distributyed poackage gives you zero help > when it comes to check the image after a download to the target.
Note that packages are downloaded directly *on* the target; that is, the target is running e.g. Debian or Ubuntu, one gets a kernel upgrade in the form of a .deb which is checksummed, installed and its contents get written to flash. > Keep in mind that the uImage format was invented to address typical > problems of embedded systems: > > You have a device with some data in flash. You don't know what > happened to the device. Now quickly check: > - Is it a kernel? Is it a file system? > - Has the image been corrupted / partially overwritten? > - Which version / production ID / production time is this image > from? Yup; I can see how all of these make sense and are useful in the context of embedded systems; I think we're looking at a different use case for mainstream linux distributions here where processes and tools already deal with the above. > > Also, this means end-user systems need mkimage installed (because > > uImage differ slightly across boards). Not a problem for an embedded > > developer obviously, but would prefer avoiding this need on an end-user > > system. > > I don't see why uImages differ across boards - if the same kernel > image can be used (i. e. the same zImage file use to generate the > uImages) on these boards? Well, it was my understanding that different boards need different load addresses and/or different entry points; currently, for the same ARM SoC, it's mostly the same address. But when you start building a single zImage targetting multiple SoCs, it might not be the case anymore. (https://wiki.ubuntu.com/Specs/ARMSingleKernel) [...] > For PowerPC, initrd images have load address and entry point address > set to dummy values (0), which are not used anywhere in U-Boot. We could of course ignore the data in the uImage, and write 0x0 as you suggest: that's why we don't need this data in the uImage in the first place in our use case. > If you can come up with position independent payload, you still need > the entry point (then probably in terms of offset relative to the > current image address). Yes; but even with a position independent kernel, we need to know where in memory it should preferably be loaded (even if almost anywhere would work, there's a limited range or physical memory). > Patches to implement this (in the context of FIT images) are welcome. To make sure I got that right: you propose extending the uImage.FIT format to allow for a relative entry address instead of absolute load address + absolute entry point, correct? That sounds like something useful indeed. My understanding of the ARM zImage uncompress code is that the entry point would basically be at offset zero once loaded in memory, for all targets/boards. > This makes no sense to me. Ramdisk images don't need to be loaded > anywhere. I consider it a bug in the ARM Linux kernel that you have > to load a compressed initrd image to RAM first, then uncompress it, > then use it. In other architectures (say PPC) we can pass the address > of the image in flash memory to the kernel, which saves one copy > operation. I don't know enough about the ARM kernel's ramdisk code to comment on whether or not it could be uncompressed directly from flash into RAM; the way these are usually handled in Debian/Ubuntu so far is that the bootloader has a load command for the ramdisk from persistent storage to RAM (either NAND or MMC), then a load command for the kernel from persistent storage to RAM (either NAND or MMC), then calls the kernel entry point with the ramdisk address as an ATAG. You could argue that we could also run zImage directly from flash, and let it unpack itself into RAM. I suspect the reason it's not commonly done is because it's very specialized to flash and doesn't apply to e.g. MMC, but I don't really know for sure. > Patches to support this for ARM as well have been submitted - and > rejected. Hmm ok; do you have some pointers/rationale? It's interesting to gather past ideas and counter-arguments to try to improve the ARM boot architecture. > > So we'd be happy if you'd take patches to have U-Boot accept this > > "dumber" format. > You may be aware that the implementation of the "bootm" command has > been split into small building blocks some time ago. The idea was to > allow for easy customizing, eventually even on command line level. > You should be able to craft a custom boot command this way, which > omits the header check. Ok; I wonder if we could just have an IMAGE_FORMAT_ZIMAGE and CONFIG_ZIMAGE instead? > But I don't think that this solves your problem - you still need > information at least about the entry point address, which then has to > be stored separate from the image file, which just shifts the problem > to another area. Isn't it always at offset 0 for an ARM zImage payload? The main thing I'd like the bootloader to keep track of is the physical load address at which to load the kernel; usually this is 0x8000 when possible. I am not sure it needs to track anything else. -- Loïc Minier _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
