邮件列表摘抄

原地址：http://lists.denx.de/pipermail/u-boot/2007-March/020043.html

Hello,

the make target "uImage" in the linux kernel calls mkimage as follows:

     $(MKIMAGE) -A arm -O linux -T kernel \
     -C none -a $(ZRELADDR) -e $(ZRELADDR) \
     -n 'Linux-$(KERNELRELEASE)' -d $< $@

(see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/boot/Makefile;h=ec9c400c7f82d171ba9ccf6e52cdb055bf1a50cb;hb=HEAD,
line 63)

i.e. sets the load address and the entry point to the same address.

This part is unchanged since it was introduced in 2003.


If I understand do_bootm and do_bootm_linux (for arm, in
lib_arm/armlinux.c) correctly, the first asserts that the image is
loaded to the load address[1] and the latter jumps to entry point.

For an image created with the above rule from the vanilla kernel, that
means, jump to the header (instead of the actual image at entry point +
0x40).

So I think the linux rule is wrong, or did I miss anything?

The U-Boot I have on my target here has somewhere after the crc check in
do_bootm the following:

        hdr->ih_load = htonl(addr);
        hdr->ih_ep = htonl(addr + 0x40);

(Actually it's still worse, load_addr instead of addr is used ...)
This works but is ugly.

I wonder how other people using U-Boot + Linux on ARM handle that.

Best regards
Uwe

PS: Linux uses entry point == load address == 0 for PowerPC.  Didn't
look in the PowerPC version of bootm_linux, but maybe it has the same
problem?

[1] For Linux this is not needed, because the decompressor (at least for
2.6) is position independant.  But that's another topic.
--
Uwe Kleine-König

http://www.google.com/search?q=1+stone%3D

In message <20070315155550.GA7760 at lala> you wrote:
>
> the make target "uImage" in the linux kernel calls mkimage as follows:
...
> i.e. sets the load address and the entry point to the same address.

This may, or may not be ok.

> If I understand do_bootm and do_bootm_linux (for arm, in
> lib_arm/armlinux.c) correctly, the first asserts that the image is
> loaded to the load address[1] and the latter jumps to entry point.

You download the image  to  an  arbitrary  address  which  should  be
sufficiently  out  of  the  way  of  the [load_addr,load_addr+size of
uncompressed kernel] area. The bootm will  (uncompress  &)  copy  the
image to the load_addr, and jumpt to the entry point.

> For an image created with the above rule from the vanilla kernel, that
> means, jump to the header (instead of the actual image at entry point +
> 0x40).

No. The header will not be copied by U-Boot's "bootm" command.

> So I think the linux rule is wrong, or did I miss anything?

Yes. You talk about two addresses, but there are three.

> PS: Linux uses entry point == load address == 0 for PowerPC.  Didn't
> look in the PowerPC version of bootm_linux, but maybe it has the same
> problem?

It works the same in this respect. Note that I write *it works*.

> [1] For Linux this is not needed, because the decompressor (at least for
> 2.6) is position independant.  But that's another topic.

Right - the decompressor  itself  is  not  needed,  as  it's  already
included  in U-Boot. Adding it to the Kernel image just wastes memroy
and time as it makes booting slower.

Best regards,

Wolfgang Denk

Hello Wolfgang,

> You download the image  to  an  arbitrary  address  which  should  be
> sufficiently  out  of  the  way  of  the [load_addr,load_addr+size of
> uncompressed kernel] area. The bootm will  (uncompress  &)  copy  the
> image to the load_addr, and jumpt to the entry point.
With the above command line (i.e. -C none) it will only copy it, not
uncompress.  But probably you meant that, as you put uncompress in
parenthesis.

> > For an image created with the above rule from the vanilla kernel, that
> > means, jump to the header (instead of the actual image at entry point +
> > 0x40).
>
> No. The header will not be copied by U-Boot's "bootm" command.
Ah, OK, I see.  Then you may want to take the patch I'll send as a
follow up.
 
> > So I think the linux rule is wrong, or did I miss anything?
>
> Yes. You talk about two addresses, but there are three.
>
> > PS: Linux uses entry point == load address == 0 for PowerPC.  Didn't
> > look in the PowerPC version of bootm_linux, but maybe it has the same
> > problem?
>
> It works the same in this respect. Note that I write *it works*.
>
> > [1] For Linux this is not needed, because the decompressor (at least for
> > 2.6) is position independant.  But that's another topic.
>
> Right - the decompressor  itself  is  not  needed,  as  it's  already
> included  in U-Boot. Adding it to the Kernel image just wastes memroy
> and time as it makes booting slower.
So you suggest to gzip the vmlinux image and use -C gzip?
 
Best regards,
Uwe

In message <20070315211340.GA27920 at informatik.uni-freiburg.de> you wrote:
>
> > uncompressed kernel] area. The bootm will  (uncompress  &)  copy  the
> > image to the load_addr, and jumpt to the entry point.
> With the above command line (i.e. -C none) it will only copy it, not
> uncompress.  But probably you meant that, as you put uncompress in
> parenthesis.

Indeed.

> > Right - the decompressor  itself  is  not  needed,  as  it's  already
> > included  in U-Boot. Adding it to the Kernel image just wastes memroy
> > and time as it makes booting slower.
> So you suggest to gzip the vmlinux image and use -C gzip?

Right. That's what we do here on all architectures, including ARM.

Best regards,

Wolfgang Denk