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

[Mark A. Greer]

On Fri, Mar 16, 2007 at 11:50:16AM +1100, David Gibson wrote:
> On Thu, Mar 15, 2007 at 05:47:17PM -0700, Mark A. Greer wrote:
> > On Fri, Mar 16, 2007 at 11:18:19AM +1100, David Gibson wrote:
> > > On Thu, Mar 15, 2007 at 04:02:30PM -0700, Mark A. Greer wrote:
> > > > On Mon, Mar 05, 2007 at 02:24:52PM +1100, David Gibson wrote:
> > > > > In addition the wrapper script is rearranged to ensure that the
> > > > > platform .o is always linked first.  This means that platforms where
> > > > > the zImage entry point is at a fixed address or offset, rather than
> > > > > being encoded in the binary header can be supported using option (1).
> > > > 
> > > > But now you don't have a fixed address for _zimage_start when you use
> > > > option 2).  I don't know what address _zimage_start is at so I can't
> > > > start it.  This is an issue for fw's that don't understand ELF and simply
> > > > download a bucket of bits.  You have to tell the fw where to jump to
> > > > (e.g., go 0x410010).
> > > 
> > > The patch already includes an example that deals with this case,
> > > uImage.  The wrapper script pulls the ELF entry point information out
> > > using objdump and puts it into uboot's structure.
> > 
> > Sure, you're putting the addr into a struct in the uimage that u-boot
> > knows enough to get.
> > 
> > 'u-boot' == smart
> > 'my firmware' == dumb
> > 
> > I'm talking about a fw that knows *nothing* about what its downloading/
> > running--its just a bucket of bits/instructions.  It doesn't get an address
> > out of the image.  It has to be told explicitly where to download the image
> > to and where to jump to.  As in, by someone sitting at the console who went
> > and dug out the start addr.  Or, more likely with a prestored jump cmd that
> > someone figured out the right address for and stored.  But, when the start
> > addr changes, suddenly it won't boot and someone has to figure out why,
> > find the the new start addr, modify the prestored cmd(s), and its good
> > until the next time the start addr changes.
> 
> Sorry, I misunderstood.  That sort of firmware - and the even dumber
> sort where the start address isn't configurable at all - is exactly
> what option (1) is for.  You'll need an asm platform file which
> defines _zimage_start to a fixed offset.  In your case you could
> probably just make it a jump to the generic _zimage_start.

Arg, I was afraid you were going to say that.  What I don't like is that
I'll simply duplicate the functionality of crt0.S verbatim just so I know
where the start addr is.  It really has nothing to do with crt0.S and
everything to do with the link order.

/me still thinks there's a better way.

<rant>
Actually, I like it less than I'm letting on.  Basically, you changed
something that has existed for a long time and worked fine for everyone.
In the process, my stuff and others were broken.  All of this to support
an option that there are no users of yet (AFAIK).  I think this needs to
go back to the old link order and/or a better solution found.
</rant>

Mark