PowerPC: add more than 4MB kernel image size support to bootwarapper

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.

arch/powerpc/boot/zImage.lds.S +0 -0

   _start = .;
   .text      :
   {

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Quoted 11 lines · 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.

Good plan. However..

[snip]

arch/powerpc/boot/zImage.lds.S line 6

Quoted 9 lines

diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S linux-2.6/arch/powerpc/boot/zImage.lds.S

arch/powerpc/boot/zImage.lds.S +1 -1

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

Quoted 9 lines

arch/powerpc/boot/zImage.lds.S +0 -0

   _start = .;
   .text      :
   {

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Quoted 16 lines · David Gibson

Quoted 11 lines · 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.

Good plan. However..

[snip]

Quoted 13 lines

arch/powerpc/boot/zImage.lds.S line 6

Quoted 9 lines

diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S linux-2.6/arch/powerpc/boot/zImage.lds.S

arch/powerpc/boot/zImage.lds.S +1 -1

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

Quoted 15 lines · Valentine Barshak

Quoted 1 line · David Gibson

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:

Quoted 3 lines

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

Quoted 24 lines · David Gibson

Quoted 15 lines · Valentine Barshak

Quoted 1 line · David Gibson

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:

Quoted 3 lines

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

Quoted 4 lines

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.

Quoted 30 lines · Mark A. Greer

Quoted 28 lines · David Gibson

Quoted 15 lines · Valentine Barshak

Quoted 1 line · David Gibson

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:

Quoted 3 lines

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

Quoted 2 lines

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.

Quoted 29 lines

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

Quoted 1 line

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.

Quoted 2 lines · David Gibson

The zImage is already hardware and
firmware specific;

And [potentially] firmware version and zImage size specific.

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.

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

Quoted 4 lines · Mark A. Greer

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.

Quoted 3 lines

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?

Quoted 3 lines

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.

Quoted 8 lines

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

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.

Quoted 4 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 4 lines · Mark A. Greer

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.

Quoted 2 lines

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.

Quoted 7 lines

Quoted 4 lines

Quoted 3 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 3 lines

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.