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

Mark A. Greer mgreer at mvista.com
Fri Mar 16 11:47:17 EST 2007


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.

We need something better than that.

Mark



More information about the Linuxppc-dev mailing list