Author: afaerber Date: Thu Nov 25 22:56:23 2010 New Revision: 969 URL: http://tracker.coreboot.org/trac/openbios/changeset/969
Log: ppc: Set up TOC base for ppc64
r2 points to TOC base, __toc_start + 0x8000. This value is stored as part of the function descriptor.
Include some related ELF sections in the linker script.
Cc: Alexander Graf agraf@suse.de Cc: Segher Boessenkool segher@kernel.crashing.org Signed-off-by: Andreas Färber andreas.faerber@web.de
Modified: trunk/openbios-devel/arch/ppc/qemu/start.S trunk/openbios-devel/arch/ppc64/qemu/ldscript
Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Thu Nov 25 22:53:25 2010 (r968) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Thu Nov 25 22:56:23 2010 (r969) @@ -445,6 +445,13 @@
/* save memory size in stack */
+#ifdef __powerpc64__ + /* set up TOC pointer */ + + LOAD_REG_IMMEDIATE(r2, setup_mmu) + ld r2, 8(r2) +#endif + bl BRANCH_LABEL(setup_mmu) bl BRANCH_LABEL(entry) 1: nop
Modified: trunk/openbios-devel/arch/ppc64/qemu/ldscript ============================================================================== --- trunk/openbios-devel/arch/ppc64/qemu/ldscript Thu Nov 25 22:53:25 2010 (r968) +++ trunk/openbios-devel/arch/ppc64/qemu/ldscript Thu Nov 25 22:56:23 2010 (r969) @@ -41,8 +41,18 @@ _data = .; *(.data) *(.data.*) + *(.toc1) + *(.branch_lt) _edata = .; } + .opd : { + *(.opd) + } + .got : { + __toc_start = .; + *(.got) + *(.toc) + }
.bss ALIGN(4096): { _bss = .;
Am 25.11.2010 um 22:56 schrieb repository service:
Author: afaerber Date: Thu Nov 25 22:56:23 2010 New Revision: 969 URL: http://tracker.coreboot.org/trac/openbios/changeset/969
Log: ppc: Set up TOC base for ppc64
r2 points to TOC base, __toc_start + 0x8000. This value is stored as part of the function descriptor.
Include some related ELF sections in the linker script.
Cc: Alexander Graf agraf@suse.de Cc: Segher Boessenkool segher@kernel.crashing.org Signed-off-by: Andreas Färber andreas.faerber@web.de
Starting with this revision,
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
Have fun,
Andreas
Andreas Färber wrote:
Starting with this revision,
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
Have fun,
Andreas
Great work! :)
Does that mean you're now back onto booting PPC AIX?
ATB,
Mark.
Am 26.11.2010 um 10:53 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
Starting with this revision, qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false' should take you to the Forth prompt. Have fun, Andreas
Great work! :)
Does that mean you're now back onto booting PPC AIX?
Thanks.
No, not yet. I did some of the cleanups I announced first and ppc64 is not in a booting state yet. It hangs after "Trying cd:,\:tbxi". Right now I'm trying to figure out why Blue is having troubles compiling.
I've also been investigating why Haiku hangs again. http://dev.haiku-os.org/ticket/6071#comment:3 It hangs while setting up the segment registers (mtsrin).
I noticed that Haiku uses the set-callback ciface method shortly before, but it appears that we only save the callback-function in forth/system/ciface.fs and - according to grep - never use it elsewhere. Shouldn't every ofmem function check if we have a non-zero callback- function (how? Cf. below) and then call that instead?
variable callback-function
: set-callback ( newfunc -- oldfunc ) callback-function @ swap callback-function ! ;
For AIX I'm looking into the machine support: I noticed there's provisions for the PReP machine but that errors out in QEMU so I couldn't test. I'm pretty sure that enabling AAPL stuff on PReP would be wrong though (is_apple() == 1). Also, a new IBM PReP machine may get contributed to QEMU, requiring adjustments in OpenBIOS. To emulate an IBM CHRP machine I need to fix ofmem and PCI code to handle 64-bit addresses.
Once that is done I'll probably get back to my RTAS investigations for AIX.
So, quite a long list ahead still. Which is why I'm a little impatient to get the next obvious bugs fixed while avoiding bikeshed discussions about possible cleanups. ;)
Andreas
Andreas Färber wrote:
No, not yet. I did some of the cleanups I announced first and ppc64 is not in a booting state yet. It hangs after "Trying cd:,\:tbxi". Right now I'm trying to figure out why Blue is having troubles compiling.
I've also been investigating why Haiku hangs again. http://dev.haiku-os.org/ticket/6071#comment:3 It hangs while setting up the segment registers (mtsrin).
Hmmm that's probably going to require more PPC-fu than I have.
I noticed that Haiku uses the set-callback ciface method shortly before, but it appears that we only save the callback-function in forth/system/ciface.fs and - according to grep - never use it elsewhere. Shouldn't every ofmem function check if we have a non-zero callback-function (how? Cf. below) and then call that instead?
variable callback-function
: set-callback ( newfunc -- oldfunc ) callback-function @ swap callback-function ! ;
AIUI the callback function provides a way for open firmware to call a function within the client image, e.g. allow a Forth function to invoke a "named" C function within the kernel image. I don't believe it is related to OFMEM at all.
For AIX I'm looking into the machine support: I noticed there's provisions for the PReP machine but that errors out in QEMU so I couldn't test. I'm pretty sure that enabling AAPL stuff on PReP would be wrong though (is_apple() == 1). Also, a new IBM PReP machine may get contributed to QEMU, requiring adjustments in OpenBIOS. To emulate an IBM CHRP machine I need to fix ofmem and PCI code to handle 64-bit addresses.
Once that is done I'll probably get back to my RTAS investigations for AIX.
So, quite a long list ahead still. Which is why I'm a little impatient to get the next obvious bugs fixed while avoiding bikeshed discussions about possible cleanups. ;)
Yes, I remember experiencing similar things with SPARC where 1 TODO item would end up becoming 3-4 TODO items as I found more dependent bugs :)
ATB,
Mark.
Am 30.11.2010 um 21:41 schrieb Mark Cave-Ayland:
Andreas Färber wrote:
I noticed that Haiku uses the set-callback ciface method shortly before, but it appears that we only save the callback-function in forth/system/ciface.fs and - according to grep - never use it elsewhere. Shouldn't every ofmem function check if we have a non-zero callback- function (how? Cf. below) and then call that instead? variable callback-function : set-callback ( newfunc -- oldfunc ) callback-function @ swap callback-function ! ;
AIUI the callback function provides a way for open firmware to call a function within the client image, e.g. allow a Forth function to invoke a "named" C function within the kernel image. I don't believe it is related to OFMEM at all.
The callback function apparently provides a way for the OS to take over memory management from OpenFirmware. Thus the relation to ofmem.
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir...
Haiku sets up a new page table based on the one from OpenFirmware, calls set-callback and expects to be asked for future memory allocations etc.
Andreas
Andreas Färber wrote:
The callback function apparently provides a way for the OS to take over memory management from OpenFirmware. Thus the relation to ofmem.
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir...
Haiku sets up a new page table based on the one from OpenFirmware, calls set-callback and expects to be asked for future memory allocations etc.
Andreas
That's really strange - that doesn't seem to match the spec at all, plus I don't see any mention of callbacks in the memory routines within the OpenBOOT source code? I'm really not convinced that code is doing what it thinks it should.
ATB,
Mark.
On Thu, Nov 25, 2010 at 10:04 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 25.11.2010 um 22:56 schrieb repository service:
Author: afaerber Date: Thu Nov 25 22:56:23 2010 New Revision: 969 URL: http://tracker.coreboot.org/trac/openbios/changeset/969
Log: ppc: Set up TOC base for ppc64
r2 points to TOC base, __toc_start + 0x8000. This value is stored as part of the function descriptor.
Include some related ELF sections in the linker script.
Cc: Alexander Graf agraf@suse.de Cc: Segher Boessenkool segher@kernel.crashing.org Signed-off-by: Andreas Färber andreas.faerber@web.de
Starting with this revision,
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
I still get this: GEN bootstrap.dict panic: segmentation violation at 0x9034862c dict=0x2aae90348010 here=0x2aae90348638(dict+0x628) pc=0x0(dict+0x6fcb7ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file
This happens on a 64 bit host, but not on a 32 bit host.
I built forthstrap on a 32 bit host to get further, but then I got: LINK openbios-qemu.elf libqemu.a(init.o): In function `go': /src/openbios-devel/obj-ppc64/../arch/ppc/qemu/init.c:533: undefined reference to `.call_elf' libqemu.a(main.o): In function `oldworld_boot': /src/openbios-devel/obj-ppc64/../arch/ppc/qemu/main.c:172: undefined reference to `.call_elf' libopenbios.a(elf_load.o): In function `elf_init_program': /src/openbios-devel/obj-ppc64/../libopenbios/elf_load.c:525: undefined reference to `.flush_icache_range' libopenbios.a(xcoff_load.o): In function `xcoff_init_program': /src/openbios-devel/obj-ppc64/../libopenbios/xcoff_load.c:118: undefined reference to `.flush_icache_range' libdrivers.a(timer.o): In function `udelay': /src/openbios-devel/obj-ppc64/../drivers/timer.c:91: undefined reference to `._wait_ticks' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /src/openbios-devel/obj-ppc64/../libgcc/__udivmoddi4.c:8: undefined reference to `.__divide_error'
This is with powerpc64-linux-gcc compiler: $ powerpc64-linux-gcc -v Using built-in specs. COLLECT_GCC=powerpc64-linux-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc64-linux/4.6.0/lto-wrapper Target: powerpc64-linux Configured with: ../configure --target=powerpc64-linux --enable-targets=powerpc64-linux --disable-nls --disable-threads --enable-languages=c --disable-shared --disable-libssp --disable-multilib --disable-decimal-float Thread model: single gcc version 4.6.0 20100925 (experimental) (GCC)
Am 26.11.2010 um 20:52 schrieb Blue Swirl:
On Thu, Nov 25, 2010 at 10:04 PM, Andreas Färber <andreas.faerber@web.de
wrote: Starting with [r969],
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
I still get this: GEN bootstrap.dict panic: segmentation violation at 0x9034862c dict=0x2aae90348010 here=0x2aae90348638(dict+0x628) pc=0x0(dict +0x6fcb7ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file
This happens on a 64 bit host, but not on a 32 bit host.
So I guess it might be an issue with the HOST_EQUALS_NATIVE_BITWIDTH path? The addresses are not confined to lower 32 bits so cannot be saved in ucells.
I built forthstrap on a 32 bit host to get further, but then I got: LINK openbios-qemu.elf libqemu.a(init.o): In function `go': /src/openbios-devel/obj-ppc64/../arch/ppc/qemu/init.c:533: undefined reference to `.call_elf'
[snip]
Sounds as if -m32 or the like is being passed to powerpc64-linux-ld? Dotted symbols only get generated for ppc64 target.
This is with powerpc64-linux-gcc compiler: $ powerpc64-linux-gcc -v Using built-in specs. COLLECT_GCC=powerpc64-linux-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc64-linux/4.6.0/lto- wrapper Target: powerpc64-linux Configured with: ../configure --target=powerpc64-linux --enable-targets=powerpc64-linux --disable-nls --disable-threads --enable-languages=c --disable-shared --disable-libssp --disable-multilib --disable-decimal-float Thread model: single gcc version 4.6.0 20100925 (experimental) (GCC)
I used:
$ powerpc64-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=powerpc64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/Users/andreas/QEMU/OpenBIOS/bin/libexec/gcc/ powerpc64-linux-gnu/4.5.1/lto-wrapper Target: powerpc64-linux-gnu Configured with: ../gcc-4.5.1/configure --prefix=/Users/andreas/QEMU/ OpenBIOS/bin --target=powerpc64-linux-gnu --enable-targets=all -- disable-nls --disable-threads --enable-languages=c --disable-shared -- disable-libssp --disable-decimal-float --disable-libmudflap --disable- libgomp --without-headers --enable-checking=release --with-gmp=/Users/ andreas/QEMU/OpenBIOS/bin --with-mpfr=/Users/andreas/QEMU/OpenBIOS/bin Thread model: single gcc version 4.5.1 (GCC)
Same with powerpc64-linux-gcc 4.5.1 on Darwin/x86. binutils are 2.20.1.
Andreas
On Sat, Nov 27, 2010 at 1:16 AM, Andreas Färber andreas.faerber@web.de wrote:
Am 26.11.2010 um 20:52 schrieb Blue Swirl:
On Thu, Nov 25, 2010 at 10:04 PM, Andreas Färber andreas.faerber@web.de wrote:
Starting with [r969],
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
I still get this: GEN bootstrap.dict panic: segmentation violation at 0x9034862c dict=0x2aae90348010 here=0x2aae90348638(dict+0x628) pc=0x0(dict+0x6fcb7ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file
This happens on a 64 bit host, but not on a 32 bit host.
So I guess it might be an issue with the HOST_EQUALS_NATIVE_BITWIDTH path? The addresses are not confined to lower 32 bits so cannot be saved in ucells.
I built forthstrap on a 32 bit host to get further, but then I got: LINK openbios-qemu.elf libqemu.a(init.o): In function `go': /src/openbios-devel/obj-ppc64/../arch/ppc/qemu/init.c:533: undefined reference to `.call_elf'
[snip]
Sounds as if -m32 or the like is being passed to powerpc64-linux-ld? Dotted symbols only get generated for ppc64 target.
No, LINK equals to (with V=1):
powerpc64-linux-ld --warn-common -N -T ../arch/ppc64/qemu/ldscript -o openbios-qemu.elf.nostrip --whole-archive target/arch/ppc/qemu/start.o target/arch/ppc/timebase.o libqemu.a libbootstrap.a libopenbios.a libpackages.a libdrivers.a libfs.a liblibc.a libgcc.a
This is with powerpc64-linux-gcc compiler: $ powerpc64-linux-gcc -v Using built-in specs. COLLECT_GCC=powerpc64-linux-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc64-linux/4.6.0/lto-wrapper Target: powerpc64-linux Configured with: ../configure --target=powerpc64-linux --enable-targets=powerpc64-linux --disable-nls --disable-threads --enable-languages=c --disable-shared --disable-libssp --disable-multilib --disable-decimal-float Thread model: single gcc version 4.6.0 20100925 (experimental) (GCC)
I used:
$ powerpc64-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=powerpc64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/Users/andreas/QEMU/OpenBIOS/bin/libexec/gcc/powerpc64-linux-gnu/4.5.1/lto-wrapper Target: powerpc64-linux-gnu Configured with: ../gcc-4.5.1/configure --prefix=/Users/andreas/QEMU/OpenBIOS/bin --target=powerpc64-linux-gnu --enable-targets=all --disable-nls --disable-threads --enable-languages=c --disable-shared --disable-libssp --disable-decimal-float --disable-libmudflap --disable-libgomp --without-headers --enable-checking=release --with-gmp=/Users/andreas/QEMU/OpenBIOS/bin --with-mpfr=/Users/andreas/QEMU/OpenBIOS/bin Thread model: single gcc version 4.5.1 (GCC)
Same with powerpc64-linux-gcc 4.5.1 on Darwin/x86. binutils are 2.20.1.
$ powerpc64-linux-ld -V GNU ld (GNU Binutils) 2.20.1.20100303 Supported emulations: elf64ppc elf32ppclinux elf32ppc elf32ppcsim
Am 27.11.2010 um 11:22 schrieb Blue Swirl:
On Sat, Nov 27, 2010 at 1:16 AM, Andreas Färber <andreas.faerber@web.de
wrote: Am 26.11.2010 um 20:52 schrieb Blue Swirl:
On Thu, Nov 25, 2010 at 10:04 PM, Andreas Färber <andreas.faerber@web.de
wrote:
Starting with [r969],
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
I still get this: GEN bootstrap.dict panic: segmentation violation at 0x9034862c dict=0x2aae90348010 here=0x2aae90348638(dict+0x628) pc=0x0(dict+0x6fcb7ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file
This happens on a 64 bit host, but not on a 32 bit host.
So I guess it might be an issue with the HOST_EQUALS_NATIVE_BITWIDTH path? The addresses are not confined to lower 32 bits so cannot be saved in ucells.
I built forthstrap on a 32 bit host to get further, but then I got: LINK openbios-qemu.elf libqemu.a(init.o): In function `go': /src/openbios-devel/obj-ppc64/../arch/ppc/qemu/init.c:533: undefined reference to `.call_elf'
[snip]
Sounds as if -m32 or the like is being passed to powerpc64-linux- ld? Dotted symbols only get generated for ppc64 target.
No, LINK equals to (with V=1):
powerpc64-linux-ld --warn-common -N -T ../arch/ppc64/qemu/ldscript -o openbios-qemu.elf.nostrip --whole-archive target/arch/ppc/qemu/start.o target/arch/ppc/timebase.o libqemu.a libbootstrap.a libopenbios.a libpackages.a libdrivers.a libfs.a liblibc.a libgcc.a
Ah, right, it would've warned about architecture mismatch then. What about CC for start.o? And could you try 4.5.1 to rule out your 4.6 snapshot? I'll try if Darwin/ppc64 works.
Andreas
On Sat, Nov 27, 2010 at 10:36 AM, Andreas Färber andreas.faerber@web.de wrote:
Am 27.11.2010 um 11:22 schrieb Blue Swirl:
On Sat, Nov 27, 2010 at 1:16 AM, Andreas Färber andreas.faerber@web.de wrote:
Am 26.11.2010 um 20:52 schrieb Blue Swirl:
On Thu, Nov 25, 2010 at 10:04 PM, Andreas Färber andreas.faerber@web.de wrote:
Starting with [r969],
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
I still get this: GEN bootstrap.dict panic: segmentation violation at 0x9034862c dict=0x2aae90348010 here=0x2aae90348638(dict+0x628) pc=0x0(dict+0x6fcb7ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file
This happens on a 64 bit host, but not on a 32 bit host.
So I guess it might be an issue with the HOST_EQUALS_NATIVE_BITWIDTH path? The addresses are not confined to lower 32 bits so cannot be saved in ucells.
I built forthstrap on a 32 bit host to get further, but then I got: LINK openbios-qemu.elf libqemu.a(init.o): In function `go': /src/openbios-devel/obj-ppc64/../arch/ppc/qemu/init.c:533: undefined reference to `.call_elf'
[snip]
Sounds as if -m32 or the like is being passed to powerpc64-linux-ld? Dotted symbols only get generated for ppc64 target.
No, LINK equals to (with V=1):
powerpc64-linux-ld --warn-common -N -T ../arch/ppc64/qemu/ldscript -o openbios-qemu.elf.nostrip --whole-archive target/arch/ppc/qemu/start.o target/arch/ppc/timebase.o libqemu.a libbootstrap.a libopenbios.a libpackages.a libdrivers.a libfs.a liblibc.a libgcc.a
Ah, right, it would've warned about architecture mismatch then. What about CC for start.o? And could you try 4.5.1 to rule out your 4.6 snapshot? I'll try if Darwin/ppc64 works.
It looks like GLOBL macro is not correct. With this patch (using Linux arch/powerpc/include/asm/ppc_asm.h except for the .sections which don't work for some reason), the link succeeds: diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 4b6df3f..8439542 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -285,14 +285,13 @@ call_isi_exception: exception_return: EXCEPTION_EPILOGUE
- .globl __divide_error -__divide_error: +GLOBL(__divide_error): trap_error: mflr r3 b BRANCH_LABEL(unexpected_excep)
VECTOR( 0x100, "SRE" ): - b _entry + b BRANCH_LABEL(_entry)
ILLEGAL_VECTOR( 0x200 )
@@ -358,7 +357,7 @@ VECTOR( 0x2200, "ISI_64" ): GLOBL(__vectors_end):
/************************************************************************/ -/* entry */ +/* _entry */ /************************************************************************/
GLOBL(_entry): @@ -453,7 +452,7 @@ GLOBL(_entry): #endif
bl BRANCH_LABEL(setup_mmu) - bl BRANCH_LABEL(entry) + bl BRANCH_LABEL(_entry) 1: nop b 1b
@@ -678,4 +677,4 @@ compute_ramsize:
/* Hard reset vector */ .section .romentry,"ax" - bl _entry + bl BRANCH_LABEL(_entry) diff --git a/include/arch/ppc/asmdefs.h b/include/arch/ppc/asmdefs.h index 9c85ea5..b2cfa48 100644 --- a/include/arch/ppc/asmdefs.h +++ b/include/arch/ppc/asmdefs.h @@ -110,8 +110,25 @@ #endif
#ifndef __darwin__ +#ifdef __powerpc64__ +#define XGLUE(a,b) a##b +#define GLUE(a,b) XGLUE(a,b) + +#define GLOBL(name) \ + .align 2 ; \ + .globl name; \ + .globl GLUE(.,name); \ +name: \ + .quad GLUE(.,name); \ + .quad .TOC.@tocbase; \ + .quad 0; \ + .type GLUE(.,name),@function; \ +GLUE(.,name) +#define EXTERN(name) _##name +#else #define GLOBL( name ) .globl name ; name #define EXTERN( name ) name +#endif #else /* an underscore is needed on Darwin */ #define GLOBL( name ) .globl _##name ; name: ; _##name
I don't get the Forth prompt, screen remains black. According to qemu.log, execution stops at infinite loop: IN: .printk 0x00000000fff087c8: addi r1,r1,1168 0x00000000fff087cc: mr r3,r30 0x00000000fff087d0: b 0xfff29e10
IN: _restgpr0_29 0x00000000fff29e10: ld r0,16(r1) 0x00000000fff29e14: ld r29,-24(r1) 0x00000000fff29e18: mtlr r0 0x00000000fff29e1c: ld r30,-16(r1) 0x00000000fff29e20: ld r31,-8(r1) 0x00000000fff29e24: blr
IN: .unexpected_excep 0x00000000fff08db4: nop 0x00000000fff08db8: b 0xfff08db8
IN: .unexpected_excep 0x00000000fff08db8: b 0xfff08db8
Am 27.11.2010 um 16:03 schrieb Blue Swirl:
On Sat, Nov 27, 2010 at 10:36 AM, Andreas Färber <andreas.faerber@web.de
wrote: Am 27.11.2010 um 11:22 schrieb Blue Swirl:
On Sat, Nov 27, 2010 at 1:16 AM, Andreas Färber <andreas.faerber@web.de
wrote:
Am 26.11.2010 um 20:52 schrieb Blue Swirl:
On Thu, Nov 25, 2010 at 10:04 PM, Andreas Färber andreas.faerber@web.de wrote:
Starting with [r969],
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
I built forthstrap on a 32 bit host to get further, but then I got: LINK openbios-qemu.elf libqemu.a(init.o): In function `go': /src/openbios-devel/obj-ppc64/../arch/ppc/qemu/init.c:533: undefined reference to `.call_elf'
[snip]
Sounds as if -m32 or the like is being passed to powerpc64-linux- ld? Dotted symbols only get generated for ppc64 target.
No, LINK equals to (with V=1):
powerpc64-linux-ld --warn-common -N -T ../arch/ppc64/qemu/ldscript -o openbios-qemu.elf.nostrip --whole-archive target/arch/ppc/qemu/ start.o target/arch/ppc/timebase.o libqemu.a libbootstrap.a libopenbios.a libpackages.a libdrivers.a libfs.a liblibc.a libgcc.a
Ah, right, it would've warned about architecture mismatch then. What about CC for start.o? And could you try 4.5.1 to rule out your 4.6 snapshot? I'll try if Darwin/ppc64 works.
It looks like GLOBL macro is not correct.
Yeah, I stumbled across that for call_elf(), too.
With this patch (using Linux arch/powerpc/include/asm/ppc_asm.h except for the .sections which don't work for some reason),
(the Linux macros force .text while we use .text.vectors for placement; .opd should be right though)
the link succeeds: diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 4b6df3f..8439542 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -285,14 +285,13 @@ call_isi_exception: exception_return: EXCEPTION_EPILOGUE
.globl __divide_error-__divide_error: +GLOBL(__divide_error):
Acked.
trap_error: mflr r3 b BRANCH_LABEL(unexpected_excep)
VECTOR( 0x100, "SRE" ):
b _entry
b BRANCH_LABEL(_entry)ILLEGAL_VECTOR( 0x200 )
@@ -358,7 +357,7 @@ VECTOR( 0x2200, "ISI_64" ): GLOBL(__vectors_end):
/ ************************************************************************/ -/* entry */ +/* _entry */ / ************************************************************************/
GLOBL(_entry): @@ -453,7 +452,7 @@ GLOBL(_entry): #endif
bl BRANCH_LABEL(setup_mmu)
bl BRANCH_LABEL(entry)
bl BRANCH_LABEL(_entry)
Nack, infinite recursion. Original code is right, unless .entry gets hidden by the compiler somehow. If the latter, we need to dereference the function descriptor instead and do a bctrl.
1: nop b 1b
@@ -678,4 +677,4 @@ compute_ramsize:
/* Hard reset vector */ .section .romentry,"ax"
bl _entry
bl BRANCH_LABEL(_entry)diff --git a/include/arch/ppc/asmdefs.h b/include/arch/ppc/asmdefs.h index 9c85ea5..b2cfa48 100644 --- a/include/arch/ppc/asmdefs.h +++ b/include/arch/ppc/asmdefs.h @@ -110,8 +110,25 @@ #endif
#ifndef __darwin__ +#ifdef __powerpc64__ +#define XGLUE(a,b) a##b +#define GLUE(a,b) XGLUE(a,b)
+#define GLOBL(name) \
.align 2 ; \.globl name; \.globl GLUE(.,name); \+name: \
.quad GLUE(.,name); \.quad .TOC.@tocbase; \.quad 0; \.type GLUE(.,name),@function; \+GLUE(.,name)
Doesn't look right without the sections... or at least strange.
+#define EXTERN(name) _##name +#else #define GLOBL( name ) .globl name ; name #define EXTERN( name ) name +#endif #else /* an underscore is needed on Darwin */ #define GLOBL( name ) .globl _##name ; name: ; _##name
I was rather considering to add a new macro for externally called functions like call_elf() and the ciface, i.e. leave GLOBL() as it is with compatibility stuff and add a new GLOBAL() macro for instance that does the ppc64 .opd, using our GLOBL() internally. The advantage would be that we don't need to clutter start.S with unneeded BRANCH_LABEL() calls. What do you think?
Andreas
On Sat, Nov 27, 2010 at 6:42 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 27.11.2010 um 16:03 schrieb Blue Swirl:
On Sat, Nov 27, 2010 at 10:36 AM, Andreas Färber andreas.faerber@web.de wrote:
Am 27.11.2010 um 11:22 schrieb Blue Swirl:
On Sat, Nov 27, 2010 at 1:16 AM, Andreas Färber andreas.faerber@web.de wrote:
Am 26.11.2010 um 20:52 schrieb Blue Swirl:
On Thu, Nov 25, 2010 at 10:04 PM, Andreas Färber andreas.faerber@web.de wrote: > > Starting with [r969], > > qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env > 'auto-boot?=false' > > should take you to the Forth prompt.
I built forthstrap on a 32 bit host to get further, but then I got: LINK openbios-qemu.elf libqemu.a(init.o): In function `go': /src/openbios-devel/obj-ppc64/../arch/ppc/qemu/init.c:533: undefined reference to `.call_elf'
[snip]
Sounds as if -m32 or the like is being passed to powerpc64-linux-ld? Dotted symbols only get generated for ppc64 target.
No, LINK equals to (with V=1):
powerpc64-linux-ld --warn-common -N -T ../arch/ppc64/qemu/ldscript -o openbios-qemu.elf.nostrip --whole-archive target/arch/ppc/qemu/start.o target/arch/ppc/timebase.o libqemu.a libbootstrap.a libopenbios.a libpackages.a libdrivers.a libfs.a liblibc.a libgcc.a
Ah, right, it would've warned about architecture mismatch then. What about CC for start.o? And could you try 4.5.1 to rule out your 4.6 snapshot? I'll try if Darwin/ppc64 works.
It looks like GLOBL macro is not correct.
Yeah, I stumbled across that for call_elf(), too.
With this patch (using Linux arch/powerpc/include/asm/ppc_asm.h except for the .sections which don't work for some reason),
(the Linux macros force .text while we use .text.vectors for placement; .opd should be right though)
But then there are strange errors: ../arch/ppc/qemu/start.S: Assembler messages: ../arch/ppc/qemu/start.S:293: Error: invalid segment ".opd"
the link succeeds: diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 4b6df3f..8439542 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -285,14 +285,13 @@ call_isi_exception: exception_return: EXCEPTION_EPILOGUE
- .globl __divide_error
-__divide_error: +GLOBL(__divide_error):
Acked.
trap_error: mflr r3 b BRANCH_LABEL(unexpected_excep)
VECTOR( 0x100, "SRE" ):
- b _entry
- b BRANCH_LABEL(_entry)
ILLEGAL_VECTOR( 0x200 )
@@ -358,7 +357,7 @@ VECTOR( 0x2200, "ISI_64" ): GLOBL(__vectors_end):
/************************************************************************/ -/* entry */ +/* _entry */ /************************************************************************/
GLOBL(_entry): @@ -453,7 +452,7 @@ GLOBL(_entry): #endif
bl BRANCH_LABEL(setup_mmu)
- bl BRANCH_LABEL(entry)
- bl BRANCH_LABEL(_entry)
Nack, infinite recursion. Original code is right, unless .entry gets hidden by the compiler somehow. If the latter, we need to dereference the function descriptor instead and do a bctrl.
But then there would be a link time conflict with entry() in arch/ppc/qemu/init.c.
1: nop b 1b
@@ -678,4 +677,4 @@ compute_ramsize:
/* Hard reset vector */ .section .romentry,"ax"
- bl _entry
- bl BRANCH_LABEL(_entry)
diff --git a/include/arch/ppc/asmdefs.h b/include/arch/ppc/asmdefs.h index 9c85ea5..b2cfa48 100644 --- a/include/arch/ppc/asmdefs.h +++ b/include/arch/ppc/asmdefs.h @@ -110,8 +110,25 @@ #endif
#ifndef __darwin__ +#ifdef __powerpc64__ +#define XGLUE(a,b) a##b +#define GLUE(a,b) XGLUE(a,b)
+#define GLOBL(name) \
- .align 2 ; \
- .globl name; \
- .globl GLUE(.,name); \
+name: \
- .quad GLUE(.,name); \
- .quad .TOC.@tocbase; \
- .quad 0; \
- .type GLUE(.,name),@function; \
+GLUE(.,name)
Doesn't look right without the sections... or at least strange.
+#define EXTERN(name) _##name +#else #define GLOBL( name ) .globl name ; name #define EXTERN( name ) name +#endif #else /* an underscore is needed on Darwin */ #define GLOBL( name ) .globl _##name ; name: ; _##name
I was rather considering to add a new macro for externally called functions like call_elf() and the ciface, i.e. leave GLOBL() as it is with compatibility stuff and add a new GLOBAL() macro for instance that does the ppc64 .opd, using our GLOBL() internally. The advantage would be that we don't need to clutter start.S with unneeded BRANCH_LABEL() calls. What do you think?
I think that's also the approach Linux uses. I don't have preference.
Am 27.11.2010 um 20:02 schrieb Blue Swirl:
On Sat, Nov 27, 2010 at 6:42 PM, Andreas Färber <andreas.faerber@web.de
wrote: Am 27.11.2010 um 16:03 schrieb Blue Swirl:
diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 4b6df3f..8439542 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S
@@ -453,7 +452,7 @@ GLOBL(_entry): #endif
bl BRANCH_LABEL(setup_mmu)
bl BRANCH_LABEL(entry)
bl BRANCH_LABEL(_entry)Nack, infinite recursion. Original code is right, unless .entry gets hidden by the compiler somehow. If the latter, we need to dereference the function descriptor instead and do a bctrl.
But then there would be a link time conflict with entry() in arch/ppc/qemu/init.c.
This is in fact supposed to branch to that entry(). :)
Please post the conflict you get.
Andreas
On Sat, Nov 27, 2010 at 9:46 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 27.11.2010 um 20:02 schrieb Blue Swirl:
On Sat, Nov 27, 2010 at 6:42 PM, Andreas Färber andreas.faerber@web.de wrote:
Am 27.11.2010 um 16:03 schrieb Blue Swirl:
diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 4b6df3f..8439542 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S
@@ -453,7 +452,7 @@ GLOBL(_entry): #endif
bl BRANCH_LABEL(setup_mmu)
- bl BRANCH_LABEL(entry)
- bl BRANCH_LABEL(_entry)
Nack, infinite recursion. Original code is right, unless .entry gets hidden by the compiler somehow. If the latter, we need to dereference the function descriptor instead and do a bctrl.
But then there would be a link time conflict with entry() in arch/ppc/qemu/init.c.
This is in fact supposed to branch to that entry(). :)
That could explain the black screen. Now I get to the OpenBIOS prompt (with the additional patch I sent).
This should also fix linker errors observed by Blue.
Cc: Blue Swirl blauwirbel@gmail.com Cc: Alexander Graf agraf@suse.de Signed-off-by: Andreas Färber andreas.faerber@web.de --- arch/ppc/qemu/start.S | 7 +++---- include/arch/ppc/asmdefs.h | 18 ++++++++++++++++++ 2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 4b6df3f..76ef6d6 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -285,8 +285,7 @@ call_isi_exception: exception_return: EXCEPTION_EPILOGUE
- .globl __divide_error -__divide_error: +GLOBL(__divide_error): trap_error: mflr r3 b BRANCH_LABEL(unexpected_excep) @@ -473,7 +472,7 @@ saved_stack: .long 0 .previous /* void call_elf( arg1, arg2, entry ) */ -GLOBL(call_elf): +_GLOBAL(call_elf): mflr r0 stwu r1,-16(r1) stw r0,20(r1) @@ -633,7 +632,7 @@ GLOBL(of_rtas_end): #define LG_CACHE_LINE_SIZE 5
/* flush_icache_range( unsigned long start, unsigned long stop) */ -GLOBL(flush_icache_range): +_GLOBAL(flush_icache_range): li r5,CACHE_LINE_SIZE-1 andc r3,r3,r5 subf r4,r3,r4 diff --git a/include/arch/ppc/asmdefs.h b/include/arch/ppc/asmdefs.h index 9c85ea5..05a89b2 100644 --- a/include/arch/ppc/asmdefs.h +++ b/include/arch/ppc/asmdefs.h @@ -118,6 +118,24 @@ #define EXTERN( name ) _##name #endif
+#if defined(__powerpc64__) && !defined(__darwin__) +#define _GLOBAL(name) \ + .align 2 ; \ + .section ".opd", "aw" ; \ + .globl name ; \ + .globl .##name ; \ + name: \ + .quad .##name ; \ + .quad .TOC.@tocbase ; \ + .quad 0 ; \ + .previous ; \ + .type .##name, @function ; \ + .##name +#else +#define _GLOBAL(name) \ + GLOBL(name) +#endif + #define BIT(n) (1<<(31-(n)))
#endif /* _H_ASMDEFS */
On Sun, Nov 28, 2010 at 12:58 AM, Andreas Färber andreas.faerber@web.de wrote:
This should also fix linker errors observed by Blue.
Better, but still: LINK openbios-qemu.elf libdrivers.a(timer.o): In function `udelay': /src/openbios-devel/obj-ppc64/../drivers/timer.c:91: undefined reference to `._wait_ticks' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /src/openbios-devel/obj-ppc64/../libgcc/__udivmoddi4.c:8: undefined reference to `.__divide_error'
Cc: Blue Swirl blauwirbel@gmail.com Cc: Alexander Graf agraf@suse.de Signed-off-by: Andreas Färber andreas.faerber@web.de
arch/ppc/qemu/start.S | 7 +++---- include/arch/ppc/asmdefs.h | 18 ++++++++++++++++++ 2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 4b6df3f..76ef6d6 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -285,8 +285,7 @@ call_isi_exception: exception_return: EXCEPTION_EPILOGUE
- .globl __divide_error
-__divide_error: +GLOBL(__divide_error):
Shouldn't this be _GLOBAL?
trap_error: mflr r3 b BRANCH_LABEL(unexpected_excep) @@ -473,7 +472,7 @@ saved_stack: .long 0 .previous /* void call_elf( arg1, arg2, entry ) */ -GLOBL(call_elf): +_GLOBAL(call_elf): mflr r0 stwu r1,-16(r1) stw r0,20(r1) @@ -633,7 +632,7 @@ GLOBL(of_rtas_end): #define LG_CACHE_LINE_SIZE 5
/* flush_icache_range( unsigned long start, unsigned long stop) */ -GLOBL(flush_icache_range): +_GLOBAL(flush_icache_range): li r5,CACHE_LINE_SIZE-1 andc r3,r3,r5 subf r4,r3,r4 diff --git a/include/arch/ppc/asmdefs.h b/include/arch/ppc/asmdefs.h index 9c85ea5..05a89b2 100644 --- a/include/arch/ppc/asmdefs.h +++ b/include/arch/ppc/asmdefs.h @@ -118,6 +118,24 @@ #define EXTERN( name ) _##name #endif
+#if defined(__powerpc64__) && !defined(__darwin__) +#define _GLOBAL(name) \
- .align 2 ; \
- .section ".opd", "aw" ; \
- .globl name ; \
- .globl .##name ; \
- name: \
- .quad .##name ; \
- .quad .TOC.@tocbase ; \
- .quad 0 ; \
- .previous ; \
- .type .##name, @function ; \
- .##name
It's strange that now there are no errors about .opd section. I'm pretty sure this is close to what I tried earlier.
+#else +#define _GLOBAL(name) \
- GLOBL(name)
+#endif
#define BIT(n) (1<<(31-(n)))
#endif /* _H_ASMDEFS */
1.7.3
Am 28.11.2010 um 09:20 schrieb Blue Swirl:
On Sun, Nov 28, 2010 at 12:58 AM, Andreas Färber <andreas.faerber@web.de
wrote: This should also fix linker errors observed by Blue.
Better, but still: LINK openbios-qemu.elf libdrivers.a(timer.o): In function `udelay': /src/openbios-devel/obj-ppc64/../drivers/timer.c:91: undefined reference to `._wait_ticks' libgcc.a(__udivmoddi4.o): In function `__udivmoddi4': /src/openbios-devel/obj-ppc64/../libgcc/__udivmoddi4.c:8: undefined reference to `.__divide_error'
Cc: Blue Swirl blauwirbel@gmail.com Cc: Alexander Graf agraf@suse.de Signed-off-by: Andreas Färber andreas.faerber@web.de
arch/ppc/qemu/start.S | 7 +++---- include/arch/ppc/asmdefs.h | 18 ++++++++++++++++++ 2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 4b6df3f..76ef6d6 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -285,8 +285,7 @@ call_isi_exception: exception_return: EXCEPTION_EPILOGUE
.globl __divide_error-__divide_error: +GLOBL(__divide_error):
Shouldn't this be _GLOBAL?
Yes, it should since it's called from C code in libgcc/. I somehow assumed it would be called from assembly.
Thanks, applied in r976.
Andreas
Am 26.11.2010 um 20:52 schrieb Blue Swirl:
On Thu, Nov 25, 2010 at 10:04 PM, Andreas Färber <andreas.faerber@web.de
wrote: Am 25.11.2010 um 22:56 schrieb repository service:
Author: afaerber Date: Thu Nov 25 22:56:23 2010 New Revision: 969 URL: http://tracker.coreboot.org/trac/openbios/changeset/969
Log: ppc: Set up TOC base for ppc64
r2 points to TOC base, __toc_start + 0x8000. This value is stored as part of the function descriptor.
Include some related ELF sections in the linker script.
Cc: Alexander Graf agraf@suse.de Cc: Segher Boessenkool segher@kernel.crashing.org Signed-off-by: Andreas Färber andreas.faerber@web.de
Starting with this revision,
qemu-system-ppc64 -bios .../obj-ppc64/openbios-qemu.elf -prom-env 'auto-boot?=false'
should take you to the Forth prompt.
I still get this: GEN bootstrap.dict panic: segmentation violation at 0x9034862c dict=0x2aae90348010 here=0x2aae90348638(dict+0x628) pc=0x0(dict +0x6fcb7ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file
This happens on a 64 bit host, but not on a 32 bit host.
Same here:
$ make V=1 HOSTCC="gcc -arch ppc64" [...] ./forthstrap -I../forth/bootstrap/ -I../forth/bootstrap/ -I../forth/ lib/ -I../forth/device/ -I../forth/debugging/ -I../forth/admin/ -I../ forth/util/ -I../forth/packages/ -I../forth/system/ -I../libopenbios/ - I../packages/ -I../drivers/ -I../arch/ppc/ -I./forth -D bootstrap.dict -c bootstrap.dict-console.log ../forth/bootstrap/start.fs panic: segmentation violation at 0x30061c dict=0x100300000 here=0x100300628(dict+0x628) pc=0x0(dict+0xffd00000) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file make: *** [bootstrap.dict] Error 1
Changing config.mak to use - DNATIVE_BITWIDTH_SMALLER_THAN_HOST_BITWIDTH (despite ppc64 being 64- bit) fixes this.
This boils down to my remarks that this config mechanism is not purely about bitwidth but also about cell size. Not sure how to fix properly...
Andreas
-
Andreas Färber -
Blue Swirl -
Mark Cave-Ayland -
repository service