[RFC 3/3] zImage: Exception vector support

David Gibson david at gibson.dropbear.id.au
Wed Feb 21 11:16:23 EST 2007


On Tue, Feb 20, 2007 at 07:44:25AM -0800, Geoff Levand wrote:
> Geoff Levand wrote:
> > David Gibson wrote:
> >> On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:
> >>> Add SMP exception vector support to the powerpc zImage bootwrapper.  For
> >>> platforms which have entry points in the vector table.  This implements
> >>> SMP entry via the system reset vector.
> >> 
> >> I really don't like having always-included code take over the absolute
> >> start of the zImage's address space.  The whole idea in my entry
> >> cleanup patch is that the platform code gets control of the "head.S"
> >> area, so we can potentially support platforms with conflicting
> >> hard-wired requirements for things at specific offsets.
> >> 
> >> I think this belongs in a ps3.o, which will define _zimage_start to be
> >> identical to the reset vector.
> >> 
> > 
> > I need two entry points, one for the first stage loader (0x100), and one
> > for a second stage kexec loader (_zimage_start).

Ok, in that case you can have a separate _zimage_start from the reset
vector.

> Sorry, I should have been more clear.  This is what I have in the wrapper.
> My intension was that head.S is only used for platforms that need it.
> 
> +ps3)
> +    platformo="$object/head.o $object/ps3-hvcall.o $object/ps3.o"
> +    ;;
> 
> Having those vectors makes a 4MB dead gap in the binary image.  The ps3's
> loader supports a gziped image so there is no problem, but for the general
> case of binary images, there is no way we can have those always in there.

Ah, ok, that's reasonable.  However, for the time being, PS3 is the
only platform that needs this.  I think it would be better to do this
as a PS3 specific wrapper initially.  Later, if we get other platforms
that need a reset vector we can see what's really common and
consolidate it.

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