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

Signed-off-by: Geoff Levand <redacted>

---
 arch/powerpc/boot/head.S       |   96 +++++++++++++++++++++++++++++++++++++++++
 arch/powerpc/boot/zImage.lds.S |    2 
 2 files changed, 98 insertions(+)

--- /dev/null
+++ ps3-linux-dev/arch/powerpc/boot/head.S

@@ -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:
--- ps3-linux-dev.orig/arch/powerpc/boot/zImage.lds.S
+++ ps3-linux-dev/arch/powerpc/boot/zImage.lds.S

@@ -2,6 +2,8 @@ OUTPUT_ARCH(powerpc:common)
 ENTRY(_zimage_start)
 SECTIONS
 {
+  .vectors 0 : { *(.vectors) }
+
   . = (4*1024*1024);
   _start = .;
   .text      :

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

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 <redacted>

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

Geoff Levand writes:

+	xor	r4, r4, r4

What's wrong with "li r4,0"?

Paul.

Josh Boyer wrote:

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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 <redacted>

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

No, its not platform specific nor SMP specific, it should work
with all SMP and UP platforms that need this kind of support.

-Geoff

On Mon, 2007-02-19 at 07:03 -0800, Geoff Levand wrote:

Josh Boyer wrote:

quoted

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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 <redacted>

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

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.

Benjamin Herrenschmidt wrote:

On Mon, 2007-02-19 at 07:03 -0800, Geoff Levand wrote:

quoted

Josh Boyer wrote:

quoted

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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 <redacted>

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

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

It won't do any good, or it won't work?  I figured it would just branch to
_zimage_start on 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.

On Mon, 2007-02-19 at 07:03 -0800, Geoff Levand wrote:

Josh Boyer wrote:

quoted

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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 <redacted>

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

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

Josh Boyer wrote:

On Mon, 2007-02-19 at 07:03 -0800, Geoff Levand wrote:

quoted

Josh Boyer wrote:

quoted

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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 <redacted>

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

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

On Mon, 2007-02-19 at 13:39 -0800, Geoff Levand wrote:

Josh Boyer wrote:

quoted

On Mon, 2007-02-19 at 07:03 -0800, Geoff Levand wrote:

quoted

Josh Boyer wrote:

quoted

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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 <redacted>

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

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

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

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.

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

David Gibson wrote:

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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.

I need two entry points, one for the first stage loader (0x100), and one
for a second stage kexec loader (_zimage_start).

-Geoff

Geoff Levand wrote:

David Gibson wrote:

quoted

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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.

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

+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

On Tue, Feb 20, 2007 at 07:44:25AM -0800, Geoff Levand wrote:

Geoff Levand wrote:

quoted

David Gibson wrote:

quoted

On Sat, Feb 17, 2007 at 05:17:08PM -0800, Geoff Levand wrote:

quoted

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.

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.

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.

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.

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

On Tue, Feb 20, 2007 at 05:02:11PM +0100, Segher Boessenkool wrote:

quoted

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

No, the initial loader has a hard-wired entry point, that's why this
is necessary.

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

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.

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

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