[PATCH 8/15] zImage: Cleanup and improve zImage entry point

David Gibson david at gibson.dropbear.id.au
Fri Mar 16 12:50:23 EST 2007


On Thu, Mar 15, 2007 at 06:01:16PM -0700, Mark A. Greer wrote:
> On Fri, Mar 16, 2007 at 11:14:30AM +1100, David Gibson wrote:
> > On Thu, Mar 15, 2007 at 03:35:29PM -0700, Mark A. Greer wrote:
> 
> <snip>
> 
> > > On Mon, Mar 05, 2007 at 02:24:52PM +1100, David Gibson wrote:
> > > Statically initializing _platform_stack_top (or any variable) won't
> > > work when you download/run the zImage at a location different than
> > > where its linked at.  Yes, I know the image is "relocatable" but that
> > > doesn't work for addresses put into variables/structs at link time
> > > like this one.  That type of assignment has to be done at runtime.
> > > 
> > > What happens is the linker puts 0x0040_1234, say, into
> > > _platform_stack_top but when you download the image to 0x0080_0000
> > > it still has a value of 0x0040_1234 even though its running at
> > > 0x00800_0000+.
> > 
> > Ah, good point.  In this case we should be able to fix this by having
> > crt0.S relocate the pointer before loading it into r1, yes, in the
> > same way it relocates the GOT entries?
> >
> > Incidentally I would have preferred not to store the stack address in
> > a variable, but just generated a symbol for the stack top and loaded
> > that directly in crt0.S.  But I couldn't think of a way in the C macro
> > to generate the necesary symbol at the end of the stack.
> 
> What about something like this:
> 
> #define BSS_STACK(size) \
> 	static char _bss_stack[size]; \
> 	u32 _platform_stack_size = size;
> 
> Then in crt0.S add value of _platform_stack_size to _bss_stack to get r1?
> That should relocate correctly.

That sounds reasonable, though it's slightly more involved that the
current code.  I'm wrangling another stack of bootloader patches at
the moment, you want to send something to implement this?

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



More information about the Linuxppc-dev mailing list