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