[RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Valentine Barshak]

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.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 arch/powerpc/boot/wrapper      |    6 ++++--
 arch/powerpc/boot/zImage.lds.S |    2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff -ruN linux-2.6.orig/arch/powerpc/boot/wrapper linux-2.6/arch/powerpc/boot/wrapper
--- linux-2.6.orig/arch/powerpc/boot/wrapper	2007-09-22 00:48:08.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/wrapper	2007-09-22 04:03:40.000000000 +0400
@@ -215,8 +215,10 @@
 fi
 
 if [ "$platform" != "miboot" ]; then
-    ${CROSS}ld -m elf32ppc -T $lds -o "$ofile" \
-	$platformo $tmp $object/wrapper.a
+    kstart=0x`${CROSS}nm "$kernel" | grep ' _start$' | cut -d' ' -f1`
+    kend=0x`${CROSS}nm "$kernel" | grep ' _end$' | cut -d' ' -f1`
+    ${CROSS}ld -m elf32ppc --defsym _kstart=$kstart --defsym _kend=$kend \
+	-T $lds -o "$ofile" $platformo $tmp $object/wrapper.a
     rm $tmp
 fi
 
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));
   _start = .;
   .text      :
   {

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[David Gibson]

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).

>    _start = .;
>    .text      :
>    {
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

-- 
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

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Valentine Barshak]

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.
Thanks,
Valentine.

> 
>>    _start = .;
>>    .text      :
>>    {
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
> 

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[David Gibson]

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

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Mark A. Greer]

On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> 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:

> > 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.

Having the link address jump around depending on the size of the kernel
or zImage is wrong IMHO.  It just screams "weird can't boot issues."
We need a way to specify exactly where we want the zImage linked no
matter what the kernel or zImage size.

Also, being able to control the link address (that is, the download
address with some firmwares) is not a u-boot specific issue and we
shouldn't make a u-boot specific solution.

The more general problem is that some firmwares examine the ELF header
and download the zImage to address it was linked at.  Some firmwares let
you override this but some don't and those are the problem ones.

We talked about this a bit back in February,
http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html

In that thread Geoff Levand suggested a config option and running it
thru a preprocessor.  David Gibson suggested making a replaceable linker
script.  I suggested passing the value of a config option to the wrapper
script which would use objcopy/whatever to change the section addresses
in the image (maybe this is what Geoff had in mind, I'm not sure).

I still like my idea best.  I haven't coded yet it so I don't have a patch
but this is what I mean:

1) add a config option (default 4MB) for the link address
2) add a parameter to the wrapper script thru which we pass the value in
   the config option
3) the wrapper script changes the VMA/LMA to the address specified
   (objcopy --change-addresses=<some math to get correct incr> ?).

I'll code it up in the next day or two unless someone doesn't like the idea.

Mark

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[David Gibson]

On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> > 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:
> 
> > > 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.
> 
> Having the link address jump around depending on the size of the kernel
> or zImage is wrong IMHO.  It just screams "weird can't boot issues."

Hrm.  Except we already have that - the zImage is linked at a fixed
location, and will just not work if the sizes are wrong.

> We need a way to specify exactly where we want the zImage linked no
> matter what the kernel or zImage size.
> 
> Also, being able to control the link address (that is, the download
> address with some firmwares) is not a u-boot specific issue and we
> shouldn't make a u-boot specific solution.
> 
> The more general problem is that some firmwares examine the ELF header
> and download the zImage to address it was linked at.  Some firmwares let
> you override this but some don't and those are the problem ones.
> 
> We talked about this a bit back in February,
> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
> 
> In that thread Geoff Levand suggested a config option and running it
> thru a preprocessor.  David Gibson suggested making a replaceable linker
> script.  I suggested passing the value of a config option to the wrapper
> script which would use objcopy/whatever to change the section addresses
> in the image (maybe this is what Geoff had in mind, I'm not sure).
> 
> I still like my idea best.  I haven't coded yet it so I don't have a patch
> but this is what I mean:
> 
> 1) add a config option (default 4MB) for the link address
> 2) add a parameter to the wrapper script thru which we pass the value in
>    the config option
> 3) the wrapper script changes the VMA/LMA to the address specified
>    (objcopy --change-addresses=<some math to get correct incr> ?).
> 
> I'll code it up in the next day or two unless someone doesn't like the idea.

A config option just doesn't seem right to me, except as a
special-circumstances hack.  The zImage is already hardware and
firmware specific; we should be able to figure out workable link and
load addresses for a specific zImage (which might need to be different
for different zImages produced by the same config).

Of course, the same objection would apply to CONFIG_DEVICE_TREE which
we have already.

-- 
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

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Mark A. Greer]

On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote:
> On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> > On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote:
> > > 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:
> > 
> > > > 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.
> > 
> > Having the link address jump around depending on the size of the kernel
> > or zImage is wrong IMHO.  It just screams "weird can't boot issues."
> 
> Hrm.  Except we already have that - the zImage is linked at a fixed
> location, and will just not work if the sizes are wrong.

Yes, its an issue now (which is why we're having this discussion) but
at least its predictable ATM.  Having it jump around on you because
you happened to set/clear a CONFIG option is worse.

My point is that the address needs to be set manually--no fancy heuristics
or whatever to guess.

> > We need a way to specify exactly where we want the zImage linked no
> > matter what the kernel or zImage size.
> > 
> > Also, being able to control the link address (that is, the download
> > address with some firmwares) is not a u-boot specific issue and we
> > shouldn't make a u-boot specific solution.
> > 
> > The more general problem is that some firmwares examine the ELF header
> > and download the zImage to address it was linked at.  Some firmwares let
> > you override this but some don't and those are the problem ones.
> > 
> > We talked about this a bit back in February,
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html
> > 
> > In that thread Geoff Levand suggested a config option and running it
> > thru a preprocessor.  David Gibson suggested making a replaceable linker
> > script.  I suggested passing the value of a config option to the wrapper
> > script which would use objcopy/whatever to change the section addresses
> > in the image (maybe this is what Geoff had in mind, I'm not sure).
> > 
> > I still like my idea best.  I haven't coded yet it so I don't have a patch
> > but this is what I mean:
> > 
> > 1) add a config option (default 4MB) for the link address
> > 2) add a parameter to the wrapper script thru which we pass the value in
> >    the config option
> > 3) the wrapper script changes the VMA/LMA to the address specified
> >    (objcopy --change-addresses=<some math to get correct incr> ?).
> > 
> > I'll code it up in the next day or two unless someone doesn't like the idea.
> 
> A config option just doesn't seem right to me, except as a
> special-circumstances hack.

Acutally, I started to hack up the patch and noticed that its already
there.  Its 'CONFIG_BOOT_LOAD' which is an "Advanced setup" option
in arch/powerpc/Kconfig (probably migrated from arch/ppc/Kconfig).
Several defconfig's have it set but its not used AFAICS.

> The zImage is already hardware and
> firmware specific;

And [potentially] firmware version and zImage size specific.

> we should be able to figure out workable link and
> load addresses for a specific zImage

I was going to argue with you here until...

> (which might need to be different
> for different zImages produced by the same config).

Oh yeah, I forgot about multiple zImages from the same config.  D*mn.
Hmm, I guess I have to think about this more then.  (and stop hacking up
the patch I was talking about).

> Of course, the same objection would apply to CONFIG_DEVICE_TREE which
> we have already.

Yep.

Mark

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Mark A. Greer]

On Thu, Oct 04, 2007 at 07:59:30PM -0700, Mark A. Greer wrote:
> On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote:

> > The zImage is already hardware and
> > firmware specific;
> 
> And [potentially] firmware version and zImage size specific.

I meant to add, "which is why it'll be difficult to come up with a
heuristic that will work in all situations."

Mark

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Scott Wood]

On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> Having the link address jump around depending on the size of the kernel
> or zImage is wrong IMHO.  It just screams "weird can't boot issues."
> We need a way to specify exactly where we want the zImage linked no
> matter what the kernel or zImage size.

Why?  The zImage is relocatable.  It doesn't matter where it's linked.

> Also, being able to control the link address (that is, the download
> address with some firmwares) is not a u-boot specific issue and we
> shouldn't make a u-boot specific solution.

How is this a u-boot specific solution?

> The more general problem is that some firmwares examine the ELF header
> and download the zImage to address it was linked at.  Some firmwares let
> you override this but some don't and those are the problem ones.

That's not the more general problem; it's the same problem with a different
file format.

> I still like my idea best.  I haven't coded yet it so I don't have a patch
> but this is what I mean:
> 
> 1) add a config option (default 4MB) for the link address
> 2) add a parameter to the wrapper script thru which we pass the value in
>    the config option
> 3) the wrapper script changes the VMA/LMA to the address specified
>    (objcopy --change-addresses=<some math to get correct incr> ?).

I'd much rather it be automatic than require the user to guess an
appropriate value (and be aware in the first place that it needs to be set).

-Scott

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Mark A. Greer]

On Fri, Oct 05, 2007 at 12:30:54PM -0500, Scott Wood wrote:
> On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote:
> > Having the link address jump around depending on the size of the kernel
> > or zImage is wrong IMHO.  It just screams "weird can't boot issues."
> > We need a way to specify exactly where we want the zImage linked no
> > matter what the kernel or zImage size.
> 
> Why?

Why?  Because its only safe to download a zImage to certain "safe" locations.
Where those "safe" locations are vary by firmware, firmware version, and
zImage size.  This is the issue we're discussing.

I've already explained _why_ the link address matters WRT where its downloaded.

> The zImage is relocatable.  It doesn't matter where it's linked.

We know...and a zImage running at an address it wasn't linked at is
not the issue.

> > Also, being able to control the link address (that is, the download
> > address with some firmwares) is not a u-boot specific issue and we
> > shouldn't make a u-boot specific solution.
> 
> How is this a u-boot specific solution?

Because the hoops being jumped through in the patch(es) are to make
u-boot happy and no other firmware.

> > The more general problem is that some firmwares examine the ELF header
> > and download the zImage to address it was linked at.  Some firmwares let
> > you override this but some don't and those are the problem ones.
> 
> That's not the more general problem; it's the same problem with a different
> file format.

True, I misspoke.  I'll restate it this way:

The more general problem is that some firmwares will only download to
the address the zImage is linked at.  So, we need to control what that
link address is."

> > I still like my idea best.  I haven't coded yet it so I don't have a patch
> > but this is what I mean:
> > 
> > 1) add a config option (default 4MB) for the link address
> > 2) add a parameter to the wrapper script thru which we pass the value in
> >    the config option
> > 3) the wrapper script changes the VMA/LMA to the address specified
> >    (objcopy --change-addresses=<some math to get correct incr> ?).
> 
> I'd much rather it be automatic than require the user to guess an
> appropriate value (and be aware in the first place that it needs to be set).

Sure, automatic is nice; conjuring up the magic to make it work in all
situations isn't.

Having the link address--and therefore the download address on some
systems--mysteriously and uncontrollably jump around based on the zImage
size is asking for trouble.

Mark

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Scott Wood]

Mark A. Greer wrote:
> Why?  Because its only safe to download a zImage to certain "safe" locations.
> Where those "safe" locations are vary by firmware, firmware version, and
> zImage size.  This is the issue we're discussing.

In theory, yes -- but in practice the odds of this particular heuristic 
choosing an unsuitable address seem slim.

> I've already explained _why_ the link address matters WRT where its downloaded.

Sorry, I was being a bit too pendantic with respect to the distinction 
between link and load address.

>>> Also, being able to control the link address (that is, the download
>>> address with some firmwares) is not a u-boot specific issue and we
>>> shouldn't make a u-boot specific solution.
>> How is this a u-boot specific solution?
> 
> Because the hoops being jumped through in the patch(es) are to make
> u-boot happy and no other firmware.

No, the "hoops" (which I don't think are sufficiently complicated to 
warrant such a name) are to address a generic issue with the bootwrapper 
-- it wants to put the kernel at zero.  It'd be really nice if, in the 
absense of a vmlinux_alloc method, the generic code would do an ordinary 
malloc() if there's not enough room at zero.

>> I'd much rather it be automatic than require the user to guess an
>> appropriate value (and be aware in the first place that it needs to be set).
> 
> Sure, automatic is nice; conjuring up the magic to make it work in all
> situations isn't.

I think this heuristic would work in most situations, so if we do add a 
manual override it should be an override, and not something that 
everybody has to put up with.

> Having the link address--and therefore the download address on some
> systems--mysteriously and uncontrollably jump around based on the zImage
> size is asking for trouble.

It's a source of potential issues, but I think "asking for trouble" is 
exaggerating somewhat.

-Scott

Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper

[Mark A. Greer]

On Sun, Oct 07, 2007 at 08:31:46PM -0500, Scott Wood wrote:

Sorry for the delay, Scott.

> Mark A. Greer wrote:
> >Why?  Because its only safe to download a zImage to certain "safe" 
> >locations.
> >Where those "safe" locations are vary by firmware, firmware version, and
> >zImage size.  This is the issue we're discussing.
> 
> In theory, yes -- but in practice the odds of this particular heuristic 
> choosing an unsuitable address seem slim.

Yes, it probably will work fairly well for most powerpc 32-bit platforms
since the default in arch/ppc was 8MB (but there was a manual override
that was used by some platforms).  That still doesn't make it safe for
everyone 32-bit or 64-bit.

> >I've already explained _why_ the link address matters WRT where its 
> >downloaded.
> 
> Sorry, I was being a bit too pendantic with respect to the distinction 
> between link and load address.

And I was probably too impatient.  Sorry.

> >>>Also, being able to control the link address (that is, the download
> >>>address with some firmwares) is not a u-boot specific issue and we
> >>>shouldn't make a u-boot specific solution.
> >>How is this a u-boot specific solution?
> >
> >Because the hoops being jumped through in the patch(es) are to make
> >u-boot happy and no other firmware.
> 
> No, the "hoops" (which I don't think are sufficiently complicated to 
> warrant such a name)

Not yet maybe but as exceptions come along
	". = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));"
will become more complicated.

> are to address a generic issue with the bootwrapper 
> -- it wants to put the kernel at zero.  It'd be really nice if, in the 
> absense of a vmlinux_alloc method, the generic code would do an ordinary 
> malloc() if there's not enough room at zero.

Actually, that's a good idea but its only for safety sake.  When you
unpack the kernel at somewhere other than 0, there will be an additional
copy very early during kernel boot to copy itself to address 0.  So, if
we add that feature we should print a warning so the user knows extra
time was spent copying the kernel to 0.  If we can come up with a simple
way to control the link address we can avoid that copy.

> >>I'd much rather it be automatic than require the user to guess an
> >>appropriate value (and be aware in the first place that it needs to be 
> >>set).
> >
> >Sure, automatic is nice; conjuring up the magic to make it work in all
> >situations isn't.
> 
> I think this heuristic would work in most situations, so if we do add a 
> manual override it should be an override, and not something that 
> everybody has to put up with.

Okay, so how about we just leave the default at 4MB and come up with
that manual override??  ;)

> >Having the link address--and therefore the download address on some
> >systems--mysteriously and uncontrollably jump around based on the zImage
> >size is asking for trouble.
> 
> It's a source of potential issues, but I think "asking for trouble" is 
> exaggerating somewhat.

Noted and disagreed with. :)

Mark