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

Mark A. Greer mgreer at mvista.com
Fri Mar 16 14:36:49 EST 2007


On Fri, Mar 16, 2007 at 12:50:23PM +1100, David Gibson wrote:
> 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?

Sure.  I want to get my current stack of patches working on top of yours
& Scott's first then I'll make a patch for this (I've just hacked around
this issue for now).  Stay tuned.

Mark



More information about the Linuxppc-dev mailing list