On Tue, 24 Aug 2010, Dave Martin wrote:
> Hi,
>
> On Mon, Aug 23, 2010 at 11:20 PM, Loïc Minier <loic.min...@linaro.org> wrote:
>
> [...]
>
> >
> > a kernel build most commonly outputs a zImage; this is then converted
> > to an uImage for u-boot consumption with some rune like:
> > mkimage -A arm -O linux -T kernel -C none \
> > -a 0x80008000 -e 0x80008000 -n Linux \
> > -d vmlinuz-2.6.35-1001-omap \
> > uImage-linaro
>
> 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.
I think this is a flaw with U-Boot's image format. We've introduced in
the last merge window the ability for zImage to be completely position
independent. But the U-Boot's mkimage tool still insists on a load
address to be part of the uImage itself instead of having the
possibility to only decide at load time where to load the image.
But until now, the kernel zImage had to encode at least the address of
the decompressed kernel which is related to the physical RAM offset.
And physical RAM offset is also related to the address used by mkimage.
So for the time being, there is little point not building the uImage at
kernel build time because if you need a different address passed to
mkimage then you still (at the moment) need a different kernel image
anyway.
Right now we can have a single kernel binary that can boot on multiple
boards if they're using the same SOC family. That also means that they
are using the same load address with mkimage. Otherwise you need a
different kernel binary already. So if a given kernel is always going
to be booted by U-Boot, then the uImage format can as well be built
with the kernel "make uImage" target right away.
Nicolas
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
