2019-05-27 08:55:01 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* Copyright (C) Paul Mackerras 1997.
|
|
|
|
*
|
2014-04-24 09:23:37 +02:00
|
|
|
* Adapted for 64 bit LE PowerPC by Andrew Tauferner
|
2005-04-16 15:20:36 -07:00
|
|
|
*/
|
|
|
|
|
2005-08-08 13:24:38 +10:00
|
|
|
#include "ppc_asm.h"
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-24 09:23:37 +02:00
|
|
|
RELA = 7
|
2022-04-06 17:00:38 +10:00
|
|
|
RELASZ = 8
|
|
|
|
RELAENT = 9
|
2014-04-24 09:23:37 +02:00
|
|
|
|
2018-11-27 09:01:54 +11:00
|
|
|
.data
|
2011-04-12 20:38:55 +00:00
|
|
|
/* A procedure descriptor used when booting this as a COFF file.
|
|
|
|
* When making COFF, this comes first in the link and we're
|
|
|
|
* linked at 0x500000.
|
|
|
|
*/
|
2007-06-07 22:21:31 +10:00
|
|
|
.globl _zimage_start_opd
|
2006-01-14 15:04:06 +11:00
|
|
|
_zimage_start_opd:
|
2011-04-12 20:38:55 +00:00
|
|
|
.long 0x500000, 0, 0, 0
|
2018-11-27 09:01:54 +11:00
|
|
|
.text
|
|
|
|
b _zimage_start
|
2011-04-12 20:38:55 +00:00
|
|
|
|
2014-04-24 09:23:37 +02:00
|
|
|
#ifdef __powerpc64__
|
|
|
|
.balign 8
|
2017-03-09 16:42:12 +11:00
|
|
|
p_start: .8byte _start
|
|
|
|
p_etext: .8byte _etext
|
|
|
|
p_bss_start: .8byte __bss_start
|
|
|
|
p_end: .8byte _end
|
2014-04-24 09:23:37 +02:00
|
|
|
|
powerpc/toc: Future proof kernel toc
This patch future-proofs the kernel against linker changes that might
put the toc pointer at some location other than .got+0x8000, by
replacing __toc_start+0x8000 with .TOC. throughout. If the kernel's
idea of the toc pointer doesn't agree with the linker, bad things
happen.
prom_init.c code relocating its toc is also changed so that a symbolic
__prom_init_toc_start toc-pointer relative address is calculated
rather than assuming that it is always at toc-pointer - 0x8000. The
length calculations loading values from the toc are also avoided.
It's a little incestuous to do that with unreloc_toc picking up
adjusted values (which is fine in practice, they both adjust by the
same amount if all goes well).
I've also changed the way .got is aligned in vmlinux.lds and
zImage.lds, mostly so that dumping out section info by objdump or
readelf plainly shows the alignment is 256. This linker script
feature was added 2005-09-27, available in FSF binutils releases from
2.17 onwards. Should be safe to use in the kernel, I think.
Finally, put *(.got) before the prom_init.o entry which only needs
*(.toc), so that the GOT header goes in the correct place. I don't
believe this makes any difference for the kernel as it would for
dynamic objects being loaded by ld.so. That change is just to stop
lusers who blindly copy kernel scripts being led astray. Of course,
this change needs the prom_init.c changes.
Some notes on .toc and .got.
.toc is a compiler generated section of addresses. .got is a linker
generated section of addresses, generally built when the linker sees
R_*_*GOT* relocations. In the case of powerpc64 ld.bfd, there are
multiple generated .got sections, one per input object file. So you
can somewhat reasonably write in a linker script an input section
statement like *prom_init.o(.got .toc) to mean "the .got and .toc
section for files matching *prom_init.o". On other architectures that
doesn't make sense, because the linker generally has just one .got
section. Even on powerpc64, note well that the GOT entries for
prom_init.o may be merged with GOT entries from other objects. That
means that if prom_init.o references, say, _end via some GOT
relocation, and some other object also references _end via a GOT
relocation, the GOT entry for _end may be in the range
__prom_init_toc_start to __prom_init_toc_end and if the kernel does
something special to GOT/TOC entries in that range then the value of
_end as seen by objects other than prom_init.o will be affected. On
the other hand the GOT entry for _end may not be in the range
__prom_init_toc_start to __prom_init_toc_end. Which way it turns out
is deterministic but a detail of linker operation that should not be
relied on.
A feature of ld.bfd is that input .toc (and .got) sections matching
one linker input section statement may be sorted, to put entries used
by small-model code first, near the toc base. This is why scripts for
powerpc64 normally use *(.got .toc) rather than *(.got) *(.toc), since
the first form allows more freedom to sort.
Another feature of ld.bfd is that indirect addressing sequences using
the GOT/TOC may be edited by the linker to relative addressing. In
many cases relative addressing would be emitted by gcc for
-mcmodel=medium if you appropriately decorate variable declarations
with non-default visibility.
The original patch is here:
https://lore.kernel.org/linuxppc-dev/20210310034813.GM6042@bubble.grove.modra.org/
Signed-off-by: Alan Modra <amodra@au1.ibm.com>
[aik: removed non-relocatable which is gone in 24d33ac5b8ffb]
[aik: added <=2.24 check]
[aik: because of llvm-as, kernel_toc_addr() uses "mr" instead of global register variable]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211221055904.555763-2-aik@ozlabs.ru
2021-12-21 16:58:59 +11:00
|
|
|
p_toc: .8byte .TOC. - p_base
|
2017-03-09 16:42:12 +11:00
|
|
|
p_dyn: .8byte __dynamic_start - p_base
|
|
|
|
p_rela: .8byte __rela_dyn_start - p_base
|
|
|
|
p_prom: .8byte 0
|
2014-04-24 09:23:37 +02:00
|
|
|
.weak _platform_stack_top
|
2017-03-09 16:42:12 +11:00
|
|
|
p_pstack: .8byte _platform_stack_top
|
2014-04-24 09:23:37 +02:00
|
|
|
#else
|
2011-04-12 20:38:55 +00:00
|
|
|
p_start: .long _start
|
|
|
|
p_etext: .long _etext
|
|
|
|
p_bss_start: .long __bss_start
|
|
|
|
p_end: .long _end
|
|
|
|
|
|
|
|
.weak _platform_stack_top
|
|
|
|
p_pstack: .long _platform_stack_top
|
2014-04-24 09:23:37 +02:00
|
|
|
#endif
|
2006-01-14 15:04:06 +11:00
|
|
|
|
2018-09-14 13:36:47 +09:30
|
|
|
.weak _zimage_start
|
2005-10-28 17:46:49 -07:00
|
|
|
_zimage_start:
|
2007-03-21 09:02:53 -06:00
|
|
|
.globl _zimage_start_lib
|
|
|
|
_zimage_start_lib:
|
2006-01-14 15:04:06 +11:00
|
|
|
/* Work out the offset between the address we were linked at
|
|
|
|
and the address where we're running. */
|
2023-04-07 14:09:24 +10:00
|
|
|
bcl 20,31,.+4
|
2011-04-12 20:38:55 +00:00
|
|
|
p_base: mflr r10 /* r10 now points to runtime addr of p_base */
|
2014-04-24 09:23:37 +02:00
|
|
|
#ifndef __powerpc64__
|
2011-04-12 20:38:55 +00:00
|
|
|
/* grab the link address of the dynamic section in r11 */
|
|
|
|
addis r11,r10,(_GLOBAL_OFFSET_TABLE_-p_base)@ha
|
|
|
|
lwz r11,(_GLOBAL_OFFSET_TABLE_-p_base)@l(r11)
|
|
|
|
cmpwi r11,0
|
|
|
|
beq 3f /* if not linked -pie */
|
|
|
|
/* get the runtime address of the dynamic section in r12 */
|
|
|
|
.weak __dynamic_start
|
|
|
|
addis r12,r10,(__dynamic_start-p_base)@ha
|
|
|
|
addi r12,r12,(__dynamic_start-p_base)@l
|
|
|
|
subf r11,r11,r12 /* runtime - linktime offset */
|
|
|
|
|
|
|
|
/* The dynamic section contains a series of tagged entries.
|
|
|
|
* We need the RELA and RELACOUNT entries. */
|
|
|
|
li r9,0
|
|
|
|
li r0,0
|
|
|
|
9: lwz r8,0(r12) /* get tag */
|
|
|
|
cmpwi r8,0
|
|
|
|
beq 10f /* end of list */
|
|
|
|
cmpwi r8,RELA
|
|
|
|
bne 11f
|
|
|
|
lwz r9,4(r12) /* get RELA pointer in r9 */
|
|
|
|
b 12f
|
2022-04-06 17:00:38 +10:00
|
|
|
11: cmpwi r8,RELASZ
|
|
|
|
bne .Lcheck_for_relaent
|
|
|
|
lwz r0,4(r12) /* get RELASZ value in r0 */
|
|
|
|
b 12f
|
|
|
|
.Lcheck_for_relaent:
|
|
|
|
cmpwi r8,RELAENT
|
2011-04-12 20:38:55 +00:00
|
|
|
bne 12f
|
2022-04-06 17:00:38 +10:00
|
|
|
lwz r14,4(r12) /* get RELAENT value in r14 */
|
2011-04-12 20:38:55 +00:00
|
|
|
12: addi r12,r12,8
|
|
|
|
b 9b
|
2005-10-28 17:46:48 -07:00
|
|
|
|
2011-04-12 20:38:55 +00:00
|
|
|
/* The relocation section contains a list of relocations.
|
|
|
|
* We now do the R_PPC_RELATIVE ones, which point to words
|
2022-04-06 17:00:38 +10:00
|
|
|
* which need to be initialized with addend + offset */
|
2011-04-12 20:38:55 +00:00
|
|
|
10: /* skip relocation if we don't have both */
|
|
|
|
cmpwi r0,0
|
2005-11-17 22:09:02 +01:00
|
|
|
beq 3f
|
2011-04-12 20:38:55 +00:00
|
|
|
cmpwi r9,0
|
|
|
|
beq 3f
|
2022-04-06 17:00:38 +10:00
|
|
|
cmpwi r14,0
|
|
|
|
beq 3f
|
2011-04-12 20:38:55 +00:00
|
|
|
|
|
|
|
add r9,r9,r11 /* Relocate RELA pointer */
|
2022-04-06 17:00:38 +10:00
|
|
|
divwu r0,r0,r14 /* RELASZ / RELAENT */
|
2011-04-12 20:38:55 +00:00
|
|
|
mtctr r0
|
|
|
|
2: lbz r0,4+3(r9) /* ELF32_R_INFO(reloc->r_info) */
|
|
|
|
cmpwi r0,22 /* R_PPC_RELATIVE */
|
2022-04-06 17:00:38 +10:00
|
|
|
bne .Lnext
|
2011-04-12 20:38:55 +00:00
|
|
|
lwz r12,0(r9) /* reloc->r_offset */
|
|
|
|
lwz r0,8(r9) /* reloc->r_addend */
|
|
|
|
add r0,r0,r11
|
|
|
|
stwx r0,r11,r12
|
2022-04-06 17:00:38 +10:00
|
|
|
.Lnext: add r9,r9,r14
|
2005-11-17 22:09:02 +01:00
|
|
|
bdnz 2b
|
2005-10-28 17:46:48 -07: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 14:24:52 +11:00
|
|
|
/* Do a cache flush for our text, in case the loader didn't */
|
2011-04-12 20:38:55 +00:00
|
|
|
3: lwz r9,p_start-p_base(r10) /* note: these are relocated now */
|
|
|
|
lwz r8,p_etext-p_base(r10)
|
2005-11-17 22:09:02 +01:00
|
|
|
4: dcbf r0,r9
|
2005-04-16 15:20:36 -07:00
|
|
|
icbi r0,r9
|
|
|
|
addi r9,r9,0x20
|
2006-03-04 13:15:40 +01:00
|
|
|
cmplw cr0,r9,r8
|
2005-11-17 22:09:02 +01:00
|
|
|
blt 4b
|
2005-04-16 15:20:36 -07: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 14:24:52 +11:00
|
|
|
/* Clear the BSS */
|
2011-04-12 20:38:55 +00:00
|
|
|
lwz r9,p_bss_start-p_base(r10)
|
|
|
|
lwz r8,p_end-p_base(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 14:24:52 +11:00
|
|
|
addi r9,r9,4
|
|
|
|
cmplw cr0,r9,r8
|
|
|
|
blt 5b
|
2005-04-16 15:20:36 -07: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 14:24:52 +11:00
|
|
|
/* Possibly set up a custom stack */
|
2011-04-12 20:38:55 +00:00
|
|
|
lwz r8,p_pstack-p_base(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 14:24:52 +11:00
|
|
|
cmpwi r8,0
|
|
|
|
beq 6f
|
|
|
|
lwz r1,0(r8)
|
|
|
|
li r0,0
|
|
|
|
stwu r0,-16(r1) /* establish a stack frame */
|
|
|
|
6:
|
2014-04-24 09:23:37 +02:00
|
|
|
#else /* __powerpc64__ */
|
|
|
|
/* Save the prom pointer at p_prom. */
|
|
|
|
std r5,(p_prom-p_base)(r10)
|
|
|
|
|
|
|
|
/* Set r2 to the TOC. */
|
|
|
|
ld r2,(p_toc-p_base)(r10)
|
|
|
|
add r2,r2,r10
|
|
|
|
|
|
|
|
/* Grab the link address of the dynamic section in r11. */
|
|
|
|
ld r11,-32768(r2)
|
|
|
|
cmpwi r11,0
|
|
|
|
beq 3f /* if not linked -pie then no dynamic section */
|
|
|
|
|
|
|
|
ld r11,(p_dyn-p_base)(r10)
|
|
|
|
add r11,r11,r10
|
|
|
|
ld r9,(p_rela-p_base)(r10)
|
|
|
|
add r9,r9,r10
|
|
|
|
|
2015-02-11 12:55:44 +08:00
|
|
|
li r13,0
|
2014-04-24 09:23:37 +02:00
|
|
|
li r8,0
|
2015-02-11 12:55:44 +08:00
|
|
|
9: ld r12,0(r11) /* get tag */
|
|
|
|
cmpdi r12,0
|
2014-04-24 09:23:37 +02:00
|
|
|
beq 12f /* end of list */
|
2015-02-11 12:55:44 +08:00
|
|
|
cmpdi r12,RELA
|
2014-04-24 09:23:37 +02:00
|
|
|
bne 10f
|
2015-02-11 12:55:44 +08:00
|
|
|
ld r13,8(r11) /* get RELA pointer in r13 */
|
2014-04-24 09:23:37 +02:00
|
|
|
b 11f
|
2022-04-06 17:00:38 +10:00
|
|
|
10: cmpwi r12,RELASZ
|
|
|
|
bne .Lcheck_for_relaent
|
|
|
|
lwz r8,8(r11) /* get RELASZ pointer in r8 */
|
|
|
|
b 11f
|
|
|
|
.Lcheck_for_relaent:
|
|
|
|
cmpwi r12,RELAENT
|
|
|
|
bne 11f
|
|
|
|
lwz r14,8(r11) /* get RELAENT pointer in r14 */
|
2014-04-24 09:23:37 +02:00
|
|
|
11: addi r11,r11,16
|
|
|
|
b 9b
|
|
|
|
12:
|
2022-04-06 17:00:38 +10:00
|
|
|
cmpdi r13,0 /* check we have both RELA, RELASZ, RELAENT*/
|
2014-04-24 09:23:37 +02:00
|
|
|
cmpdi cr1,r8,0
|
|
|
|
beq 3f
|
|
|
|
beq cr1,3f
|
2022-04-06 17:00:38 +10:00
|
|
|
cmpdi r14,0
|
|
|
|
beq 3f
|
2014-04-24 09:23:37 +02:00
|
|
|
|
|
|
|
/* Calcuate the runtime offset. */
|
2015-02-11 12:55:44 +08:00
|
|
|
subf r13,r13,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 14:24:52 +11:00
|
|
|
|
2014-04-24 09:23:37 +02:00
|
|
|
/* Run through the list of relocations and process the
|
|
|
|
* R_PPC64_RELATIVE ones. */
|
2022-04-06 17:00:38 +10:00
|
|
|
divdu r8,r8,r14 /* RELASZ / RELAENT */
|
2014-04-24 09:23:37 +02:00
|
|
|
mtctr r8
|
|
|
|
13: ld r0,8(r9) /* ELF64_R_TYPE(reloc->r_info) */
|
|
|
|
cmpdi r0,22 /* R_PPC64_RELATIVE */
|
2022-04-06 17:00:38 +10:00
|
|
|
bne .Lnext
|
2015-02-11 12:55:44 +08:00
|
|
|
ld r12,0(r9) /* reloc->r_offset */
|
2014-04-24 09:23:37 +02:00
|
|
|
ld r0,16(r9) /* reloc->r_addend */
|
2015-02-11 12:55:44 +08:00
|
|
|
add r0,r0,r13
|
|
|
|
stdx r0,r13,r12
|
2022-04-06 17:00:38 +10:00
|
|
|
.Lnext: add r9,r9,r14
|
2014-04-24 09:23:37 +02:00
|
|
|
bdnz 13b
|
|
|
|
|
|
|
|
/* Do a cache flush for our text, in case the loader didn't */
|
|
|
|
3: ld r9,p_start-p_base(r10) /* note: these are relocated now */
|
|
|
|
ld r8,p_etext-p_base(r10)
|
|
|
|
4: dcbf r0,r9
|
|
|
|
icbi r0,r9
|
|
|
|
addi r9,r9,0x20
|
|
|
|
cmpld cr0,r9,r8
|
|
|
|
blt 4b
|
|
|
|
sync
|
|
|
|
isync
|
|
|
|
|
|
|
|
/* Clear the BSS */
|
|
|
|
ld r9,p_bss_start-p_base(r10)
|
|
|
|
ld r8,p_end-p_base(r10)
|
|
|
|
li r0,0
|
|
|
|
5: std r0,0(r9)
|
|
|
|
addi r9,r9,8
|
|
|
|
cmpld cr0,r9,r8
|
|
|
|
blt 5b
|
|
|
|
|
|
|
|
/* Possibly set up a custom stack */
|
|
|
|
ld r8,p_pstack-p_base(r10)
|
|
|
|
cmpdi r8,0
|
|
|
|
beq 6f
|
|
|
|
ld r1,0(r8)
|
|
|
|
li r0,0
|
2015-02-11 12:55:44 +08:00
|
|
|
stdu r0,-112(r1) /* establish a stack frame */
|
2014-04-24 09:23:37 +02:00
|
|
|
6:
|
|
|
|
#endif /* __powerpc64__ */
|
[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 14:24:52 +11:00
|
|
|
/* Call platform_init() */
|
|
|
|
bl platform_init
|
|
|
|
|
|
|
|
/* Call start */
|
|
|
|
b start
|
2014-04-24 09:23:36 +02:00
|
|
|
|
|
|
|
#ifdef __powerpc64__
|
|
|
|
|
|
|
|
#define PROM_FRAME_SIZE 512
|
2021-10-22 16:13:22 +10:00
|
|
|
|
|
|
|
.macro OP_REGS op, width, start, end, base, offset
|
|
|
|
.Lreg=\start
|
|
|
|
.rept (\end - \start + 1)
|
|
|
|
\op .Lreg,\offset+\width*.Lreg(\base)
|
|
|
|
.Lreg=.Lreg+1
|
|
|
|
.endr
|
|
|
|
.endm
|
|
|
|
|
|
|
|
#define SAVE_GPRS(start, end, base) OP_REGS std, 8, start, end, base, 0
|
|
|
|
#define REST_GPRS(start, end, base) OP_REGS ld, 8, start, end, base, 0
|
|
|
|
#define SAVE_GPR(n, base) SAVE_GPRS(n, n, base)
|
|
|
|
#define REST_GPR(n, base) REST_GPRS(n, n, base)
|
2014-04-24 09:23:36 +02:00
|
|
|
|
|
|
|
/* prom handles the jump into and return from firmware. The prom args pointer
|
|
|
|
is loaded in r3. */
|
|
|
|
.globl prom
|
|
|
|
prom:
|
|
|
|
mflr r0
|
|
|
|
std r0,16(r1)
|
|
|
|
stdu r1,-PROM_FRAME_SIZE(r1) /* Save SP and create stack space */
|
|
|
|
|
|
|
|
SAVE_GPR(2, r1)
|
2021-10-22 16:13:22 +10:00
|
|
|
SAVE_GPRS(13, 31, r1)
|
2014-04-24 09:23:36 +02:00
|
|
|
mfcr r10
|
|
|
|
std r10,8*32(r1)
|
|
|
|
mfmsr r10
|
|
|
|
std r10,8*33(r1)
|
|
|
|
|
|
|
|
/* remove MSR_LE from msr but keep MSR_SF */
|
|
|
|
mfmsr r10
|
|
|
|
rldicr r10,r10,0,62
|
|
|
|
mtsrr1 r10
|
|
|
|
|
|
|
|
/* Load FW address, set LR to label 1, and jump to FW */
|
2023-04-07 14:09:24 +10:00
|
|
|
bcl 20,31,0f
|
2014-04-24 09:23:36 +02:00
|
|
|
0: mflr r10
|
|
|
|
addi r11,r10,(1f-0b)
|
|
|
|
mtlr r11
|
|
|
|
|
|
|
|
ld r10,(p_prom-0b)(r10)
|
|
|
|
mtsrr0 r10
|
|
|
|
|
|
|
|
rfid
|
|
|
|
|
|
|
|
1: /* Return from OF */
|
2014-04-24 09:23:39 +02:00
|
|
|
FIXUP_ENDIAN
|
2014-04-24 09:23:36 +02:00
|
|
|
|
|
|
|
/* Restore registers and return. */
|
|
|
|
rldicl r1,r1,0,32
|
|
|
|
|
|
|
|
/* Restore the MSR (back to 64 bits) */
|
|
|
|
ld r10,8*(33)(r1)
|
|
|
|
mtmsr r10
|
|
|
|
isync
|
|
|
|
|
|
|
|
/* Restore other registers */
|
|
|
|
REST_GPR(2, r1)
|
2021-10-22 16:13:22 +10:00
|
|
|
REST_GPRS(13, 31, r1)
|
2014-04-24 09:23:36 +02:00
|
|
|
ld r10,8*32(r1)
|
|
|
|
mtcr r10
|
|
|
|
|
|
|
|
addi r1,r1,PROM_FRAME_SIZE
|
|
|
|
ld r0,16(r1)
|
|
|
|
mtlr r0
|
|
|
|
blr
|
|
|
|
#endif
|