Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
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 ___ 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
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 ___ 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
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 ___ 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
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 ___ 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
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 ___ 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
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 ___ 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
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 ___ 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
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 ___ 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
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.0 +0400
+++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22
04:03:58.0 +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
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
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.S2007-09-22
00:48:08.0 +0400
+++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.0
+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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] [PATCH] 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.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
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/wrapper2007-09-22 00:48:08.0
+0400
+++ linux-2.6/arch/powerpc/boot/wrapper 2007-09-22 04:03:40.0 +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.0 +0400
+++ linux-2.6/arch/powerpc/boot/zImage.lds.S2007-09-22 04:03:58.0
+0400
@@ -3,7 +3,7 @@
EXTERN(_zimage_start)
SECTIONS
{
- . = (4*1024*1024);
+ . = ALIGN((_kend - _kstart), (4*1024*1024));
_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
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.0 +0400
+++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.0
+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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
