2005-04-17 02:20:36 +04:00
/ *
* Copyright ( C ) P a u l M a c k e r r a s 1 9 9 7 .
*
2014-04-24 11:23:37 +04:00
* Adapted f o r 6 4 b i t L E P o w e r P C b y A n d r e w T a u f e r n e r
*
2005-04-17 02:20:36 +04:00
* This p r o g r a m i s f r e e s o f t w a r e ; you can redistribute it and/or
* modify i t u n d e r t h e t e r m s o f t h e G N U G e n e r a l P u b l i c L i c e n s e
* as p u b l i s h e d b y t h e F r e e S o f t w a r e F o u n d a t i o n ; either version
* 2 of t h e L i c e n s e , o r ( a t y o u r o p t i o n ) a n y l a t e r v e r s i o n .
*
* /
2005-08-08 07:24:38 +04:00
# include " p p c _ a s m . h "
2005-04-17 02:20:36 +04:00
2014-04-24 11:23:37 +04:00
RELA = 7
RELACOUNT = 0 x6 f f f f f f9
2005-04-17 02:20:36 +04:00
.text
2011-04-13 00:38:55 +04:00
/ * A p r o c e d u r e d e s c r i p t o r u s e d w h e n b o o t i n g t h i s a s a C O F F f i l e .
* When m a k i n g C O F F , t h i s c o m e s f i r s t i n t h e l i n k a n d w e ' r e
* linked a t 0 x50 0 0 0 0 .
* /
2007-06-07 16:21:31 +04:00
.globl _zimage_start_opd
2006-01-14 07:04:06 +03:00
_zimage_start_opd :
2011-04-13 00:38:55 +04:00
.long 0 x5 0 0 0 0 0 , 0 , 0 , 0
2014-04-24 11:23:37 +04:00
# ifdef _ _ p o w e r p c64 _ _
.balign 8
p_start : .llong _ s t a r t
p_etext : .llong _ e t e x t
p_bss_start : .llong _ _ b s s _ s t a r t
p_end : .llong _ e n d
p_toc : .llong _ _ t o c _ s t a r t + 0x8000 - p_ b a s e
p_dyn : .llong _ _ d y n a m i c _ s t a r t - p _ b a s e
p_rela : .llong _ _ r e l a _ d y n _ s t a r t - p _ b a s e
p_prom : .llong 0
.weak _platform_stack_top
p_pstack : .llong _ p l a t f o r m _ s t a c k _ t o p
# else
2011-04-13 00:38:55 +04:00
p_start : .long _ s t a r t
p_etext : .long _ e t e x t
p_bss_start : .long _ _ b s s _ s t a r t
p_end : .long _ e n d
.weak _platform_stack_top
p_pstack : .long _ p l a t f o r m _ s t a c k _ t o p
2014-04-24 11:23:37 +04:00
# endif
2006-01-14 07:04:06 +03: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 06:24:52 +03:00
.weak _zimage_start
2005-10-29 04:46:49 +04:00
.globl _zimage_start
_zimage_start :
2007-03-21 18:02:53 +03:00
.globl _zimage_start_lib
_zimage_start_lib :
2006-01-14 07:04:06 +03:00
/ * Work o u t t h e o f f s e t b e t w e e n t h e a d d r e s s w e w e r e l i n k e d a t
and t h e a d d r e s s w h e r e w e ' r e r u n n i n g . * /
2011-04-13 00:38:55 +04:00
bl . + 4
p_base : mflr r10 / * r10 n o w p o i n t s t o r u n t i m e a d d r o f p _ b a s e * /
2014-04-24 11:23:37 +04:00
# ifndef _ _ p o w e r p c64 _ _
2011-04-13 00:38:55 +04:00
/* grab the link address of the dynamic section in r11 */
addis r11 ,r10 ,( _ G L O B A L _ O F F S E T _ T A B L E _ - p _ b a s e ) @ha
lwz r11 ,( _ G L O B A L _ O F F S E T _ T A B L E _ - p _ b a s e ) @l(r11)
cmpwi r11 ,0
beq 3 f / * i f n o t l i n k e d - p i e * /
/* get the runtime address of the dynamic section in r12 */
.weak __dynamic_start
addis r12 ,r10 ,( _ _ d y n a m i c _ s t a r t - p _ b a s e ) @ha
addi r12 ,r12 ,( _ _ d y n a m i c _ s t a r t - p _ b a s e ) @l
subf r11 ,r11 ,r12 / * r u n t i m e - l i n k t i m e o f f s e t * /
/ * The d y n a m i c s e c t i o n c o n t a i n s a s e r i e s o f t a g g e d e n t r i e s .
* We n e e d t h e R E L A a n d R E L A C O U N T e n t r i e s . * /
li r9 ,0
li r0 ,0
9 : lwz r8 ,0 ( r12 ) / * g e t t a g * /
cmpwi r8 ,0
beq 1 0 f / * e n d o f l i s t * /
cmpwi r8 ,R E L A
bne 1 1 f
lwz r9 ,4 ( r12 ) / * g e t R E L A p o i n t e r i n r9 * /
b 1 2 f
11 : addis r8 ,r8 ,( - R E L A C O U N T ) @ha
cmpwi r8 ,R E L A C O U N T @l
bne 1 2 f
lwz r0 ,4 ( r12 ) / * g e t R E L A C O U N T v a l u e i n r0 * /
12 : addi r12 ,r12 ,8
b 9 b
2005-10-29 04:46:48 +04:00
2011-04-13 00:38:55 +04:00
/ * The r e l o c a t i o n s e c t i o n c o n t a i n s a l i s t o f r e l o c a t i o n s .
* We n o w d o t h e R _ P P C _ R E L A T I V E o n e s , w h i c h p o i n t t o w o r d s
* which n e e d t o b e i n i t i a l i z e d w i t h a d d e n d + o f f s e t .
* The R _ P P C _ R E L A T I V E o n e s c o m e f i r s t a n d t h e r e a r e R E L A C O U N T
* of t h e m . * /
10 : /* skip relocation if we don't have both */
cmpwi r0 ,0
2005-11-18 00:09:02 +03:00
beq 3 f
2011-04-13 00:38:55 +04:00
cmpwi r9 ,0
beq 3 f
add r9 ,r9 ,r11 / * R e l o c a t e R E L A p o i n t e r * /
mtctr r0
2 : lbz r0 ,4 + 3 ( r9 ) / * E L F 3 2 _ R _ I N F O ( r e l o c - > r _ i n f o ) * /
cmpwi r0 ,2 2 / * R _ P P C _ R E L A T I V E * /
bne 3 f
lwz r12 ,0 ( r9 ) / * r e l o c - > r _ o f f s e t * /
lwz r0 ,8 ( r9 ) / * r e l o c - > r _ a d d e n d * /
add r0 ,r0 ,r11
stwx r0 ,r11 ,r12
addi r9 ,r9 ,1 2
2005-11-18 00:09:02 +03:00
bdnz 2 b
2005-10-29 04:46:48 +04: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 06:24:52 +03:00
/* Do a cache flush for our text, in case the loader didn't */
2011-04-13 00:38:55 +04:00
3 : lwz r9 ,p _ s t a r t - p _ b a s e ( r10 ) / * n o t e : t h e s e a r e r e l o c a t e d n o w * /
lwz r8 ,p _ e t e x t - p _ b a s e ( r10 )
2005-11-18 00:09:02 +03:00
4 : dcbf r0 ,r9
2005-04-17 02:20:36 +04:00
icbi r0 ,r9
addi r9 ,r9 ,0 x20
2006-03-04 15:15:40 +03:00
cmplw c r0 ,r9 ,r8
2005-11-18 00:09:02 +03:00
blt 4 b
2005-04-17 02:20:36 +04: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 06:24:52 +03:00
/* Clear the BSS */
2011-04-13 00:38:55 +04:00
lwz r9 ,p _ b s s _ s t a r t - p _ b a s e ( r10 )
lwz r8 ,p _ e n d - p _ b a s e ( r10 )
li r0 ,0
5 : stw r0 ,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 06:24:52 +03:00
addi r9 ,r9 ,4
cmplw c r0 ,r9 ,r8
blt 5 b
2005-04-17 02:20:36 +04: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 06:24:52 +03:00
/* Possibly set up a custom stack */
2011-04-13 00:38:55 +04:00
lwz r8 ,p _ p s t a c k - p _ b a s e ( r10 )
[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 06:24:52 +03:00
cmpwi r8 ,0
beq 6 f
lwz r1 ,0 ( r8 )
li r0 ,0
stwu r0 ,- 1 6 ( r1 ) / * e s t a b l i s h a s t a c k f r a m e * /
6 :
2014-04-24 11:23:37 +04:00
# else / * _ _ p o w e r p c64 _ _ * /
/* Save the prom pointer at p_prom. */
std r5 ,( p _ p r o m - p _ b a s e ) ( r10 )
/* Set r2 to the TOC. */
ld r2 ,( p _ t o c - p _ b a s e ) ( r10 )
add r2 ,r2 ,r10
/* Grab the link address of the dynamic section in r11. */
ld r11 ,- 3 2 7 6 8 ( r2 )
cmpwi r11 ,0
beq 3 f / * i f n o t l i n k e d - p i e t h e n n o d y n a m i c s e c t i o n * /
ld r11 ,( p _ d y n - p _ b a s e ) ( r10 )
add r11 ,r11 ,r10
ld r9 ,( p _ r e l a - p _ b a s e ) ( r10 )
add r9 ,r9 ,r10
li r7 ,0
li r8 ,0
9 : ld r6 ,0 ( r11 ) / * g e t t a g * /
cmpdi r6 ,0
beq 1 2 f / * e n d o f l i s t * /
cmpdi r6 ,R E L A
bne 1 0 f
ld r7 ,8 ( r11 ) / * g e t R E L A p o i n t e r i n r7 * /
b 1 1 f
10 : addis r6 ,r6 ,( - R E L A C O U N T ) @ha
cmpdi r6 ,R E L A C O U N T @l
bne 1 1 f
ld r8 ,8 ( r11 ) / * g e t R E L A C O U N T v a l u e i n r8 * /
11 : addi r11 ,r11 ,1 6
b 9 b
12 :
cmpdi r7 ,0 / * c h e c k w e h a v e b o t h R E L A a n d R E L A C O U N T * /
cmpdi c r1 ,r8 ,0
beq 3 f
beq c r1 ,3 f
/* Calcuate the runtime offset. */
subf r7 ,r7 ,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 06:24:52 +03:00
2014-04-24 11:23:37 +04:00
/ * Run t h r o u g h t h e l i s t o f r e l o c a t i o n s a n d p r o c e s s t h e
* R_ P P C 6 4 _ R E L A T I V E o n e s . * /
mtctr r8
13 : ld r0 ,8 ( r9 ) / * E L F 6 4 _ R _ T Y P E ( r e l o c - > r _ i n f o ) * /
cmpdi r0 ,2 2 / * R _ P P C 6 4 _ R E L A T I V E * /
bne 3 f
ld r6 ,0 ( r9 ) / * r e l o c - > r _ o f f s e t * /
ld r0 ,1 6 ( r9 ) / * r e l o c - > r _ a d d e n d * /
add r0 ,r0 ,r7
stdx r0 ,r7 ,r6
addi r9 ,r9 ,2 4
bdnz 1 3 b
/* Do a cache flush for our text, in case the loader didn't */
3 : ld r9 ,p _ s t a r t - p _ b a s e ( r10 ) / * n o t e : t h e s e a r e r e l o c a t e d n o w * /
ld r8 ,p _ e t e x t - p _ b a s e ( r10 )
4 : dcbf r0 ,r9
icbi r0 ,r9
addi r9 ,r9 ,0 x20
cmpld c r0 ,r9 ,r8
blt 4 b
sync
isync
/* Clear the BSS */
ld r9 ,p _ b s s _ s t a r t - p _ b a s e ( r10 )
ld r8 ,p _ e n d - p _ b a s e ( r10 )
li r0 ,0
5 : std r0 ,0 ( r9 )
addi r9 ,r9 ,8
cmpld c r0 ,r9 ,r8
blt 5 b
/* Possibly set up a custom stack */
ld r8 ,p _ p s t a c k - p _ b a s e ( r10 )
cmpdi r8 ,0
beq 6 f
ld r1 ,0 ( r8 )
li r0 ,0
stdu r0 ,- 1 6 ( r1 ) / * e s t a b l i s h a s t a c k f r a m e * /
6 :
# endif / * _ _ p o w e r p c64 _ _ * /
[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 06:24:52 +03:00
/* Call platform_init() */
bl p l a t f o r m _ i n i t
/* Call start */
b s t a r t
2014-04-24 11:23:36 +04:00
# ifdef _ _ p o w e r p c64 _ _
# define P R O M _ F R A M E _ S I Z E 5 1 2
# define S A V E _ G P R ( n , b a s e ) s t d n ,8 * ( n ) ( b a s e )
# define R E S T _ G P R ( n , b a s e ) l d n ,8 * ( n ) ( b a s e )
# define S A V E _ 2 G P R S ( n , b a s e ) S A V E _ G P R ( n , b a s e ) ; SAVE_GPR(n+1, base)
# define S A V E _ 4 G P R S ( n , b a s e ) S A V E _ 2 G P R S ( n , b a s e ) ; SAVE_2GPRS(n+2, base)
# define S A V E _ 8 G P R S ( n , b a s e ) S A V E _ 4 G P R S ( n , b a s e ) ; SAVE_4GPRS(n+4, base)
# define S A V E _ 1 0 G P R S ( n , b a s e ) S A V E _ 8 G P R S ( n , b a s e ) ; SAVE_2GPRS(n+8, base)
# define R E S T _ 2 G P R S ( n , b a s e ) R E S T _ G P R ( n , b a s e ) ; REST_GPR(n+1, base)
# define R E S T _ 4 G P R S ( n , b a s e ) R E S T _ 2 G P R S ( n , b a s e ) ; REST_2GPRS(n+2, base)
# define R E S T _ 8 G P R S ( n , b a s e ) R E S T _ 4 G P R S ( n , b a s e ) ; REST_4GPRS(n+4, base)
# define R E S T _ 1 0 G P R S ( n , b a s e ) R E S T _ 8 G P R S ( n , b a s e ) ; REST_2GPRS(n+8, base)
/ * prom h a n d l e s t h e j u m p i n t o a n d r e t u r n f r o m f i r m w a r e . T h e p r o m a r g s p o i n t e r
is l o a d e d i n r3 . * /
.globl prom
prom :
mflr r0
std r0 ,1 6 ( r1 )
stdu r1 ,- P R O M _ F R A M E _ S I Z E ( r1 ) / * S a v e S P a n d c r e a t e s t a c k s p a c e * /
SAVE_ G P R ( 2 , r1 )
SAVE_ G P R ( 1 3 , r1 )
SAVE_ 8 G P R S ( 1 4 , r1 )
SAVE_ 1 0 G P R S ( 2 2 , r1 )
mfcr r10
std r10 ,8 * 3 2 ( r1 )
mfmsr r10
std r10 ,8 * 3 3 ( r1 )
/* remove MSR_LE from msr but keep MSR_SF */
mfmsr r10
rldicr r10 ,r10 ,0 ,6 2
mtsrr1 r10
/* Load FW address, set LR to label 1, and jump to FW */
bl 0 f
0 : mflr r10
addi r11 ,r10 ,( 1 f - 0 b )
mtlr r11
ld r10 ,( p _ p r o m - 0 b ) ( r10 )
mtsrr0 r10
rfid
1 : /* Return from OF */
/* Restore registers and return. */
rldicl r1 ,r1 ,0 ,3 2
/* Restore the MSR (back to 64 bits) */
ld r10 ,8 * ( 3 3 ) ( r1 )
mtmsr r10
isync
/* Restore other registers */
REST_ G P R ( 2 , r1 )
REST_ G P R ( 1 3 , r1 )
REST_ 8 G P R S ( 1 4 , r1 )
REST_ 1 0 G P R S ( 2 2 , r1 )
ld r10 ,8 * 3 2 ( r1 )
mtcr r10
addi r1 ,r1 ,P R O M _ F R A M E _ S I Z E
ld r0 ,1 6 ( r1 )
mtlr r0
blr
# endif
