Hi Wolfgang, > > IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the > > Makefile so that make behaves more consistently. Speaking of which, > > the number of '.' in the name is getting rather large. Would you > > consider using 'fitImage' instead of 'uImage.fit'? > > Why chose a different name at all? We could still call it "uImage", > meaning "U-Boot image" - U-Boot is clever enought o detect > automatically if we pass it an old style or a fit image. I agree with your point to an extent, but having 2 types of uImages is somewhat confusing to a user, even if U-Boot can differentiate between them. And if the legacy image and FIT image had the same Make target, how does a user specify which type they want to build? The fact that both "legacy" and FIT images would reside at arch/powerpc/boot/uImage doesn't make things any less confusing to Joe User. Currently U-Boot supports booting: 1 "legacy" uImages 2 "new" Flattened Image Tree (FIT) uImages What do you think about changing the U-Boot documentation to rename those 2 image types to: 1 uImages 2 FIT Images The FIT image is a relatively generic image type - its just a blob that dtc created from a device tree and some input binaries. In my mind its not intimately tied to U-Boot, at least not conceptually. The "legacy" uImages have to agree with U-Boot's header format defined in the U-Boot source code, so the uImage name does make sense with respect to the "legacy" uImages. My vote would be to make the Linux FIT target rule "fitImage" and then update the U-Boot documentation to make obvious the differences between uImages and FIT images. What do you think of that? Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
