Common data for uImage generation

Nicolas Pitre nicolas.pitre at linaro.org
Tue Aug 24 19:59:15 BST 2010


On Tue, 24 Aug 2010, Dave Martin wrote:

> Hi,
> 
> On Mon, Aug 23, 2010 at 11:20 PM, Loïc Minier <loic.minier at 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


More information about the Linaro-dev mailing list