2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) Paul Mackerras 1997.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* NOTE: this code runs in 32 bit mode and is packaged as ELF32.
|
|
|
|
|
*/
|
|
|
|
|
|
2005-08-08 11:24:38 +08:00
|
|
|
#include "ppc_asm.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
.text
|
2006-01-14 12:04:06 +08:00
|
|
|
/* a procedure descriptor used when booting this as a COFF file */
|
|
|
|
|
_zimage_start_opd:
|
|
|
|
|
.long _zimage_start, 0, 0, 0
|
|
|
|
|
|
[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>
2007-03-05 11:24:52 +08:00
|
|
|
.weak _zimage_start
|
2005-10-29 08:46:49 +08:00
|
|
|
.globl _zimage_start
|
|
|
|
|
_zimage_start:
|
2007-03-21 23:02:53 +08:00
|
|
|
.globl _zimage_start_lib
|
|
|
|
|
_zimage_start_lib:
|
2006-01-14 12:04:06 +08:00
|
|
|
/* Work out the offset between the address we were linked at
|
|
|
|
|
and the address where we're running. */
|
2005-11-18 05:09:02 +08:00
|
|
|
bl 1f
|
2006-01-14 12:04:06 +08:00
|
|
|
1: mflr r0
|
2005-11-18 05:09:02 +08:00
|
|
|
lis r9,1b@ha
|
|
|
|
|
addi r9,r9,1b@l
|
2005-10-29 08:46:48 +08:00
|
|
|
subf. r0,r9,r0
|
2006-01-14 12:04:06 +08:00
|
|
|
beq 3f /* if running at same address as linked */
|
2005-10-29 08:46:48 +08:00
|
|
|
|
2006-01-14 12:04:06 +08:00
|
|
|
/* The .got2 section contains a list of addresses, so add
|
|
|
|
|
the address offset onto each entry. */
|
2005-10-29 08:46:48 +08:00
|
|
|
lis r9,__got2_start@ha
|
|
|
|
|
addi r9,r9,__got2_start@l
|
|
|
|
|
lis r8,__got2_end@ha
|
|
|
|
|
addi r8,r8,__got2_end@l
|
|
|
|
|
subf. r8,r9,r8
|
2005-11-18 05:09:02 +08:00
|
|
|
beq 3f
|
2005-10-29 08:46:48 +08:00
|
|
|
srwi. r8,r8,2
|
|
|
|
|
mtctr r8
|
|
|
|
|
add r9,r0,r9
|
2006-01-14 12:04:06 +08:00
|
|
|
2: lwz r8,0(r9)
|
2005-10-29 08:46:48 +08:00
|
|
|
add r8,r8,r0
|
|
|
|
|
stw r8,0(r9)
|
|
|
|
|
addi r9,r9,4
|
2005-11-18 05:09:02 +08:00
|
|
|
bdnz 2b
|
2005-10-29 08:46:48 +08:00
|
|
|
|
[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>
2007-03-05 11:24:52 +08:00
|
|
|
/* Do a cache flush for our text, in case the loader didn't */
|
2006-03-04 20:15:40 +08:00
|
|
|
3: lis r9,_start@ha
|
|
|
|
|
addi r9,r9,_start@l
|
2005-10-29 08:46:48 +08:00
|
|
|
add r9,r0,r9
|
2005-04-17 06:20:36 +08:00
|
|
|
lis r8,_etext@ha
|
|
|
|
|
addi r8,r8,_etext@l
|
2005-10-29 08:46:48 +08:00
|
|
|
add r8,r0,r8
|
2005-11-18 05:09:02 +08:00
|
|
|
4: dcbf r0,r9
|
2005-04-17 06:20:36 +08:00
|
|
|
icbi r0,r9
|
|
|
|
|
addi r9,r9,0x20
|
2006-03-04 20:15:40 +08:00
|
|
|
cmplw cr0,r9,r8
|
2005-11-18 05:09:02 +08:00
|
|
|
blt 4b
|
2005-04-17 06:20:36 +08:00
|
|
|
sync
|
|
|
|
|
isync
|
|
|
|
|
|
[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>
2007-03-05 11:24:52 +08:00
|
|
|
/* Clear the BSS */
|
|
|
|
|
lis r9,__bss_start@ha
|
|
|
|
|
addi r9,r9,__bss_start@l
|
2007-03-28 16:21:02 +08:00
|
|
|
add r9,r0,r9
|
[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>
2007-03-05 11:24:52 +08:00
|
|
|
lis r8,_end@ha
|
|
|
|
|
addi r8,r8,_end@l
|
2007-03-28 16:21:02 +08:00
|
|
|
add r8,r0,r8
|
|
|
|
|
li r10,0
|
|
|
|
|
5: stw r10,0(r9)
|
[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>
2007-03-05 11:24:52 +08:00
|
|
|
addi r9,r9,4
|
|
|
|
|
cmplw cr0,r9,r8
|
|
|
|
|
blt 5b
|
2005-04-17 06:20:36 +08:00
|
|
|
|
[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>
2007-03-05 11:24:52 +08:00
|
|
|
/* Possibly set up a custom stack */
|
|
|
|
|
.weak _platform_stack_top
|
|
|
|
|
lis r8,_platform_stack_top@ha
|
|
|
|
|
addi r8,r8,_platform_stack_top@l
|
|
|
|
|
cmpwi r8,0
|
|
|
|
|
beq 6f
|
2007-03-28 16:21:02 +08:00
|
|
|
add r8,r0,r8
|
[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>
2007-03-05 11:24:52 +08:00
|
|
|
lwz r1,0(r8)
|
2007-03-28 16:21:02 +08:00
|
|
|
add r1,r0,r1
|
[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>
2007-03-05 11:24:52 +08:00
|
|
|
li r0,0
|
|
|
|
|
stwu r0,-16(r1) /* establish a stack frame */
|
|
|
|
|
6:
|
|
|
|
|
|
|
|
|
|
/* Call platform_init() */
|
|
|
|
|
bl platform_init
|
|
|
|
|
|
|
|
|
|
/* Call start */
|
|
|
|
|
b start
|