On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> David Gibson wrote:
> > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
> >> Currently zImage is linked at the 4MB base address.
> >> Some platforms (using cuboot, treeboot) need the zImage's
> >> entry point and base address. They place zImage exactly
> >> at the base address it's been linked to. Sometimes 4MB left
> >> at the start of the memory is simply not enough to unpack zImage.
> >> This could happen with initramfs enabled, since the kernel image
> >> packed along with initramfs.cpio could be over 5MB in size.
> >> This patch checks vmlinux image size and links zImage at
> >> the base address that is equal to the unpacked image size
> >> aligned to 4MB boundary. This way zImage base address is 4MB
> >> only if unpacked kernel image size is less then 4MB.
> >
> > Good plan. However..
> >
> > [snip]
> >> diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S
> >> linux-2.6/arch/powerpc/boot/zImage.lds.S
> >> --- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 2007-09-22
> >> 00:48:08.000000000 +0400
> >> +++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22
> >> 04:03:58.000000000 +0400
> >> @@ -3,7 +3,7 @@
> >> EXTERN(_zimage_start)
> >> SECTIONS
> >> {
> >> - . = (4*1024*1024);
> >> + . = ALIGN((_kend - _kstart), (4*1024*1024));
> >
> > ..I don't see any reason to keep the 4MB granularity. I would just
> > align the address to say a 64k boundary (64k because that's the
> > granularity used in the normal ABI).
>
> Looking deeper at this I've found that currently u-boot thinks that
> memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> defined as (8 << 20)), although all physical memory is identity mapped.
> That's why it puts command line and board info structure as high as
> possible within the first 8MB. This worked fine with uImage, since
> u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> (we need space at the start of the memory to eventually put vmlinux
> image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> workaround for that is to always link zImage at >=8MB base or to have
> 4MB granularity like this:
>
> + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
>
> Reserve at least 64K for u-boot cmd_line and bdinfo.
Ah. Right. That makes things a bit tricky. Even this 4MB
granularity may not be enough (say, if the vmlinux is < 4MB, but the
zImage has a really big initrd and is > 4MB).
Except... it shouldn't really be the link address that matters. The
zImage is relocatable, so it should only be the load address specified
in the uImage header which matters. I think that's currently derived
from the link address, but it doesn't have to be.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
