zImage: Exception vector support
RFC 3/3 zImage: Exception vector support
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.
--- arch/powerpc/boot/head.S | 96 +++++++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/zImage.lds.S | 2 2 files changed, 98 insertions(+)
arch/powerpc/boot/head.S new file +96 -0
@@ -0,0 +1,96 @@ +/* + * zImage exception vector entry. + * + * Copyright (C) 2007 Sony Computer Entertainment Inc. + * Copyright 2007 Sony Corp. + * + * 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; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include "ppc_asm.h" + +/* + * __system_reset_entry - For platforms entering at the reset vector. + * + * __system_reset_entry runs the bootwrapper code on cpu 0 to prepare the + * wrapped kernel image. Cpu 0 then enters the kernel at the end of the + * bootwrapper code. .secondary_start sends secondary cpus to + * smp_secondary_hold() to wait until the bootwrapper code is finished + * running. When signled, secondary cpus enter the kernel directly from + * smp_secondary_hold(). + * + * This implementation supports only one secondary cpu. + * + * For the PS3 first stage entry the MMU is off and the bootwrapper image + * has been loaded to lpar address zero. The bootwrapper is entered at + * 0x100 (system reset) by both proceesor threads. + */ + + .section .vectors,"ax" + . = 0x100 + .globl __system_reset_entry +__system_reset_entry: + + /* switch to 32-bit mode */ + + mfmsr r9 + clrldi r9,r9,1 + mtmsrd r9 + nop + + /* test thread number and branch */ + + mfspr r3, 0x88 + cntlzw. r3, r3 + beq __primary_start + +__secondary_start: + + /* setup secondary's stack */ + + lis r1, __wrapper_stack_1@ha + addi r1, r1, __wrapper_stack_1@l + subi r1, r1, 16 + + xor r4, r4, r4 + xor r5, r5, r5 + b smp_secondary_hold + +__primary_start: + + /* setup primary's stack */ + + lis r1, __wrapper_stack_0@ha + addi r1, r1, __wrapper_stack_0@l + subi r1, r1, 16 + + xor r3, r3, r3 + xor r4, r4, r4 + xor r5, r5, r5 + b _zimage_start + + .section .bss + .align 16; + . = . + 4096 +__wrapper_stack_0: + +/* + * The bss is cleared in crt0, so put a tiny stack in the data + * section for the secondary cpu. + */ + + .section .data + .align 16; + . = . + 128 +__wrapper_stack_1:
arch/powerpc/boot/zImage.lds.S +2 -0
@@ -2,6 +2,8 @@ OUTPUT_ARCH(powerpc:common) ENTRY(_zimage_start) SECTIONS { + .vectors 0 : { *(.vectors) } + . = (4*1024*1024); _start = .; .text :
Quoted 9 lines · Geoff Levand
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.
Signed-off-by Geoff Levand <[email protected]>--- arch/powerpc/boot/head.S | 96 +++++++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/zImage.lds.S | 2
This one seems pretty PS3 specific, and there's no makefile entry to actually compile it... Could we name it head_ps3.S or something similar?
Or am I misunderstanding the code and it's really generic to most SMP machines (which would make a case to arguably call it head_smp.S).
josh
Quoted 11 lines · Josh Boyer
Quoted 9 lines · Geoff Levand
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.
Signed-off-by Geoff Levand <[email protected]>--- arch/powerpc/boot/head.S | 96 +++++++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/zImage.lds.S | 2
Quoted 5 lines
This one seems pretty PS3 specific, and there's no makefile entry to actually compile it... Could we name it
head_ps3.Sor something similar?Or am I misunderstanding the code and it's really generic to most SMP machines (which would make a case to arguably call it
head_smp.S).
No, its not platform specific nor SMP specific, it should work with all SMP and UP platforms that need this kind of support.
-Geoff
Quoted 12 lines · Geoff Levand
Quoted 11 lines · Josh Boyer
Quoted 9 lines · Geoff Levand
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.
Signed-off-by Geoff Levand <[email protected]>--- arch/powerpc/boot/head.S | 96 +++++++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/zImage.lds.S | 2
Quoted 8 lines
Quoted 5 lines
This one seems pretty PS3 specific, and there's no makefile entry to actually compile it... Could we name it
head_ps3.Sor something similar?Or am I misunderstanding the code and it's really generic to most SMP machines (which would make a case to arguably call it
head_smp.S).No, its not platform specific nor SMP specific, it should work with all SMP and UP platforms that need this kind of support.
Well, all platforms that are multithread at least... the thread number testing won't do any good on 970 for example :-)
Ben.
Quoted 16 lines · Benjamin Herrenschmidt
Quoted 15 lines · Geoff Levand
Quoted 14 lines · Josh Boyer
Quoted 9 lines · Geoff Levand
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.
Signed-off-by Geoff Levand <[email protected]>--- arch/powerpc/boot/head.S | 96 +++++++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/zImage.lds.S | 2This one seems pretty PS3 specific, and there's no makefile entry to actually compile it... Could we name it
head_ps3.Sor something similar?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Or am I misunderstanding the code and it's really generic to most SMP machines (which would make a case to arguably call it
head_smp.S).No, its not platform specific nor SMP specific, it should work with all SMP and UP platforms that need this kind of support.
Well, all platforms that are multithread at least... the thread number testing won't do any good on 970 for example :-)
It won't do any good, or it won't work? I figured it would just branch to _zimage_start on non-SMP systems.
-Geoff
Quoted 3 lines
It won't do any good, or it won't work? I figured it would just branch to
_zimage_starton non-SMP systems.
Well, the SPRN_CTRLF register only exist on some processors. Also, non-IBM processors are likely to do things differently. In fact, I'm not even sure that all POWERx processor use the bits in there the same way.
Ben.
Quoted 12 lines · Geoff Levand
Quoted 11 lines · Josh Boyer
Quoted 9 lines · Geoff Levand
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.
Signed-off-by Geoff Levand <[email protected]>--- arch/powerpc/boot/head.S | 96 +++++++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/zImage.lds.S | 2
Quoted 8 lines
Quoted 5 lines
This one seems pretty PS3 specific, and there's no makefile entry to actually compile it... Could we name it
head_ps3.Sor something similar?Or am I misunderstanding the code and it's really generic to most SMP machines (which would make a case to arguably call it
head_smp.S).No, its not platform specific nor SMP specific, it should work with all SMP and UP platforms that need this kind of support.
Well, I'm not sure it will work with all UP platforms anyway. The SPR you're peeking at to look at the thread number doesn't even exist on 4xx for example.
josh
Quoted 19 lines · Josh Boyer
Quoted 18 lines · Geoff Levand
Quoted 16 lines · Josh Boyer
Quoted 9 lines · Geoff Levand
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.
Signed-off-by Geoff Levand <[email protected]>--- arch/powerpc/boot/head.S | 96 +++++++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/zImage.lds.S | 2This one seems pretty PS3 specific, and there's no makefile entry to actually compile it... Could we name it
head_ps3.Sor something similar?Or am I misunderstanding the code and it's really generic to most SMP machines (which would make a case to arguably call it
head_smp.S).
Quoted 6 lines
Quoted 2 lines
No, its not platform specific nor SMP specific, it should work with all SMP and UP platforms that need this kind of support.
Well, I'm not sure it will work with all UP platforms anyway. The SPR you're peeking at to look at the thread number doesn't even exist on 4xx for example.
The 4xx wrapper needs a reset vector? If so, what bootloader are you using?
-Geoff
Quoted 20 lines · Geoff Levand
Quoted 19 lines · Josh Boyer
Quoted 18 lines · Geoff Levand
Quoted 16 lines · Josh Boyer
Quoted 9 lines · Geoff Levand
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.
Signed-off-by Geoff Levand <[email protected]>--- arch/powerpc/boot/head.S | 96 +++++++++++++++++++++++++++++++++++++++++ arch/powerpc/boot/zImage.lds.S | 2This one seems pretty PS3 specific, and there's no makefile entry to actually compile it... Could we name it
head_ps3.Sor something similar?Or am I misunderstanding the code and it's really generic to most SMP machines (which would make a case to arguably call it
head_smp.S).
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
No, its not platform specific nor SMP specific, it should work with all SMP and UP platforms that need this kind of support.
Well, I'm not sure it will work with all UP platforms anyway. The SPR you're peeking at to look at the thread number doesn't even exist on 4xx for example.
The 4xx wrapper needs a reset vector? If so, what bootloader are you using?
Ok, sorry. Getting ahead of myself there. I'll shut up now.
josh
Review
Quoted 1 line · Geoff Levand
(quoted diff) +1
-0+ xor r4, r4, r4
What's wrong with "li r4,0"?
Paul.
Quoted 3 lines · Geoff Levand
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.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Quoted 5 lines · David Gibson
Quoted 3 lines · Geoff Levand
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.
Quoted 9 lines
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_startto 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).
-Geoff
Quoted 12 lines · Geoff Levand
Quoted 11 lines · David Gibson
Quoted 3 lines · Geoff Levand
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.
Quoted 6 lines
Quoted 3 lines
I think this belongs in a ps3.o, which will define
_zimage_startto 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
Quoted 7 lines
(quoted diff) +3
-0+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.
If this is an ELF file, you can put the exception vectors in a separate segment. Or if you don't need the entry point to be in the low region, (and you don't need that unless your boot loader ignores the entry point in the ELF header), you can copy the vectors in at startup and have no code linked at 0 at all.
Segher
Quoted 11 lines · Segher Boessenkool
Quoted 10 lines
(quoted diff) +3
-0+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.
Quoted 6 lines
If this is an ELF file, you can put the exception vectors in a separate segment. Or if you don't need the entry point to be in the low region, (and you don't need that unless your boot loader ignores the entry point in the ELF header), you can copy the vectors in at startup and have no code linked at 0 at all.
No, the initial loader has a hard-wired entry point, that's why this is necessary.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Quoted 7 lines
If this is an ELF file, you can put the exception vectors in a separate segment. Or if you don't need the entry point to be in the low region, (and you don't need that unless your boot loader ignores the entry point in the ELF header), you can copy the vectors in at startup and have no code linked at 0 at all.
No you cant. When flashed in ROM, the HV expands the bootloader binary at 0 and jumps to 0x100
Ben.
Quoted 9 lines
Quoted 6 lines
If this is an ELF file, you can put the exception vectors in a separate segment. Or if you don't need the entry point to be in the low region, (and you don't need that unless your boot loader ignores the entry point in the ELF header), you can copy the vectors in at startup and have no code linked at 0 at all.
No you cant. When flashed in ROM, the HV expands the bootloader binary at 0 and jumps to
0x100
Yeah, I said "if this is an ELF file", and that's not the case unfortunately.
Segher
Quoted 13 lines · Geoff Levand
Quoted 12 lines · Geoff Levand
Quoted 11 lines · David Gibson
Quoted 3 lines · Geoff Levand
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.
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
I think this belongs in a ps3.o, which will define
_zimage_startto 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).
Ok, in that case you can have a separate _zimage_start from the reset vector.
Quoted 10 lines
Sorry, I should have been more clear. This is what I have in the wrapper. My intension was that
head.Sis only used for platforms that need it.(quoted diff) +3
-0+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.
Ah, ok, that's reasonable. However, for the time being, PS3 is the only platform that needs this. I think it would be better to do this as a PS3 specific wrapper initially. Later, if we get other platforms that need a reset vector we can see what's really common and consolidate it.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Quoted 4 lines
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.
That's still a bit gross even with a zImage... right now, I don't think you can specify the link address per platform, can you ? Would be better if it was set to 0 for ps3... that or have the reset vector be at BASE + 0x100 ...
Ben.