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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
