December 2012 - OpenBIOS - mail.coreboot.org

testing Max OS X boot on latest trunk (revision 1080)
by Amadeusz Sławiński Feb. 28, 2013

Feb. 28, 2013

Here are results of my testing booting OS X on latest trunk Logs in attachment Not patched ones (fails without get-key-map): 10.0.log 10.2.log 10.4.log Patched with gsoc get-key-map patch: 10.0-gkm.log 10.2-gkm-panic.log 10.4-gkm.log Patched with gsoc divide by 0: 10.2-gkm-dvb0.log Logs from patched boot without CIF: all-without-cif.log 10.2 ones show that there is need for some solution regarding division by 0, some notes from my talks with Mark: My g5 machine returns 0 when dividing by 0, no warnings are printed: 0 > 0 0 / ok 1 > . ok 0 > 0 0 > 2 0 / ok 1 > . ok 0 > 0 Question is how to implement it, or maybe just use gsoc patch? Also it seems that Mac OS X seems to provide it's own fill-rectangle and draw-rectangle it prints: FILL-RECTANGLE isn't unique. and also similar message when I apply gsoc draw-rectangle patch so it seems that this one isn't needed Another problem is that it seems to be unable to open/load kernel. On graphic side of things it seems to draw things better than with gsoc patches, graphics are not weirdly resized, but there is not much to see except boot folder graphic (10.0)/white apple(10.2, 10.4). Amadeusz

2 1

[commit] r1078 - trunk/openbios-devel/arch/ppc/qemu
by repository service Jan. 10, 2013

Jan. 10, 2013

Author: mcayland Date: Sun Dec 9 21:37:53 2012 New Revision: 1078 URL: http://tracker.coreboot.org/trac/openbios/changeset/1078 Log: PPC: Implement filll (fill long) word for QEMU/PPC as required by BootX. Based upon an original patch by John Arbuckle <programmingkidx(a)gmail.com>. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/init.c Modified: trunk/openbios-devel/arch/ppc/qemu/init.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/init.c Fri Dec 7 15:28:07 2012 (r1077) +++ trunk/openbios-devel/arch/ppc/qemu/init.c Sun Dec 9 21:37:53 2012 (r1078) @@ -613,6 +613,21 @@ fword("finish-device"); } +/* + * filll ( addr len quad -- ) + */ + +static void ffilll(void) +{ + const u32 longval = POP(); + u32 len = POP(); + u32 *aaddr = (u32 *)cell2pointer(POP()); + + while (len--) { + *aaddr++ = longval; + } +} + void arch_of_init(void) { @@ -877,6 +892,9 @@ device_end(); + /* Implementation of filll word (required by BootX) */ + bind_func("filll", ffilll); + bind_func("platform-boot", boot); bind_func("(go)", go); }

3 2

Re: [OpenBIOS] static and global variable problem
by Programmingkid Jan. 1, 2013

Jan. 1, 2013

On Dec 21, 2012, at 8:14 AM, Mark Cave-Ayland wrote: > On 21/12/12 13:09, Programmingkid wrote: > >>> No, you've got this the wrong way around. The default CFLAGS for OpenBIOS uses -Os which causes heavy optimisation and confuses gdb causing it to give incorrect output. So if you want to use gdb to debug OpenBIOS, you need to rebuild it with -O0 and use the generated .nostrip unstripped binary. >> >> I have done that and the problem is still there. > > Okay - did you make sure you did a complete rebuild so the flags got picked up by the C compiler? > > rm -rf obj-ppc > vi Makefile.target > (change -Os to -O0) > ./config/scripts/switch-arch ppc > make > > If you're sure, post a message with detailed instructions to the list so that others can try and reproduce what you are seeing. > How to reproduce the problem: 1. Start QEMU for debugging: qemu-system-ppc -m 128 -bios openbios-qemu.elf.nostrip -cdrom darwin8.iso -s -S 2. Start up gdb to read the firmware file: powerpc-linux-gdb openbios-qemu.elf.nostrip 3. Connect to QEMU using this command inside gdb: target remote localhost:1234 4. Set a breakpoint at this place: b ofmem.c:414 5. Have OpenBIOS start the boot process by entering this in QEMU: boot cd:,\\:tbxi 6. When the breakpoint in tripped, type this in gdb: print &next_grab_slot. next_grab_slot will have an address that isn't available to QEMU. The value I see is 0xfffda060. QEMU would have to have over 4 GB of ram in order to access this address.

2 4

bootx error message
by Programmingkid Dec. 30, 2012

Dec. 30, 2012

I just wanted to share this error message I see right before booting failed for Mac OS X: setting boot-uuid to: A9E84582-CFBD-347C-B2E9-5C3F4F1138C247 non-root file owner detected: 501 non-root file owner detected: 501 Reading HFS+ file: [\mach_kernel] from 3fc5d1a4. Reading HFS+ file: [\mach_kernel] from 3fc5d1a4. Should I be concerned with the 501 issue? I guess what I'm asking is can file permissions stop bootx from loading and running the mach kernel?

1 0

testing Max OS X boot on latest trunk (revision 1080)
by Amadeusz Sławiński Dec. 25, 2012

Dec. 25, 2012

Resending because it got stuck in moderation queue due to size logs in separate mails Here are results of my testing booting OS X on latest trunk Logs in attachment Not patched ones (fails without get-key-map): 10.0.log 10.2.log 10.4.log Patched with gsoc get-key-map patch: 10.0-gkm.log 10.2-gkm-panic.log 10.4-gkm.log Patched with gsoc divide by 0: 10.2-gkm-dvb0.log Logs from patched boot without CIF: all-without-cif.log 10.2 ones show that there is need for some solution regarding division by 0, some notes from my talks with Mark: My g5 machine returns 0 when dividing by 0, no warnings are printed: 0 > 0 0 / ok 1 > . ok 0 > 0 0 > 2 0 / ok 1 > . ok 0 > 0 Question is how to implement it, or maybe just use gsoc patch? Also it seems that Mac OS X seems to provide it's own fill-rectangle and +draw-rectangle it prints: FILL-RECTANGLE isn't unique. and also similar message when I apply gsoc draw-rectangle patch so it seems that this one isn't needed Another problem is that it seems to be unable to open/load kernel. On graphic side of things it seems to draw things better than with gsoc patches, graphics are not weirdly resized, but there is not much to see except boot folder graphic (10.0)/white apple(10.2, 10.4). Amadeusz

4 12

[PATCH] get-key-map implementation
by Programmingkid Dec. 23, 2012

Dec. 23, 2012

This patch is an improvement upon the last get-key-map patch. This patch makes the code more 64bit friendly. It also fixes some whitespace damage. The get-key-map word is used by bootx to see if any keys are being held down. signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Index: drivers/adb_kbd.c =================================================================== --- drivers/adb_kbd.c (revision 1078) +++ drivers/adb_kbd.c (working copy) @@ -24,7 +24,7 @@ #include "libc/byteorder.h" #include "libc/vsprintf.h" #include "kbd.h" - +#include <math.h> #include "adb_bus.h" #include "adb_kbd.h" @@ -42,11 +42,13 @@ } static void keyboard_read(void); +static void getKeyMap(void); NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", getKeyMap }, }; /* VT100 escape sequences */ @@ -566,3 +568,65 @@ } PUSH(i); } + +// The implementation of the get-key-map word. +// Returns an array of 32 bytes. Certain bits +// are used to determine which keys are being +// held down. + +static void getKeyMap(void) +{ + #define sizeOfArray 8 // 8 bytes (32 bits) in size + uint32_t keyPushed, *keyMapArray, offset; + const uint32_t modifierKeyIndex = 7; + const uint32_t commandKeyValue = pow(2,28); + const uint32_t shiftKeyValue = pow(2,30); + const uint32_t theAKeyValue = pow(2,27); + + keyMapArray = (uint32_t *) malloc(sizeOfArray); + if(!keyMapArray) // if failed to allocate memory + { + printk("Failed to allocate memory for keyMapArray!\n"); + PUSH(0); + return; + } + + // Set all the elements to zero + int index; + for(index = 0; index < sizeOfArray; index++) + { + keyMapArray[index] = 0; + } + + feval("key?"); + if(POP() != -1) // if no key was pushed + { + PUSH((uint32_t)keyMapArray); // returns the address of keyMapArray + return; + } + + feval("key"); + keyPushed = POP(); + + if(keyPushed > 0 && keyPushed < 27) // control key combination + { + offset = 1; + keyMapArray[modifierKeyIndex] = commandKeyValue; + } + + else if(keyPushed > 64 && keyPushed < 91) // shift key combination + { + offset = 65; + keyMapArray[modifierKeyIndex] = shiftKeyValue; + } + + else // just a letter is being held down + { + offset = 97; + } + + // Determines the value and location of a bit in the array. + *keyMapArray = theAKeyValue >> (keyPushed - offset); + + PUSH((uint32_t) keyMapArray); +} This patch takes us a lot further along while booting Mac OS X. Here is the CIF. >> ============================================================= >> OpenBIOS 1.0 [Dec 12 2012 20:16] >> Configuration device id QEMU version 1 machine id 2 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,750 Welcome to OpenBIOS v1.0 built on Dec 12 2012 20:16 Trying hd:,\\:tbxi... Trying hd:,\ppc\bootinfo.txt... No valid state has been set by load or init-program 0 > boot cd:,\\:tbxi >> finddevice("/openprom") = 0xfff49f40 >> getprop(0xfff49f40, "model", 0x0565f68c, 255) = 15 >> 0x0565f68c 4f 70 65 6e 46 69 72 6d 77 61 72 65 20 33 00 __ OpenFirmware 3. >> peer(0x00000000) = 0xfff49d80 >> getprop(0xfff49d80, "#address-cells", 0x056579d0, 4) = 4 >> 0x056579d0 00 00 00 01 __ __ __ __ __ __ __ __ __ __ __ __ .... >> peer(0x00000000) = 0xfff49d80 >> getprop(0xfff49d80, "#size-cells", 0x056579d4, 4) = 4 >> 0x056579d4 00 00 00 01 __ __ __ __ __ __ __ __ __ __ __ __ .... >> of_client_interface: interpret 05616674 >> interpret hex unselect-dev " /packages" find-device new-device " sl_words" device-name : open true ; : close ; 0 value outputLevel : slw_set_output_level dup 0= if 0 stdout ! then to outputLevel ; : slw_emit 2 outputLevel <= if emit else drop then ; : slw_cr 2 outputLevel <= if cr then ; 0 value keyboardIH 20 buffer: keyMap : slw_init_keymap to keyboardIH keyMap dup 20 0 fill ; : slw_update_keymap { ; dpth } depth -> dpth keyboardIH if " get-key-map" keyboardIH $call-method depth dpth - 1 = if 20 then 4 / 0 do dup i 4 * + l@ keyMap i 4 * + tuck l@ or swap l! loop drop then ; 0 value screenIH 0 value cursorAddr 0 value cursorX 0 value cursorY 0 value cursorW 0 value cursorH 0 value cursorFrames 0 value cursorPixelSize 0 value cursorStage 0 value cursorTime 0 value cursorDelay : slw_spin screenIH 0<> cursorAddr 0<> and if get-msecs dup cursorTime - cursorDelay >= if to cursorTime slw_update_keymap cursorStage 1+ cursorFrames mod dup to cursorStage handle_calls return: 00000000 07c5b098 >> finddevice("/options") = 0xfff4a0e8 >> finddevice("/chosen") = 0xfff4a160 >> of_client_interface: interpret 056133e4 >> interpret dev /chosen new-device " memory-map" device-name active-package device-end ([1] -- [2]) >> handle_calls return: 00000000 fff57a90 >> getprop(0xfff4a160, "mmu", 0x056579ec, 4) = 4 >> 0x056579ec 07 c5 a8 2c __ __ __ __ __ __ __ __ __ __ __ __ .Ũ, >> getprop(0xfff4a160, "memory", 0x056579f0, 4) = 4 >> 0x056579f0 07 c5 ae 58 __ __ __ __ __ __ __ __ __ __ __ __ .ŮX >> peer(0x00000000) = 0xfff49d80 >> of_client_interface: interpret 05616db8 fff49d80 0000000a 056131d4 >> interpret get-package-property if 0 0 then ([4] -- [3]) >> handle_calls return: 00000000 00000019 fff56d04 >> getprop(0xfff4a160, "stdout", 0x056579f4, 4) = 4 >> 0x056579f4 07 c5 af 5c __ __ __ __ __ __ __ __ __ __ __ __ .ů\ >> instance-to-package(0x07c5af5c) = 0xfff567a4 >> getprop(0xfff4a160, "stdin", 0x056579f8, 4) = 4 >> 0x056579f8 07 c5 b0 64 __ __ __ __ __ __ __ __ __ __ __ __ .Űd >> instance-to-package(0x07c5b064) = 0xfff567a4 >> getprop(0xfff567a4, "name", 0x0565f81c, 31) = 5 >> 0x0565f81c 63 68 2d 62 00 __ __ __ __ __ __ __ __ __ __ __ ch-b. >> open("keyboard") = 0x07c5b49c >> of_client_interface: call-method 05616d78 07c5b098 07c5b49c >> call-method slw_init_keymap ([3] -- [2]) >> handle_calls return: 00000000 fff57558 >> of_client_interface: call-method 05616d88 07c5b098 >> call-method slw_update_keymap ([2] -- [1]) >> handle_calls return: 00000000 >> getprop(0xfff4a0e8, "security-mode", 0x0565f83c, 32) = -1 >> of_client_interface: call-method 05616d60 07c5b098 00000000 >> call-method slw_set_output_level ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c70 07c5b098 >> call-method slw_cr ([2] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c70 07c5b098 >> call-method slw_cr ([2] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 0000004d >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000061 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000063 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000020 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 0000004f >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000053 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000020 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000058 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000020 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 0000004c >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 0000006f >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000061 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000064 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000065 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c78 07c5b098 00000072 >> call-method slw_emit ([3] -- [1]) >> handle_calls return: 00000000 >> of_client_interface: call-method 05613c70 07c5b098 >> call-method slw_cr ([2] -- [1]) >> handle_calls return: 00000000 >> claim(0x05000000, 4194304, 0) = 0x05000000 >> claim(0x05400000, 2097152, 0) = 0x05400000 >> claim(0x04000000, 16777216, 0) = 0x04000000 >> claim(0x00004000, 67092480, 0) = 0x00004000

3 4

Update
by Programmingkid Dec. 23, 2012

Dec. 23, 2012

The Darwin PPC cd is definitely something you should download. I tried it today and was blown away by the results. I was actually able to see the Apple logo displayed in QEMU! This cd image is free and would allow you to actually test some of the patches yourself. Here's the link: http://www.opensource.apple.com/darwinsource/images/darwinppc-801.cdr.gz This patch is what allowed me to go so far in booting: Index: forth/admin/iocontrol.fs =================================================================== --- forth/admin/iocontrol.fs (revision 1041) +++ forth/admin/iocontrol.fs (working copy) @@ -80,6 +80,7 @@ ; : io-emit ( char -- ) + stdout @ 0= if drop exit then \ make sure stdout pointer is not null io-out-char c! io-out-char 1 " write" stdout @ $call-method drop ; I could post the CIF, but it is huge. The above patch is definitely needed.

3 5

static and global variable problem
by Programmingkid Dec. 21, 2012

Dec. 21, 2012

I was doing some debugging of an issue with the hash_page_32() function in the file ofmem.c, when I noticed a very odd problem. The static variable next_grab_slot never changes value. I tried declaring it as a global variable and its value still never changes. I used gdb to monitor its value. Local variables work just fine. Any body know a way to fix this problem? My guess is this is a gcc problem. What is your theory?

3 4

Fwd: static and global variable problem
by Programmingkid Dec. 21, 2012

Dec. 21, 2012

On Dec 21, 2012, at 8:14 AM, Mark Cave-Ayland wrote: > On 21/12/12 13:09, Programmingkid wrote: > >>> No, you've got this the wrong way around. The default CFLAGS for OpenBIOS uses -Os which causes heavy optimisation and confuses gdb causing it to give incorrect output. So if you want to use gdb to debug OpenBIOS, you need to rebuild it with -O0 and use the generated .nostrip unstripped binary. >> >> I have done that and the problem is still there. > > Okay - did you make sure you did a complete rebuild so the flags got picked up by the C compiler? > > rm -rf obj-ppc > vi Makefile.target > (change -Os to -O0) > ./config/scripts/switch-arch ppc > make > > If you're sure, post a message with detailed instructions to the list so that others can try and reproduce what you are seeing. I found out that the address of the variable next_grab_slot was way out of range. Qemu was given only 128MB of ram, and this variable was located at an address around the 4095 MB area.

1 0

Re: [OpenBIOS] Mac OS X support
by Programmingkid Dec. 21, 2012

Dec. 21, 2012

On Nov 16, 2012, at 1:54 PM, Amadeusz Sławiński wrote: > On Fri, Nov 16, 2012 at 11:29:04AM -0500, Programmingkid wrote: >> >> On Nov 16, 2012, at 7:08 AM, Amadeusz Sławiński wrote: >> >>> On Thu, Nov 15, 2012 at 05:44:54PM -0500, Programmingkid wrote: >>>> Could you send me your OpenBIOS-qemu.elf file? I tried the link that was on that page you sent me, but I only see an error message that says "Wrong IP" when I try to download it. >>>> >>>> Here is the problem link: http://free-uploading.com/t0uwrodvvxkz/ ... u.elf.html >>>> >>>> May I suggest using mediafire.com instead. >>> >>> Sorry, this file seems to be lost and I also get "Wrong IP" message, >>> however when applying patches from GSOC onto current trunk I was able to >>> get it into similar state (it even stopped in same places). >>> I will redo this later (I deleted my working dir) and send you newer one. >> >> Thank you. > > And here it is, both stripped and not stripped > I tested it with Mac OS X 10.0 and 10.2 install cd, boots similarly to > what was on screenshots > > I run it as follows: > qemu-system-ppc -bios openbios-qemu.elf -cdrom Mac\ OS\ 10.0.img -g 800x600x32 -m 1024 > > Please tell me if you got them as gmail can do weird things whan it > comes to mailing attachments. > <openbios-qemu.elf><openbios-qemu.elf.nostrip> I recently decided to try your openbios files you sent me a while back. This time I tried them in QEMU 1.2.2 and 0.12.5. Both times, the boot process stops at the same place. It is where this is displayed in the log: >> claim(0x05000000, 4194304, 0) = 0x05000000 >> claim(0x05400000, 2097152, 0) = 0x05400000 >> claim(0x04000000, 16777216, 0) = 0x04000000 >> claim(0x00004000, 67092480, 0) = 0x00004000 The only way I can go further is the alter a few lines in ofmem.c. Did you make any changes to QEMU?

3 3