Re: [RFC 3/3] zImage: Exception vector support

[Geoff Levand <geoffrey.levand@am.sony.com>]

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

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.

Regarding these two entry points, the plan is for the kernel in flash memory
(first stage) to support kexec so that it has the capability to itself load
and boot a kernel (second stage) from any source the kernel + initrd supports;
net, removable, USB, HDD, etc.  So the first stage kernel can act as a
second stage loader.  This second stage loader will take an ELF image, as it
is most convenient.  The vectors will be in the ELF file in their own
small section (.vectors), but won't be used by the second stage loader.

-Geoff