]> www.pilppa.org Git - linux-2.6-omap-h63xx.git/commit
[POWERPC] zImage: Cleanup and improve zImage entry point
authorDavid Gibson <david@gibson.dropbear.id.au>
Mon, 5 Mar 2007 03:24:52 +0000 (14:24 +1100)
committerPaul Mackerras <paulus@samba.org>
Tue, 13 Mar 2007 02:35:03 +0000 (13:35 +1100)
commitcd197ffcf10bcc1a260efe5c09a3188fd9228c83
tree280d1c3026b263fbdb95961ae77efb79739e8daf
parent79c8541924a220964f9f2cbed31eaa9fdb042eab
[POWERPC] zImage: Cleanup and improve zImage entry point

This patch re-organises the way the zImage wrapper code is entered, to
allow more flexibility on platforms with unusual entry conditions.
After this patch, a platform .o file has two options:

1) It can define a _zimage_start, in which case the platform code gets
   control from the very beginning of execution.  In this case the
   platform code is responsible for relocating the zImage if necessary,
   clearing the BSS, performing any platform specific initialization, and
   finally calling start() to load and enter the kernel.

2) It can define platform_init().  In this case the generic crt0.S
   handles initial entry, and calls platform_init() before calling
   start().  The signature of platform_init() is changed, however, to
   take up to 5 parameters (in r3..r7) as they come from the platform's
   initial loader, instead of a fixed set of parameters based on OF's
   usage.

   When using the generic crt0.S, the platform .o can optionally
   supply a custom stack to use, using the BSS_STACK() macro.  If this
   is not supplied, the crt0.S will assume that the loader has
   supplied a usable stack.

In either case, the platform code communicates information to the
generic code (specifically, a PROM pointer for OF systems, and/or an
initrd image address supplied by the bootloader) via a global
structure "loader_info".

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

Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
arch/powerpc/boot/Makefile
arch/powerpc/boot/crt0.S
arch/powerpc/boot/main.c
arch/powerpc/boot/of.c
arch/powerpc/boot/ops.h
arch/powerpc/boot/wrapper
arch/powerpc/boot/zImage.coff.lds.S
arch/powerpc/boot/zImage.lds.S