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