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

David Gibson david at gibson.dropbear.id.au
Fri Mar 16 11:14:30 EST 2007


On Thu, Mar 15, 2007 at 03:35:29PM -0700, Mark A. Greer wrote:
> On Mon, Mar 05, 2007 at 02:24:52PM +1100, David Gibson wrote:
> 
> Hi David,
> 
> <snip>
> 
> > Index: working-2.6/arch/powerpc/boot/ops.h
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/boot/ops.h	2007-02-19 14:01:38.000000000 +1100
> > +++ working-2.6/arch/powerpc/boot/ops.h	2007-02-19 14:01:43.000000000 +1100
> 
> <snip>
> 
> > @@ -100,4 +106,8 @@ static inline void exit(void)
> >  	for(;;);
> >  }
> >  
> > +#define BSS_STACK(size) \
> > +	static char _bss_stack[size]; \
> > +	void *_platform_stack_top = _bss_stack + sizeof(_bss_stack);
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> >  #endif /* _PPC_BOOT_OPS_H_ */
> 
> 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.

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