OpenBIOS November 2010

openbios@openbios.org

10 participants
59 discussions

[commit] r946 - trunk/openbios-devel/forth/admin
by repository service 06 Nov '10

06 Nov '10

Author: afaerber Date: Sat Nov 6 02:17:02 2010 New Revision: 946 URL: http://tracker.coreboot.org/trac/openbios/changeset/946 Log: Optimize .properties array display by 0.r Introduce a 0.r word, suggested by Segher. Optimize r890 by using this helper. v4: * Replace ." " by space word, suggested by Segher. Signed-off-by: Segher Boessenkool <segher(a)kernel.crashing.org> Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Acked-by: Segher Boessenkool <segher(a)kernel.crashing.org> Modified: trunk/openbios-devel/forth/admin/devices.fs Modified: trunk/openbios-devel/forth/admin/devices.fs ============================================================================== --- trunk/openbios-devel/forth/admin/devices.fs Tue Nov 2 23:16:32 2010 (r945) +++ trunk/openbios-devel/forth/admin/devices.fs Sat Nov 6 02:17:02 2010 (r946) @@ -276,6 +276,11 @@ . ; +\ Print a number zero-padded +: 0.r ( u minlen -- ) + 0 swap <# 1 ?do # loop #s #> type +; + : .p-bytes? ( data len -- 1 | data len 0 ) ." -- " dup . ." : " swap >r 0 @@ -283,7 +288,7 @@ dup r@ + c@ ( len n ch ) - pocket tohexstr dup 2 <> if ." 0" then type ." " + 2 0.r space 1+ repeat 2drop r> drop 1

1 0

[PATCH 0/4] Paving the way for ppc64
by Andreas Färber 02 Nov '10

02 Nov '10

Hello, With these patches and a hack such as the following I am able to build and debug into ppc64 OpenBIOS: diff --git a/kernel/internal.c b/kernel/internal.c index 91ab440..d1fd850 100644 --- a/kernel/internal.c +++ b/kernel/internal.c @@ -50,7 +50,11 @@ char xtname[MAXNFALEN]; /* instead of pointing to an explicit 0 variable we * point behind the pointer. */ +#ifdef __powerpc64__ +static ucell t[] = { DOCOL, 0, 0, 0 }; +#else static ucell t[] = { DOCOL, 0, (ucell)(t+3), 0 }; +#endif static ucell *trampoline = t; #endif This hack does not matter yet as we don't return from setup_mmu() anyway. I have some more fixes related to exception preamble and epilogue cooking but that needs some more thought for a sane interim solution. Regards, Andreas Andreas Färber (4): ppc: Use vector-local version of exception_return ppc64: Don't disable SF bit ppc: Introduce load() macro for ppc64 ppc: Avoid vector overlap on ppc64 arch/ppc/qemu/start.S | 76 +++++++++++++++++++++++++++++++------------------ 1 files changed, 48 insertions(+), 28 deletions(-) -- 1.7.3

2 10

[commit] r945 - trunk/openbios-devel/arch/ppc/qemu
by repository service 02 Nov '10

02 Nov '10

Author: afaerber Date: Tue Nov 2 23:16:32 2010 New Revision: 945 URL: http://tracker.coreboot.org/trac/openbios/changeset/945 Log: ppc: Avoid vector overlap on ppc64 Due to the 64-bit immediate load sequence, the ISI and DSI vectors are two instructions too long for the respective segment exceptions. Move the code to the start of the relocated vector region and do a relative branch there. v2: * load() -> LOAD_REG_IMMEDIATE() Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Acked-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/start.S Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Tue Nov 2 23:13:24 2010 (r944) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Tue Nov 2 23:16:32 2010 (r945) @@ -186,6 +186,18 @@ 1: nop // b 1b +call_dsi_exception: + LOAD_REG_IMMEDIATE(r3, dsi_exception) + mtctr r3 + bctrl + b exception_return + +call_isi_exception: + LOAD_REG_IMMEDIATE(r3, isi_exception) + mtctr r3 + bctrl + b exception_return + exception_return: EXCEPTION_EPILOGUE @@ -202,17 +214,15 @@ VECTOR( 0x300, "DSI" ): EXCEPTION_PREAMBLE - LOAD_REG_IMMEDIATE(r3, dsi_exception) - mtctr r3 - bctrl - b exception_return + b call_dsi_exception + +ILLEGAL_VECTOR( 0x380 ) VECTOR( 0x400, "ISI" ): EXCEPTION_PREAMBLE - LOAD_REG_IMMEDIATE(r3, isi_exception) - mtctr r3 - bctrl - b exception_return + b call_isi_exception + +ILLEGAL_VECTOR( 0x480 ) ILLEGAL_VECTOR( 0x500 ) ILLEGAL_VECTOR( 0x600 )

1 0

[commit] r944 - in trunk/openbios-devel: arch/ppc/qemu include/arch/ppc
by repository service 02 Nov '10

02 Nov '10

Author: afaerber Date: Tue Nov 2 23:13:24 2010 New Revision: 944 URL: http://tracker.coreboot.org/trac/openbios/changeset/944 Log: ppc: Introduce LOAD_REG_IMMEDIATE() macro for ppc64 When loading the fw_cfg address with just lis, addi sequence, we get the high address bits as 0xffffffff on ppc64. Use the full double word immediate load sequence on ppc64. v2: * Rename from load() to LOAD_REG_IMMEDIATE() to match Linux. Suggested by Alex. * Move to ppc/asmdefs.h for future use elsewhere. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Acked-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/start.S trunk/openbios-devel/include/arch/ppc/asmdefs.h Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Tue Nov 2 23:09:31 2010 (r943) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Tue Nov 2 23:13:24 2010 (r944) @@ -202,16 +202,14 @@ VECTOR( 0x300, "DSI" ): EXCEPTION_PREAMBLE - lis r3,HA(dsi_exception) - addi r3,r3,LO(dsi_exception) + LOAD_REG_IMMEDIATE(r3, dsi_exception) mtctr r3 bctrl b exception_return VECTOR( 0x400, "ISI" ): EXCEPTION_PREAMBLE - lis r3,HA(isi_exception) - addi r3,r3,LO(isi_exception) + LOAD_REG_IMMEDIATE(r3, isi_exception) mtctr r3 bctrl b exception_return @@ -247,16 +245,14 @@ VECTOR( 0x2000, "DSI_64" ): EXCEPTION_PREAMBLE_64 - lis r3,HA(dsi_exception) - addi r3,r3,LO(dsi_exception) + LOAD_REG_IMMEDIATE(r3, dsi_exception) mtctr r3 bctrl EXCEPTION_EPILOGUE_64 VECTOR( 0x2200, "ISI_64" ): EXCEPTION_PREAMBLE_64 - lis r3,HA(isi_exception) - addi r3,r3,LO(isi_exception) + LOAD_REG_IMMEDIATE(r3, isi_exception) mtctr r3 bctrl EXCEPTION_EPILOGUE_64 @@ -278,8 +274,7 @@ /* copy exception vectors */ - lis r3,HA(__vectors) - addi r3,r3,LO(__vectors) + LOAD_REG_IMMEDIATE(r3, __vectors) li r4,0 li r5,__vectors_end - __vectors + 16 rlwinm r5,r5,0,0,28 @@ -378,22 +373,19 @@ stwu r1,-16(r1) stw r0,20(r1) mtlr r5 - lis r8,HA(saved_stack) - addi r8,r8,LO(saved_stack) // save our stack pointer + LOAD_REG_IMMEDIATE(r8, saved_stack) // save our stack pointer stw r1,0(r8) mfsdr1 r1 addi r1, r1, -32768 /* - 32 KiB exception stack */ addis r1, r1, -1 /* - 64 KiB stack */ - lis r5,HA(of_client_callback) - addi r5,r5,LO(of_client_callback) // r5 = callback + LOAD_REG_IMMEDIATE(r5, of_client_callback) // r5 = callback li r6,0 // r6 = address of client program arguments (unused) li r7,0 // r7 = length of client program arguments (unused) li r0,MSR_FP | MSR_ME | MSR_DR | MSR_IR mtmsr r0 blrl - lis r8,HA(saved_stack) - addi r8,r8,LO(saved_stack) // restore stack pointer + LOAD_REG_IMMEDIATE(r8, saved_stack) // restore stack pointer mr r1,r8 lwz r0,20(r1) mtlr r0 @@ -418,8 +410,7 @@ /* restore OF stack */ - lis r4,HA(saved_stack) - addi r4,r4,LO(saved_stack) + LOAD_REG_IMMEDIATE(r4, saved_stack) lwz r4,0(r4) stwu r4,-SAVE_SPACE(r4) @@ -564,12 +555,10 @@ #define FW_CFG_RAM_SIZE 0x03 compute_ramsize: - lis r9,HA(CFG_ADDR) - ori r9,r9,LO(CFG_ADDR) + LOAD_REG_IMMEDIATE(r9, CFG_ADDR) li r0,FW_CFG_RAM_SIZE sth r0,0(r9) - lis r9,HA(CFG_ADDR + 2) - ori r9,r9,LO(CFG_ADDR + 2) + LOAD_REG_IMMEDIATE(r9, CFG_ADDR + 2) lbz r1,0(r9) lbz r0,0(r9) slwi r0,r0,8 Modified: trunk/openbios-devel/include/arch/ppc/asmdefs.h ============================================================================== --- trunk/openbios-devel/include/arch/ppc/asmdefs.h Tue Nov 2 23:09:31 2010 (r943) +++ trunk/openbios-devel/include/arch/ppc/asmdefs.h Tue Nov 2 23:13:24 2010 (r944) @@ -75,6 +75,19 @@ /* MISC */ /************************************************************************/ +#ifdef __powerpc64__ +#define LOAD_REG_IMMEDIATE(D, x) \ + lis (D), (x)@highest ; \ + ori (D), (D), (x)@higher ; \ + sldi (D), (D), 32 ; \ + oris (D), (D), (x)@h ; \ + ori (D), (D), (x)@l +#else +#define LOAD_REG_IMMEDIATE(D, x) \ + lis (D), HA(x) ; \ + addi (D), (D), LO(x) +#endif + #ifndef __darwin__ #define GLOBL( name ) .globl name ; name #define EXTERN( name ) name

1 0

[commit] r943 - trunk/openbios-devel/arch/ppc/qemu
by repository service 02 Nov '10

02 Nov '10

Author: afaerber Date: Tue Nov 2 23:09:31 2010 New Revision: 943 URL: http://tracker.coreboot.org/trac/openbios/changeset/943 Log: ppc64: Don't disable SF bit Don't clear the MSR for the pure ppc64 version since it would disable Sixty Four bit mode as well. The MMU is supposed to be disabled by default. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Acked-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/start.S Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Tue Nov 2 23:07:27 2010 (r942) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Tue Nov 2 23:09:31 2010 (r943) @@ -268,10 +268,13 @@ /************************************************************************/ GLOBL(_entry): + +#ifndef __powerpc64__ /* clear MSR, disable MMU */ li r0,0 mtmsr r0 +#endif /* copy exception vectors */

1 0

[commit] r942 - trunk/openbios-devel/arch/ppc/qemu
by repository service 02 Nov '10

02 Nov '10

Author: afaerber Date: Tue Nov 2 23:07:27 2010 New Revision: 942 URL: http://tracker.coreboot.org/trac/openbios/changeset/942 Log: ppc: Use vector-local version of exception_return On ppc64 the high 32 address bits are clear, so ba's sign extension cannot be used to branch to the ROM version of exception_return. Use a relative branch to the relocated version instead. This fixes relocation linker errors for ppc64. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Acked-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/start.S Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Mon Nov 1 18:31:11 2010 (r941) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Tue Nov 2 23:07:27 2010 (r942) @@ -206,7 +206,7 @@ addi r3,r3,LO(dsi_exception) mtctr r3 bctrl - ba exception_return + b exception_return VECTOR( 0x400, "ISI" ): EXCEPTION_PREAMBLE @@ -214,7 +214,7 @@ addi r3,r3,LO(isi_exception) mtctr r3 bctrl - ba exception_return + b exception_return ILLEGAL_VECTOR( 0x500 ) ILLEGAL_VECTOR( 0x600 )

1 0

SOLVED: the mystery of Solaris on SPARC32 and the missing Forth arguments
by Mark Cave-Ayland 02 Nov '10

02 Nov '10

Hi folks, So I thought it may be interesting over the weekend to take a look and see how Solaris on SPARC32 is looking at the moment, and found that I was getting about as far as Artyom was, i.e. ufsboot dies after emitting this cryptic Forth statement with missing parameters: ['] find-device catch if 2drop true else current-device device-end then swap l! With gdb primed with a breakpoint set at obp_fortheval_v2() I was able to poke around and see what was happening at the time the call into OpenBIOS was being made. Nothing interesting there. But jumping back a frame showed some extra information being set in the o registers: (gdb) bt #0 obp_fortheval_v2 (str=0x1190d0 " ['] find-device catch if 2drop true else current-device device-end then swap l!") at ../arch/sparc32/romvec.c:424 #1 0x00113dd4 in ?? () #2 0x00113dd4 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) frame 1 #1 0x00113dd4 in ?? () (gdb) info regi ... o0 0x1190d0 1151184 o1 0x49 73 o2 0x1335c0 1258944 o3 0x130794 1247124 o4 0x0 0 o5 0x0 0 ... Okay; so let's take a look at what's in these o registers: (gdb) x/1s 0x1190d0 0x1190d0: " ['] find-device catch if 2drop true else current-device device-end then swap l!" (gdb) x/1s 0x1335c0 0x1335c0: "/iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d" (gdb) x/4xb 0x130794 0x130794: 0xff 0xff 0xff 0xff (gdb) Bingo! The missing parameters! Stepping back to just before where the code is invoked, I see this: 0x00113dac: sethi %hi(0x118c00), %g2 0x00113db0: mov %i0, %o0 0x00113db4: ld [ %g2 + 0xa0 ], %g2 0x00113db8: mov %l2, %o1 0x00113dbc: mov %l1, %o2 0x00113dc0: mov %i2, %o3 0x00113dc4: mov %i4, %o4 0x00113dc8: ld [ %g2 + 0x7c ], %l0 0x00113dcc: call %l0 0x00113dd0: mov %i5, %o5 So this makes it appear as if %o0 to %o5 are all set in preparation for the romvec call. Now minus the actual Forth string (actually a cstr), if the other values were pushed onto the stack in reverse order then it appears that this code would it is supposed to. There is one Forth call in the traces that only takes 1 parameter, but there doesn't seem to be a way of passing the number of arguments into the romvec call. However, based on looking at the traces, starting with the first non-zero value in the highest o register and then pushing all the lower o register values onto the Forth stack before execution should give the correct result. On the basis of this, I'd like to suggest the following proposal: 1) Change the signature of obp_fortheval_v2() from: static void obp_fortheval_v2(char *str) to: static void obp_fortheval_v2(char *str, int arg0, int arg1, int arg2, int arg3, int arg4) 2) Add code to obp_fortheval_v2 that starting from arg4 and working down to arg0, finds the first non-zero value and then pushes all remaining values argN down to arg0 onto the Forth stack before executing the Forth string. Does this sound reasonable? I'm surprised that one else has realised that the obp_fortheval_v2 function signature was wrong, but I guess it probably hardly gets used for anything these days. As a separate hack, the equivalent of the OpenBOOT current-device word in OpenBIOS is active-package. So we should probably create an OpenBIOS variable called current-device too, and set its value to -1 when the function is entered. Then after all Forth has been evaluated, if it's value has changed from before the Forth call was made then set active-package to the new value before exit. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

6 46

[commit] r941 - trunk/openbios-devel/arch/ppc/qemu
by repository service 01 Nov '10

01 Nov '10

Author: afaerber Date: Mon Nov 1 18:31:11 2010 New Revision: 941 URL: http://tracker.coreboot.org/trac/openbios/changeset/941 Log: ppc: Label illegal vectors Improve GDB backtrace by making the vector source less ambiguous. A 0x700 program exception was shown as originating from vector__0x400. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Modified: trunk/openbios-devel/arch/ppc/qemu/start.S Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Sun Oct 31 17:54:58 2010 (r940) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Mon Nov 1 18:31:11 2010 (r941) @@ -21,7 +21,7 @@ /* Macros */ /************************************************************************/ -#define ILLEGAL_VECTOR( v ) .org __vectors + v ; bl trap_error ; +#define ILLEGAL_VECTOR( v ) .org __vectors + v ; vector__##v: bl trap_error ; #define VECTOR( v, dummystr ) .org __vectors + v ; vector__##v /* We're trying to use the same code for the ppc32 and ppc64 handlers here.

1 0

couple of problem while compiling and running openfirmware on qemu
by Gleb Natapov 01 Nov '10

01 Nov '10

Hello, I tried to compile openfirmware for qemu like described here http://www.openfirmware.info/Building_OFW_for_QEMU. But after running make in cpu/x86/pc/emu/build on 64bit host I get linkage error: ld -T inflate.ld inflate.lo -o inflate.o ld: i386 architecture of input file `inflate.lo' is incompatible with i386:x86-64 output After applying this patch: Index: cpu/x86/Linux/Makefile =================================================================== --- cpu/x86/Linux/Makefile (revision 1996) +++ cpu/x86/Linux/Makefile (working copy) @@ -34,7 +34,7 @@ ${CC} -c -m32 -Wall -fno-stack-protector -ffreestanding -D_FORTIFY_SOURCE=0 -DNEED_BCOPY -O3 -fpic $< -o $@ inflate.o: inflate.lo - ${LD} -T inflate.ld $< -o $@ + ${LD} -melf_i386 -T inflate.ld $< -o $@ ../build/inflate.bin: inflate.o objcopy -O binary $< $@ ==== compilation goes a little bit further but now it stops with: ./build emuofw.rom --- Rebuilding ohci.fc --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../ohci.bth ${BP}/dev/usb2/hcd/ohci/ohci.fth:25: my-w@ ? don't know much forth so just commented every line that gave me an error: Index: dev/usb2/hcd/ohci/ohci.fth =================================================================== --- dev/usb2/hcd/ohci/ohci.fth (revision 1996) +++ dev/usb2/hcd/ohci/ohci.fth (working copy) @@ -22,12 +22,12 @@ 0 value ohci-reg : map-regs ( -- ) - 4 my-w@ h# 16 or 4 my-w! - 0 0 my-space h# 0200.0010 + 1000 map-in to ohci-reg +\ 4 my-w@ h# 16 or 4 my-w! +\ 0 0 my-space h# 0200.0010 + 1000 map-in to ohci-reg ; : unmap-regs ( -- ) - ohci-reg 1000 map-out 0 to ohci-reg +\ ohci-reg 1000 map-out 0 to ohci-reg ; : ohci-reg@ ( idx -- data ) ohci-reg + rl@ ; ======== After that compilation finally succeeded. Produced rom image runs fine on qemu, but fails on qemu-kvm with error: BUG: kvm_dirty_pages_log_change: invalid parameters 0000000010000000-0000000010ffffff Looking into it it seams like openfirmware configure cirrus framebuffer to be at address 0x10000000, but later it configures nic memory BAR with the same address (during device enumeration perhaps). Later it deconfigures nic again. Qemu somehow handles this fine, but qemu-kvm doesn't. This shouldn't work on real HW too FWIW. -- Gleb.

1 0