On 19/06/16 13:55, Cédric Le Goater wrote:
On 06/12/2016 05:29 PM, Mark Cave-Ayland wrote:
On 12/06/16 16:22, Cédric Le Goater wrote:
FYI, I had to specify the path of BootX to get running.
Really? Could you send the exact command used to boot?
Here is it :
qemu-system-ppc -M mac99 -m 1024 -drive file=./qemu/macosx.raw -prom-env 'boot-args=-v' -prom-env 'boot-device=hd:3,\System\Library\CoreServices\BootX' -bios ./work/bootloader/openbios.git/obj-ppc/openbios-qemu.elf
Curiously, openbios is not looking for this file.
hfsp_files_open_nwrom() seems to be the routine looking for such files but it is not called. May be because I compiled openbios with the qemu-ppc configuration ?
btw, mol-ppc does not compile :
forth/device/display.fs:419: undefined word.
I am discovering the code so I might be going in the wrong direction and bringing you with me :)
Well I've been working with OpenBIOS for several years now, and I think you are the only person who has tried to build mol-ppc ;) My understanding is that it was a work in progress to move the custom bios back into the OpenBIOS tree that was never completed. But to be honest there have been so many changes since then you'd be better off reforking from the QEMU part if you wanted to bring this back to life.
What is the type and creator of the Bootx file? You can use Resedit or another program to find this information out.
So, it reaches the graphical login screen but it dies repeatedly with this message on the console :
getty : /dev/console Operation not supported by device crashdump[146]: crash report written to ...
and I can not login :/
Some issue in the device models may be? I did not dig in yet.
And -prom-env 'boot-args=-v' doesn't provide any useful extra logging at all?
No not much. But the issue is not from qemu. It is a jpeg libray one. See below. May be I can find a fix for it.
C.
Host Name: maina Date/Time: 2016-06-18 19:04:24.319 +0200 OS Version: 10.4.11 (Build 8S165) Report Version: 4
Command: SecurityAgent Path: /System/Library/CoreServices/SecurityAgent.app/Contents/MacOS/SecurityAgent Parent: securityd [59]
Version: 3.8 (32241) Build Version: 20 Project Name: SecurityAgent Source Version: 322410000
PID: 187 Thread: 1
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x000000f0
Thread 0: 0 libSystem.B.dylib 0x9000af48 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000ae9c mach_msg + 60 2 com.apple.CoreFoundation 0x907de9ac __CFRunLoopRun + 832 3 com.apple.CoreFoundation 0x907de2b0 CFRunLoopRunSpecific + 268 4 com.apple.HIToolbox 0x932bcb20 RunCurrentEventLoopInMode + 264 5 com.apple.HIToolbox 0x932bc1b4 ReceiveNextEventCommon + 380 6 com.apple.HIToolbox 0x932bc020 BlockUntilNextEventMatchingListInMode + 96 7 com.apple.AppKit 0x937a1734 _DPSNextEvent + 384 8 com.apple.AppKit 0x937a13f8 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 116 9 com.apple.AppKit 0x9379d93c -[NSApplication run] + 472 10 com.apple.securityagent 0x000029e0 0x1000 + 6624 11 com.apple.securityagent 0x0000251c 0x1000 + 5404 12 com.apple.securityagent 0x00008794 0x1000 + 30612
Thread 1 Crashed: 0 libJPEG.dylib 0x91b4f930 _cg_vec_jpeg_idct_islow + 132 1 libJPEG.dylib 0x91b5e5c4 process_data_simple_main + 68 2 libJPEG.dylib 0x91b4e62c _cg_jpeg_read_scanlines + 228 3 com.apple.ImageIO.framework 0x919df84c getBandProcJPG + 224 4 com.apple.ImageIO.framework 0x919c4e88 getBytes_cb + 284 5 com.apple.CoreGraphics 0x903d5dc4 CGAccessSessionGetChunks + 508 6 com.apple.CoreGraphics 0x903d5948 img_raw_read + 240 7 com.apple.CoreGraphics 0x9042c48c img_interpolate_read + 384 8 com.apple.CoreGraphics 0x903d4568 img_data_lock + 3680 9 com.apple.CoreGraphics 0x903d2d64 CGSImageDataLockWithReference + 156 10 libRIP.A.dylib 0x947fc24c ripc_AcquireImage + 920 11 libRIP.A.dylib 0x947fa948 ripc_DrawImage + 2428 12 com.apple.CoreGraphics 0x903d2ab4 CGContextDelegateDrawImage + 76 13 com.apple.CoreGraphics 0x903d2a0c CGContextDrawImage + 340 14 com.apple.securityagent 0x0003c2dc 0x1000 + 242396 15 com.apple.securityagent 0x0003c0b8 0x1000 + 241848 16 com.apple.Foundation 0x92bf64d8 forkThreadForFunction + 108 17 libSystem.B.dylib 0x9002b908 _pthread_body + 96
Thread 1 crashed with PPC Thread State 64: srr0: 0x0000000091b4f930 srr1: 0x000000000200f030 vrsave: 0x00000000fffff41f cr: 0x24842224 xer: 0x0000000020000004 lr: 0x0000000091b4f8f4 ctr: 0x0000000091b4f8ac r0: 0x00000000fffff41f r1: 0x00000000f007edf0 r2: 0x00000000a1b48660 r3: 0x0000000000000040 r4: 0x0000000000000030 r5: 0x00000000017e2210 r6: 0x00000000017e2c10 r7: 0x0000000000000000 r8: 0x00000000017e1810 r9: 0x0000000000000080 r10: 0x00000000017e0e10 r11: 0x0000000000000070 r12: 0x0000000091b4f8ac r13: 0x00000000000000c7 r14: 0x0000000091b4f8ac r15: 0x0000000000000000 r16: 0x0000000000000000 r17: 0x000000000000013f r18: 0x0000000000000000 r19: 0x0000000001880150 r20: 0x0000000000000000 r21: 0x0000000000000001 r22: 0x00000000018c0570 r23: 0x0000000000000000 r24: 0x0000000000000000 r25: 0x00000000018c04a0 r26: 0x0000000001880000 r27: 0x0000000000000000 r28: 0x0000000000000060 r29: 0x0000000000000050 r30: 0x0000000000000001 r31: 0x0000000091b4f8f4
Hmmm I guess that could be an emulation bug. Possibly related to altivec if those instructions could be use to optimise these sorts of encode/decode routines?
ATB,
Mark.