On Tue, 24 Aug 2010, Loïc Minier wrote:
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.
This could have been me, or if it wasn't me then I would have strongly approved. I even posted some notes about the de facto header that is found at the front of the zImage binary (that was many years ago and therefore I can't find an archive link right now):
Offset into zImage Value Description 0x24 0x016F2818 Magic number used to identify this is an ARM Linux zImage 0x28 start address The address the zImage starts at 0x2C end address The address the zImage ends at
The start and end offsets can be used to validate the length of the provided zImage (size = end - start).
The zImage code is (in most cases) Position Independent Code (PIC) so may be loaded anywhere within the available address space. The start address in that case is zero.
If U-Boot really insists on its uImage format in flash, then I really think that the mkimage functionality could be made into U-Boot itself.
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.
Like I said though, if all of OMAP3 can share the same kernel image, the corresponding uImage is likely to be identical too.
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?
No. The initrd load address has to be passed to the kernel and that should remain that way so to preserve flexibility in its placement. The zImage can be loaded anywhere -- it is just mkimage that insists on a load address (and that's a problem with U-Boot not 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.
It would be great if we agreed that U-Boot should be able to cope with zImage directly. Adding the necessary support to U-Boot is trivial.
Nicolas