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