On Tue, Aug 24, 2010, Dave Martin wrote: > Couldn't we simply use the kernel tree "make uImage" rule, and put the > uImage in the kernel binary packages, rather than reduplicating this > elsewhere? Of course, which kernel tree targets to build may then > become board-specific, which might be seen as a disadvantage.
ISTR someone commented upstream a long time ago that the uImage target was clutter and that u-boot should learn to cope with zImage as other bootloaders do. Problem with the uImage target is that we want different uImages built from the same kernel flavours, and it's not really worth having one binary kernel package per board, it's nicer to have a single binary kernel package for e.g. all of omap3 and convert the zImage to what's needed for a specific board at package installation time. What might make sense is keeping the data in the kernel though: certainly the uImage and uInitrd load addresses are best kept within the kernel? > I've tended to treat the kernel tree rule as the canonical way of > generating a valid uImage, though maybe not everyone will agree with > that. It would probably be valid for daily kernel builds; but it's only one of the use cases; any boot media generation (e.g. linaro-media-create or live-helper, or debian-cd, or debian-installer) couldn't use that, and it doesn't make sense for the flash-kernel use case either. There even are some platforms which support both zImage and uImage (e.g. imx51/redboot and imx51/u-boot), albeit Linaro isn't too interested in these the plan needs to support them if we want it to go in distros. -- Loïc Minier _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
