Hello,
This thread was started on qemu-devel@ but openbios@ seems more appropriate place now.
On 06/07/2016 10:24 AM, Mark Cave-Ayland wrote:
On 07/06/16 08:04, Cédric Le Goater wrote:
- I have an old ibook G4 from which I dd'ed the disk. openbios complains for some invalid state. is that supported ?
Yes, OpenBIOS should boot most things these days (MorphOS is the only execption I know of where the bootloader won't execute correctly as it assumes real mode). The above message means that OpenBIOS couldn't find a bootloader, or it could but was unable to execute it, e.g. due to incompatible architecture - which OS is your image running?
I am pretty sure it is a Mac OS X v10.5. I still have the hardware but it is running Linux now :
# cat /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 1333.333000MHz revision : 1.5 (pvr 8003 0105) bogomips : 36.86
total bogomips : 36.86 timebase : 18432000 platform : PowerMac model : PowerBook6,7 machine : PowerBook6,7 motherboard : PowerBook6,7 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 0000001a L2 cache : 512K unified pmac-generation : NewWorld Memory : 1024 MB
# lsprop /proc/device-tree/rom@ff800000/boot-rom@fff00000/ reg fff00000 00100000 info fff00000 00003f00 000493f0 20050705 815fda85 fff08000 00078001 000493f0 20050705 23765c6c fff80000 00080002 000493f0 20050705 b3364dca fff03f00 00000083 000493f0 20050705 c2b72d61 fff03f80 00000084 e24a68ca 15a82001 ffffffff fff04000 00004005 6e767261 6d000000 00000000 00000000 00000000 [140 bytes total] name "boot-rom" security-modes 6e6f6e65 2c206675 6c6c2c20 636f6d6d 616e642c 206e6f2d 70617373 776f7264 image 00080000 (524288) model "Apple PowerBook6,7 4.9.3f0 BootROM built on 07/05/05 at 11:14:11" write-characteristic "flash" hwi-flags 402a1220 (1076498976) BootROM-version "$0004.93f0" BootROM-build-date "07/05/05 at 11:14:11" linux,phandle ff89cb08 has-config-block
Have you tried both mac99 and g3beige machines?
yes.
(I'm wondering if we should start a new thread here either just on qemu-ppc or over on the OpenBIOS list)
doing so on openbios@
OpenBIOS will read hfs/hfsplus filesystems fine - I wonder if maybe it can't locate a suitable partition in the Apple Partition Map?
If you boot to the Forth prompt with -prom-env 'auto-boot?=false' can you try the following to see if you can list the disk contents:
dir hd:,\
If that doesn't work it means that the partition auto-detection is failing, so try manually forcing the partition number until you find one that works e.g.
dir hd:0,\ dir hd:1,\ etc.
up until around partition 10? Once you find one that works it should be possible to boot that partition directly e.g.
boot hd:1
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0;
while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...
How do I add more logging with openbios ?
Thanks,
C.
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0; while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...
Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
You should find that in -nographic mode Forth errors are logged to the console - does anything obvious stand out? If not, you'd probably have to look at modifying OpenBIOS to dump out the 10.5 bootloader to see what it's trying to do.
ATB,
Mark.
On Wed, Jun 08, 2016 at 03:48:17PM +0200, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
A DSI. How can BL cause a DSI? Shouldn't it be an ISI, if fff279e8 isn't mapped? What else can be going on, is the logging complete, or did e.g. one of the first insns of fff279e8 cause the DSI?
DSISR, DAR, SRR0/1 here will tell you more.
IN: 0x00000700: .long 0x0
That's because the code at 300 is 0, which is an invalid opcode.
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0; while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...
The failing call is to seek_io.
Segher
Hello Mark,
On 06/08/2016 08:52 PM, Mark Cave-Ayland wrote:
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0; while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
0 > dir hd:3,\ 7065 2006-11-05 15:39:15 .\debugdata\debug.txt 0 2006-01-10 13:37:45 .com_symantec_symfs_private\ 12292 2002-05-16 10:37:41 .DS_Store 458752 2005-10-20 18:00:21 .hotfiles.btree 8388608 2005-07-12 03:37:09 .journal 4096 2005-07-12 03:37:09 .journal_info_block 0 2005-07-12 04:48:20 .Spotlight-V100\ 0 2006-01-09 10:49:19 .symSchedScanLockxz 0 2005-07-12 04:53:28 .Trashes\ 0 2005-03-22 00:01:29 .vol\ 0 2005-07-11 09:36:46 Applications\ 0 2005-07-11 17:21:58 Applications (Mac OS 9)\ 512 2005-12-28 17:51:55 Auth-DigitalPerformer 4.0 0 2005-12-02 17:25:12 automount\ 0 2005-07-11 10:28:40 bin\ 0 2005-05-28 17:05:33 cores\ 133120 2005-07-12 04:48:01 Desktop DB 715698 2005-07-12 04:48:01 Desktop DF 0 2003-10-32 14:57:45 Desktop Folder\ 0 2005-05-28 17:05:33 dev\ 0 2008-09-07 00:40:24 Developer\ 0 2005-11-15 13:13:52 Dossier Systeme\ 11 2005-07-12 03:37:16 etc 21579557 2006-09-19 08:26:22 gmon.out 60 2005-12-02 11:59:32 Guides de lutilisateur et informations 297 2005-01-09 16:29:43 Installer Log File 0 2005-07-11 10:22:09 Library\ 9 2015-05-28 12:06:55 mach 604360 2015-05-28 12:06:55 mach.sym 4352200 2007-10-12 01:26:11 mach_kernel 0 2005-11-17 19:04:29 Macintosh HD 13027540 2006-01-09 10:48:44 NAVMac800QSFile 0 2005-05-28 17:05:33 Network\ 29150 2005-01-18 09:35:39 Office 2004 11.1.0 Update Log 0 2005-07-11 10:19:09 private\ 0 2005-07-11 10:28:00 sbin\ 0 2006-11-02 08:15:23 sblibng.log 0 2005-07-11 09:36:30 System\ 0 2004-10-02 10:23:16 TheVolumeSettingsFolder\ 11 2005-07-12 03:37:52 tmp 0 2005-03-21 23:57:33 Users\ 0 2005-07-11 09:39:44 usr\ 11 2005-07-12 03:37:59 var 0 2005-03-22 00:01:29 Volumes\ 0 2005-07-12 03:30:28 HFS+ Private Data\ ok 0 >
That system was updated from Mac OS 9. That might be the issue.
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
You should find that in -nographic mode Forth errors are logged to the console - does anything obvious stand out? If not, you'd probably have to look at modifying OpenBIOS to dump out the 10.5 bootloader to see what it's trying to do.
yes. I will look into that next.
Using -nographic, I get more info : "Not a bootable ELF image". That's something to look for !
Thanks,
C.
Hello Segher,
On 06/08/2016 08:58 PM, Segher Boessenkool wrote:
On Wed, Jun 08, 2016 at 03:48:17PM +0200, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
A DSI. How can BL cause a DSI? Shouldn't it be an ISI, if fff279e8 isn't mapped? What else can be going on, is the logging complete, or did e.g. one of the first insns of fff279e8 cause the DSI?
DSISR, DAR, SRR0/1 here will tell you more.
IN: 0x00000700: .long 0x0
That's because the code at 300 is 0, which is an invalid opcode.
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0; while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...The failing call is to seek_io.
I have some clues now. I will dig in.
Thanks,
C.
On 08/06/16 20:38, Cédric Le Goater wrote:
Hello Mark,
On 06/08/2016 08:52 PM, Mark Cave-Ayland wrote:
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0; while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
0 > dir hd:3,\ 7065 2006-11-05 15:39:15 .\debugdata\debug.txt 0 2006-01-10 13:37:45 .com_symantec_symfs_private\ 12292 2002-05-16 10:37:41 .DS_Store 458752 2005-10-20 18:00:21 .hotfiles.btree 8388608 2005-07-12 03:37:09 .journal 4096 2005-07-12 03:37:09 .journal_info_block 0 2005-07-12 04:48:20 .Spotlight-V100\ 0 2006-01-09 10:49:19 .symSchedScanLockxz 0 2005-07-12 04:53:28 .Trashes\ 0 2005-03-22 00:01:29 .vol\ 0 2005-07-11 09:36:46 Applications\ 0 2005-07-11 17:21:58 Applications (Mac OS 9)\ 512 2005-12-28 17:51:55 Auth-DigitalPerformer 4.0 0 2005-12-02 17:25:12 automount\ 0 2005-07-11 10:28:40 bin\ 0 2005-05-28 17:05:33 cores\ 133120 2005-07-12 04:48:01 Desktop DB 715698 2005-07-12 04:48:01 Desktop DF 0 2003-10-32 14:57:45 Desktop Folder\ 0 2005-05-28 17:05:33 dev\ 0 2008-09-07 00:40:24 Developer\ 0 2005-11-15 13:13:52 Dossier Systeme\ 11 2005-07-12 03:37:16 etc 21579557 2006-09-19 08:26:22 gmon.out 60 2005-12-02 11:59:32 Guides de lutilisateur et informations 297 2005-01-09 16:29:43 Installer Log File 0 2005-07-11 10:22:09 Library\ 9 2015-05-28 12:06:55 mach 604360 2015-05-28 12:06:55 mach.sym 4352200 2007-10-12 01:26:11 mach_kernel 0 2005-11-17 19:04:29 Macintosh HD 13027540 2006-01-09 10:48:44 NAVMac800QSFile 0 2005-05-28 17:05:33 Network\ 29150 2005-01-18 09:35:39 Office 2004 11.1.0 Update Log 0 2005-07-11 10:19:09 private\ 0 2005-07-11 10:28:00 sbin\ 0 2006-11-02 08:15:23 sblibng.log 0 2005-07-11 09:36:30 System\ 0 2004-10-02 10:23:16 TheVolumeSettingsFolder\ 11 2005-07-12 03:37:52 tmp 0 2005-03-21 23:57:33 Users\ 0 2005-07-11 09:39:44 usr\ 11 2005-07-12 03:37:59 var 0 2005-03-22 00:01:29 Volumes\ 0 2005-07-12 03:30:28 HFS+ Private Data\ ok 0 >
That system was updated from Mac OS 9. That might be the issue.
Ah that could be it indeed. I've heard reports from people that installing Classic mode into a QEMU OS X causes it to fail to boot, but no-one has been able to provide an image to date. But it definitely looks like the right partition.
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
You should find that in -nographic mode Forth errors are logged to the console - does anything obvious stand out? If not, you'd probably have to look at modifying OpenBIOS to dump out the 10.5 bootloader to see what it's trying to do.
yes. I will look into that next.
Using -nographic, I get more info : "Not a bootable ELF image". That's something to look for !
That just means that OpenBIOS scanned through its list of recognised binaries and didn't match on ELF - presumably from your previous email it is a bootcode image, i.e. XML, possibly with a payload, so it would have subsequently recognised and matched on that.
You could try seeing if just loading the binary succeeds without invoking the failure on seek, and then follow this up with a go to execute the image directly:
load hd:3,\:tbxi go
If it freezes on go then that means its something in the bootloader failing in which case you may get further information by either enabling debug in the device tree:
cd / ffffffff encode-int " AAPL,debug" property boot
or perhaps passing the verbose parameter via the QEMU command line, e.g.
-prom-env 'boot-args=-v'
ATB,
Mark.
On 06/08/2016 11:55 PM, Mark Cave-Ayland wrote:
On 08/06/16 20:38, Cédric Le Goater wrote:
Hello Mark,
On 06/08/2016 08:52 PM, Mark Cave-Ayland wrote:
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0; while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
0 > dir hd:3,\ 7065 2006-11-05 15:39:15 .\debugdata\debug.txt 0 2006-01-10 13:37:45 .com_symantec_symfs_private\ 12292 2002-05-16 10:37:41 .DS_Store 458752 2005-10-20 18:00:21 .hotfiles.btree 8388608 2005-07-12 03:37:09 .journal 4096 2005-07-12 03:37:09 .journal_info_block 0 2005-07-12 04:48:20 .Spotlight-V100\ 0 2006-01-09 10:49:19 .symSchedScanLockxz 0 2005-07-12 04:53:28 .Trashes\ 0 2005-03-22 00:01:29 .vol\ 0 2005-07-11 09:36:46 Applications\ 0 2005-07-11 17:21:58 Applications (Mac OS 9)\ 512 2005-12-28 17:51:55 Auth-DigitalPerformer 4.0 0 2005-12-02 17:25:12 automount\ 0 2005-07-11 10:28:40 bin\ 0 2005-05-28 17:05:33 cores\ 133120 2005-07-12 04:48:01 Desktop DB 715698 2005-07-12 04:48:01 Desktop DF 0 2003-10-32 14:57:45 Desktop Folder\ 0 2005-05-28 17:05:33 dev\ 0 2008-09-07 00:40:24 Developer\ 0 2005-11-15 13:13:52 Dossier Systeme\ 11 2005-07-12 03:37:16 etc 21579557 2006-09-19 08:26:22 gmon.out 60 2005-12-02 11:59:32 Guides de lutilisateur et informations 297 2005-01-09 16:29:43 Installer Log File 0 2005-07-11 10:22:09 Library\ 9 2015-05-28 12:06:55 mach 604360 2015-05-28 12:06:55 mach.sym 4352200 2007-10-12 01:26:11 mach_kernel 0 2005-11-17 19:04:29 Macintosh HD 13027540 2006-01-09 10:48:44 NAVMac800QSFile 0 2005-05-28 17:05:33 Network\ 29150 2005-01-18 09:35:39 Office 2004 11.1.0 Update Log 0 2005-07-11 10:19:09 private\ 0 2005-07-11 10:28:00 sbin\ 0 2006-11-02 08:15:23 sblibng.log 0 2005-07-11 09:36:30 System\ 0 2004-10-02 10:23:16 TheVolumeSettingsFolder\ 11 2005-07-12 03:37:52 tmp 0 2005-03-21 23:57:33 Users\ 0 2005-07-11 09:39:44 usr\ 11 2005-07-12 03:37:59 var 0 2005-03-22 00:01:29 Volumes\ 0 2005-07-12 03:30:28 HFS+ Private Data\ ok 0 >
That system was updated from Mac OS 9. That might be the issue.
Ah that could be it indeed. I've heard reports from people that installing Classic mode into a QEMU OS X causes it to fail to boot, but no-one has been able to provide an image to date. But it definitely looks like the right partition.
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
You should find that in -nographic mode Forth errors are logged to the console - does anything obvious stand out? If not, you'd probably have to look at modifying OpenBIOS to dump out the 10.5 bootloader to see what it's trying to do.
yes. I will look into that next.
Using -nographic, I get more info : "Not a bootable ELF image". That's something to look for !
That just means that OpenBIOS scanned through its list of recognised binaries and didn't match on ELF - presumably from your previous email it is a bootcode image, i.e. XML, possibly with a payload, so it would have subsequently recognised and matched on that.
You could try seeing if just loading the binary succeeds without invoking the failure on seek, and then follow this up with a go to execute the image directly:
load hd:3,\:tbxi go
If it freezes on go then that means its something in the bootloader failing in which case you may get further information by either enabling debug in the device tree:
cd / ffffffff encode-int " AAPL,debug" property boot
or perhaps passing the verbose parameter via the QEMU command line, e.g.
-prom-env 'boot-args=-v'
FYI, I had to specify the path of BootX to get running.
Thanks,
C.
On Jun 11, 2016, at 1:32 PM, Cédric Le Goater wrote:
On 06/08/2016 11:55 PM, Mark Cave-Ayland wrote:
On 08/06/16 20:38, Cédric Le Goater wrote:
Hello Mark,
On 06/08/2016 08:52 PM, Mark Cave-Ayland wrote:
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0;
while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...
Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
0 > dir hd:3,\ 7065 2006-11-05 15:39:15 .\debugdata\debug.txt 0 2006-01-10 13:37:45 .com_symantec_symfs_private\ 12292 2002-05-16 10:37:41 .DS_Store 458752 2005-10-20 18:00:21 .hotfiles.btree 8388608 2005-07-12 03:37:09 .journal 4096 2005-07-12 03:37:09 .journal_info_block 0 2005-07-12 04:48:20 .Spotlight-V100\ 0 2006-01-09 10:49:19 .symSchedScanLockxz 0 2005-07-12 04:53:28 .Trashes\ 0 2005-03-22 00:01:29 .vol\ 0 2005-07-11 09:36:46 Applications\ 0 2005-07-11 17:21:58 Applications (Mac OS 9)\ 512 2005-12-28 17:51:55 Auth-DigitalPerformer 4.0 0 2005-12-02 17:25:12 automount\ 0 2005-07-11 10:28:40 bin\ 0 2005-05-28 17:05:33 cores\ 133120 2005-07-12 04:48:01 Desktop DB 715698 2005-07-12 04:48:01 Desktop DF 0 2003-10-32 14:57:45 Desktop Folder\ 0 2005-05-28 17:05:33 dev\ 0 2008-09-07 00:40:24 Developer\ 0 2005-11-15 13:13:52 Dossier Systeme\ 11 2005-07-12 03:37:16 etc 21579557 2006-09-19 08:26:22 gmon.out 60 2005-12-02 11:59:32 Guides de lutilisateur et informations 297 2005-01-09 16:29:43 Installer Log File 0 2005-07-11 10:22:09 Library\ 9 2015-05-28 12:06:55 mach 604360 2015-05-28 12:06:55 mach.sym 4352200 2007-10-12 01:26:11 mach_kernel 0 2005-11-17 19:04:29 Macintosh HD 13027540 2006-01-09 10:48:44 NAVMac800QSFile 0 2005-05-28 17:05:33 Network\ 29150 2005-01-18 09:35:39 Office 2004 11.1.0 Update Log 0 2005-07-11 10:19:09 private\ 0 2005-07-11 10:28:00 sbin\ 0 2006-11-02 08:15:23 sblibng.log 0 2005-07-11 09:36:30 System\ 0 2004-10-02 10:23:16 TheVolumeSettingsFolder\ 11 2005-07-12 03:37:52 tmp 0 2005-03-21 23:57:33 Users\ 0 2005-07-11 09:39:44 usr\ 11 2005-07-12 03:37:59 var 0 2005-03-22 00:01:29 Volumes\ 0 2005-07-12 03:30:28 HFS+ Private Data\ ok 0 >
That system was updated from Mac OS 9. That might be the issue.
Ah that could be it indeed. I've heard reports from people that installing Classic mode into a QEMU OS X causes it to fail to boot, but no-one has been able to provide an image to date. But it definitely looks like the right partition.
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
You should find that in -nographic mode Forth errors are logged to the console - does anything obvious stand out? If not, you'd probably have to look at modifying OpenBIOS to dump out the 10.5 bootloader to see what it's trying to do.
yes. I will look into that next.
Using -nographic, I get more info : "Not a bootable ELF image". That's something to look for !
That just means that OpenBIOS scanned through its list of recognised binaries and didn't match on ELF - presumably from your previous email it is a bootcode image, i.e. XML, possibly with a payload, so it would have subsequently recognised and matched on that.
You could try seeing if just loading the binary succeeds without invoking the failure on seek, and then follow this up with a go to execute the image directly:
load hd:3,\:tbxi go
If it freezes on go then that means its something in the bootloader failing in which case you may get further information by either enabling debug in the device tree:
cd / ffffffff encode-int " AAPL,debug" property boot
or perhaps passing the verbose parameter via the QEMU command line, e.g.
-prom-env 'boot-args=-v'
FYI, I had to specify the path of BootX to get running.
Really? Could you send the exact command used to boot?
What is the type and creator of the Bootx file? You can use Resedit or another program to find this information out.
On 11/06/16 18:32, Cédric Le Goater wrote:
On 06/08/2016 11:55 PM, Mark Cave-Ayland wrote:
On 08/06/16 20:38, Cédric Le Goater wrote:
Hello Mark,
On 06/08/2016 08:52 PM, Mark Cave-Ayland wrote:
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0; while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
0 > dir hd:3,\ 7065 2006-11-05 15:39:15 .\debugdata\debug.txt 0 2006-01-10 13:37:45 .com_symantec_symfs_private\ 12292 2002-05-16 10:37:41 .DS_Store 458752 2005-10-20 18:00:21 .hotfiles.btree 8388608 2005-07-12 03:37:09 .journal 4096 2005-07-12 03:37:09 .journal_info_block 0 2005-07-12 04:48:20 .Spotlight-V100\ 0 2006-01-09 10:49:19 .symSchedScanLockxz 0 2005-07-12 04:53:28 .Trashes\ 0 2005-03-22 00:01:29 .vol\ 0 2005-07-11 09:36:46 Applications\ 0 2005-07-11 17:21:58 Applications (Mac OS 9)\ 512 2005-12-28 17:51:55 Auth-DigitalPerformer 4.0 0 2005-12-02 17:25:12 automount\ 0 2005-07-11 10:28:40 bin\ 0 2005-05-28 17:05:33 cores\ 133120 2005-07-12 04:48:01 Desktop DB 715698 2005-07-12 04:48:01 Desktop DF 0 2003-10-32 14:57:45 Desktop Folder\ 0 2005-05-28 17:05:33 dev\ 0 2008-09-07 00:40:24 Developer\ 0 2005-11-15 13:13:52 Dossier Systeme\ 11 2005-07-12 03:37:16 etc 21579557 2006-09-19 08:26:22 gmon.out 60 2005-12-02 11:59:32 Guides de lutilisateur et informations 297 2005-01-09 16:29:43 Installer Log File 0 2005-07-11 10:22:09 Library\ 9 2015-05-28 12:06:55 mach 604360 2015-05-28 12:06:55 mach.sym 4352200 2007-10-12 01:26:11 mach_kernel 0 2005-11-17 19:04:29 Macintosh HD 13027540 2006-01-09 10:48:44 NAVMac800QSFile 0 2005-05-28 17:05:33 Network\ 29150 2005-01-18 09:35:39 Office 2004 11.1.0 Update Log 0 2005-07-11 10:19:09 private\ 0 2005-07-11 10:28:00 sbin\ 0 2006-11-02 08:15:23 sblibng.log 0 2005-07-11 09:36:30 System\ 0 2004-10-02 10:23:16 TheVolumeSettingsFolder\ 11 2005-07-12 03:37:52 tmp 0 2005-03-21 23:57:33 Users\ 0 2005-07-11 09:39:44 usr\ 11 2005-07-12 03:37:59 var 0 2005-03-22 00:01:29 Volumes\ 0 2005-07-12 03:30:28 HFS+ Private Data\ ok 0 >
That system was updated from Mac OS 9. That might be the issue.
Ah that could be it indeed. I've heard reports from people that installing Classic mode into a QEMU OS X causes it to fail to boot, but no-one has been able to provide an image to date. But it definitely looks like the right partition.
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
You should find that in -nographic mode Forth errors are logged to the console - does anything obvious stand out? If not, you'd probably have to look at modifying OpenBIOS to dump out the 10.5 bootloader to see what it's trying to do.
yes. I will look into that next.
Using -nographic, I get more info : "Not a bootable ELF image". That's something to look for !
That just means that OpenBIOS scanned through its list of recognised binaries and didn't match on ELF - presumably from your previous email it is a bootcode image, i.e. XML, possibly with a payload, so it would have subsequently recognised and matched on that.
You could try seeing if just loading the binary succeeds without invoking the failure on seek, and then follow this up with a go to execute the image directly:
load hd:3,\:tbxi go
If it freezes on go then that means its something in the bootloader failing in which case you may get further information by either enabling debug in the device tree:
cd / ffffffff encode-int " AAPL,debug" property boot
or perhaps passing the verbose parameter via the QEMU command line, e.g.
-prom-env 'boot-args=-v'
FYI, I had to specify the path of BootX to get running.
Oh great! Is this something that could be added to the list of paths OpenBIOS searches for an executable on boot? If you can suggest a suitable place in the ordering, the patch to add it is fairly trivial.
ATB,
Mark.
On Jun 11, 2016, at 1:32 PM, Cédric Le Goater wrote:
On 06/08/2016 11:55 PM, Mark Cave-Ayland wrote:
On 08/06/16 20:38, Cédric Le Goater wrote:
Hello Mark,
On 06/08/2016 08:52 PM, Mark Cave-Ayland wrote:
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0;
while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...
Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
0 > dir hd:3,\ 7065 2006-11-05 15:39:15 .\debugdata\debug.txt 0 2006-01-10 13:37:45 .com_symantec_symfs_private\ 12292 2002-05-16 10:37:41 .DS_Store 458752 2005-10-20 18:00:21 .hotfiles.btree 8388608 2005-07-12 03:37:09 .journal 4096 2005-07-12 03:37:09 .journal_info_block 0 2005-07-12 04:48:20 .Spotlight-V100\ 0 2006-01-09 10:49:19 .symSchedScanLockxz 0 2005-07-12 04:53:28 .Trashes\ 0 2005-03-22 00:01:29 .vol\ 0 2005-07-11 09:36:46 Applications\ 0 2005-07-11 17:21:58 Applications (Mac OS 9)\ 512 2005-12-28 17:51:55 Auth-DigitalPerformer 4.0 0 2005-12-02 17:25:12 automount\ 0 2005-07-11 10:28:40 bin\ 0 2005-05-28 17:05:33 cores\ 133120 2005-07-12 04:48:01 Desktop DB 715698 2005-07-12 04:48:01 Desktop DF 0 2003-10-32 14:57:45 Desktop Folder\ 0 2005-05-28 17:05:33 dev\ 0 2008-09-07 00:40:24 Developer\ 0 2005-11-15 13:13:52 Dossier Systeme\ 11 2005-07-12 03:37:16 etc 21579557 2006-09-19 08:26:22 gmon.out 60 2005-12-02 11:59:32 Guides de lutilisateur et informations 297 2005-01-09 16:29:43 Installer Log File 0 2005-07-11 10:22:09 Library\ 9 2015-05-28 12:06:55 mach 604360 2015-05-28 12:06:55 mach.sym 4352200 2007-10-12 01:26:11 mach_kernel 0 2005-11-17 19:04:29 Macintosh HD 13027540 2006-01-09 10:48:44 NAVMac800QSFile 0 2005-05-28 17:05:33 Network\ 29150 2005-01-18 09:35:39 Office 2004 11.1.0 Update Log 0 2005-07-11 10:19:09 private\ 0 2005-07-11 10:28:00 sbin\ 0 2006-11-02 08:15:23 sblibng.log 0 2005-07-11 09:36:30 System\ 0 2004-10-02 10:23:16 TheVolumeSettingsFolder\ 11 2005-07-12 03:37:52 tmp 0 2005-03-21 23:57:33 Users\ 0 2005-07-11 09:39:44 usr\ 11 2005-07-12 03:37:59 var 0 2005-03-22 00:01:29 Volumes\ 0 2005-07-12 03:30:28 HFS+ Private Data\ ok 0 >
That system was updated from Mac OS 9. That might be the issue.
Ah that could be it indeed. I've heard reports from people that installing Classic mode into a QEMU OS X causes it to fail to boot, but no-one has been able to provide an image to date. But it definitely looks like the right partition.
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
I'm not sure if your question was answered already, but you would use printk("Your text here").
On 06/11/2016 07:43 PM, Programmingkid wrote:
On Jun 11, 2016, at 1:32 PM, Cédric Le Goater wrote:
On 06/08/2016 11:55 PM, Mark Cave-Ayland wrote:
On 08/06/16 20:38, Cédric Le Goater wrote:
Hello Mark,
On 06/08/2016 08:52 PM, Mark Cave-Ayland wrote:
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0;
while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...
Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
0 > dir hd:3,\ 7065 2006-11-05 15:39:15 .\debugdata\debug.txt 0 2006-01-10 13:37:45 .com_symantec_symfs_private\ 12292 2002-05-16 10:37:41 .DS_Store 458752 2005-10-20 18:00:21 .hotfiles.btree 8388608 2005-07-12 03:37:09 .journal 4096 2005-07-12 03:37:09 .journal_info_block 0 2005-07-12 04:48:20 .Spotlight-V100\ 0 2006-01-09 10:49:19 .symSchedScanLockxz 0 2005-07-12 04:53:28 .Trashes\ 0 2005-03-22 00:01:29 .vol\ 0 2005-07-11 09:36:46 Applications\ 0 2005-07-11 17:21:58 Applications (Mac OS 9)\ 512 2005-12-28 17:51:55 Auth-DigitalPerformer 4.0 0 2005-12-02 17:25:12 automount\ 0 2005-07-11 10:28:40 bin\ 0 2005-05-28 17:05:33 cores\ 133120 2005-07-12 04:48:01 Desktop DB 715698 2005-07-12 04:48:01 Desktop DF 0 2003-10-32 14:57:45 Desktop Folder\ 0 2005-05-28 17:05:33 dev\ 0 2008-09-07 00:40:24 Developer\ 0 2005-11-15 13:13:52 Dossier Systeme\ 11 2005-07-12 03:37:16 etc 21579557 2006-09-19 08:26:22 gmon.out 60 2005-12-02 11:59:32 Guides de lutilisateur et informations 297 2005-01-09 16:29:43 Installer Log File 0 2005-07-11 10:22:09 Library\ 9 2015-05-28 12:06:55 mach 604360 2015-05-28 12:06:55 mach.sym 4352200 2007-10-12 01:26:11 mach_kernel 0 2005-11-17 19:04:29 Macintosh HD 13027540 2006-01-09 10:48:44 NAVMac800QSFile 0 2005-05-28 17:05:33 Network\ 29150 2005-01-18 09:35:39 Office 2004 11.1.0 Update Log 0 2005-07-11 10:19:09 private\ 0 2005-07-11 10:28:00 sbin\ 0 2006-11-02 08:15:23 sblibng.log 0 2005-07-11 09:36:30 System\ 0 2004-10-02 10:23:16 TheVolumeSettingsFolder\ 11 2005-07-12 03:37:52 tmp 0 2005-03-21 23:57:33 Users\ 0 2005-07-11 09:39:44 usr\ 11 2005-07-12 03:37:59 var 0 2005-03-22 00:01:29 Volumes\ 0 2005-07-12 03:30:28 HFS+ Private Data\ ok 0 >
That system was updated from Mac OS 9. That might be the issue.
Ah that could be it indeed. I've heard reports from people that installing Classic mode into a QEMU OS X causes it to fail to boot, but no-one has been able to provide an image to date. But it definitely looks like the right partition.
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
You should find that in -nographic mode Forth errors are logged to the console - does anything obvious stand out? If not, you'd probably have to look at modifying OpenBIOS to dump out the 10.5 bootloader to see what it's trying to do.
yes. I will look into that next.
Using -nographic, I get more info : "Not a bootable ELF image". That's something to look for !
That just means that OpenBIOS scanned through its list of recognised binaries and didn't match on ELF - presumably from your previous email it is a bootcode image, i.e. XML, possibly with a payload, so it would have subsequently recognised and matched on that.
You could try seeing if just loading the binary succeeds without invoking the failure on seek, and then follow this up with a go to execute the image directly:
load hd:3,\:tbxi go
If it freezes on go then that means its something in the bootloader failing in which case you may get further information by either enabling debug in the device tree:
cd / ffffffff encode-int " AAPL,debug" property boot
or perhaps passing the verbose parameter via the QEMU command line, e.g.
-prom-env 'boot-args=-v'
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 :)
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.
Cheers,
C.
On 06/12/2016 12:37 PM, Mark Cave-Ayland wrote:
On 11/06/16 18:32, Cédric Le Goater wrote:
On 06/08/2016 11:55 PM, Mark Cave-Ayland wrote:
On 08/06/16 20:38, Cédric Le Goater wrote:
Hello Mark,
On 06/08/2016 08:52 PM, Mark Cave-Ayland wrote:
On 08/06/16 14:48, Cédric Le Goater wrote:
So it is hd:3 and then, openbios dies directly :
... IN: 0xfff0d6c8: mr r28,r3 0xfff0d6cc: add r30,r30,r3 0xfff0d6d0: add r31,r31,r3 0xfff0d6d4: b 0xfff0d6a0
IN: 0xfff0d6a0: mr r3,r29 0xfff0d6a4: li r5,0 0xfff0d6a8: mr r6,r30 0xfff0d6ac: bl 0xfff279e8
IN: 0x00000300: .long 0x0
IN: 0x00000700: .long 0x0
which is this loop in bootcode_load() :
... bootcode = loadbase; offset = 0; while(1) { if (seek_io(fd, offset) == -1) break; count = read_io(fd, (void *)bootcode, 512); offset += count; bootcode += count; } ...Hi Cédric,
As a starting point, can you provide the contents of the root of the HD image as given with:
dir hd:3,\
0 > dir hd:3,\ 7065 2006-11-05 15:39:15 .\debugdata\debug.txt 0 2006-01-10 13:37:45 .com_symantec_symfs_private\ 12292 2002-05-16 10:37:41 .DS_Store 458752 2005-10-20 18:00:21 .hotfiles.btree 8388608 2005-07-12 03:37:09 .journal 4096 2005-07-12 03:37:09 .journal_info_block 0 2005-07-12 04:48:20 .Spotlight-V100\ 0 2006-01-09 10:49:19 .symSchedScanLockxz 0 2005-07-12 04:53:28 .Trashes\ 0 2005-03-22 00:01:29 .vol\ 0 2005-07-11 09:36:46 Applications\ 0 2005-07-11 17:21:58 Applications (Mac OS 9)\ 512 2005-12-28 17:51:55 Auth-DigitalPerformer 4.0 0 2005-12-02 17:25:12 automount\ 0 2005-07-11 10:28:40 bin\ 0 2005-05-28 17:05:33 cores\ 133120 2005-07-12 04:48:01 Desktop DB 715698 2005-07-12 04:48:01 Desktop DF 0 2003-10-32 14:57:45 Desktop Folder\ 0 2005-05-28 17:05:33 dev\ 0 2008-09-07 00:40:24 Developer\ 0 2005-11-15 13:13:52 Dossier Systeme\ 11 2005-07-12 03:37:16 etc 21579557 2006-09-19 08:26:22 gmon.out 60 2005-12-02 11:59:32 Guides de lutilisateur et informations 297 2005-01-09 16:29:43 Installer Log File 0 2005-07-11 10:22:09 Library\ 9 2015-05-28 12:06:55 mach 604360 2015-05-28 12:06:55 mach.sym 4352200 2007-10-12 01:26:11 mach_kernel 0 2005-11-17 19:04:29 Macintosh HD 13027540 2006-01-09 10:48:44 NAVMac800QSFile 0 2005-05-28 17:05:33 Network\ 29150 2005-01-18 09:35:39 Office 2004 11.1.0 Update Log 0 2005-07-11 10:19:09 private\ 0 2005-07-11 10:28:00 sbin\ 0 2006-11-02 08:15:23 sblibng.log 0 2005-07-11 09:36:30 System\ 0 2004-10-02 10:23:16 TheVolumeSettingsFolder\ 11 2005-07-12 03:37:52 tmp 0 2005-03-21 23:57:33 Users\ 0 2005-07-11 09:39:44 usr\ 11 2005-07-12 03:37:59 var 0 2005-03-22 00:01:29 Volumes\ 0 2005-07-12 03:30:28 HFS+ Private Data\ ok 0 >
That system was updated from Mac OS 9. That might be the issue.
Ah that could be it indeed. I've heard reports from people that installing Classic mode into a QEMU OS X causes it to fail to boot, but no-one has been able to provide an image to date. But it definitely looks like the right partition.
(it's much easier to cut/paste if you run qemu-system-ppc with -nographic). This is just to ensure that a HFS+ FS isn't accidentally getting picked up as a HFS filesystem (some driver partitions are set up this way).
How do I add more logging with openbios ?
You should find that in -nographic mode Forth errors are logged to the console - does anything obvious stand out? If not, you'd probably have to look at modifying OpenBIOS to dump out the 10.5 bootloader to see what it's trying to do.
yes. I will look into that next.
Using -nographic, I get more info : "Not a bootable ELF image". That's something to look for !
That just means that OpenBIOS scanned through its list of recognised binaries and didn't match on ELF - presumably from your previous email it is a bootcode image, i.e. XML, possibly with a payload, so it would have subsequently recognised and matched on that.
You could try seeing if just loading the binary succeeds without invoking the failure on seek, and then follow this up with a go to execute the image directly:
load hd:3,\:tbxi go
If it freezes on go then that means its something in the bootloader failing in which case you may get further information by either enabling debug in the device tree:
cd / ffffffff encode-int " AAPL,debug" property boot
or perhaps passing the verbose parameter via the QEMU command line, e.g.
-prom-env 'boot-args=-v'
FYI, I had to specify the path of BootX to get running.
Oh great! Is this something that could be added to the list of paths OpenBIOS searches for an executable on boot? If you can suggest a suitable place in the ordering, the patch to add it is fairly trivial.
It is a pretty standard path :
-prom-env 'boot-device=hd:3,\System\Library\CoreServices\BootX'
Here are some traces below,
Cheers,
C.
============================================================= OpenBIOS 1.1 [Jun 9 2016 11:48] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 1024M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Jun 9 2016 11:48 Trying hd:,\:tbxi...
MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open ',\:tbxi' MAC-PARTS: parstr: <NULL> argstr: \:tbxi parnum: -1 MAC-PARTS: want_bootcode 0 MAC-PARTS: macparts_open -1 MAC-PARTS: mac-parts: counted 4 partitions MAC-PARTS: found partition 1 type: Apple_partition_map with status 3 MAC-PARTS: found partition 2 type: Apple_Free with status 0 MAC-PARTS: found partition 3 type: Apple_HFS with status 40000033 MAC-PARTS: Located Apple OF fallback partition 3 MAC-PARTS: found partition 4 type: Apple_Free with status 0 MAC-PARTS: Selected partition 3 MAC-PARTS: mac-parts: about to probe for fs MAC-PARTS: mac-parts: done fs probe MAC-PARTS: mac-parts: filesystem found on partition 3 with ph fff51010 and args \:tbxi MAC-PARTS: macparts_seek 400: MAC-PARTS: macparts_seek parent offset 8008400: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 948a55c00: MAC-PARTS: macparts_seek parent offset 950a5dc00: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek d01000: MAC-PARTS: macparts_seek parent offset 8d09000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek ec9000: MAC-PARTS: macparts_seek parent offset 8ed1000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek eca000: MAC-PARTS: macparts_seek parent offset 8ed2000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87e000: MAC-PARTS: macparts_seek parent offset 152886000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87f000: MAC-PARTS: macparts_seek parent offset 152887000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a826000: MAC-PARTS: macparts_seek parent offset 15282e000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a827000: MAC-PARTS: macparts_seek parent offset 15282f000: MAC-PARTS: macparts_read search_files(): :tbxi MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open ',\:tbxi' MAC-PARTS: parstr: <NULL> argstr: \:tbxi parnum: -1 MAC-PARTS: want_bootcode 0 MAC-PARTS: macparts_open -1 MAC-PARTS: mac-parts: counted 4 partitions MAC-PARTS: found partition 1 type: Apple_partition_map with status 3 MAC-PARTS: found partition 2 type: Apple_Free with status 0 MAC-PARTS: found partition 3 type: Apple_HFS with status 40000033 MAC-PARTS: Located Apple OF fallback partition 3 MAC-PARTS: found partition 4 type: Apple_Free with status 0 MAC-PARTS: Selected partition 3 MAC-PARTS: mac-parts: about to probe for fs MAC-PARTS: mac-parts: done fs probe MAC-PARTS: mac-parts: filesystem found on partition 3 with ph fff51010 and args \:tbxi MAC-PARTS: macparts_seek 400: MAC-PARTS: macparts_seek parent offset 8008400: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 948a55c00: MAC-PARTS: macparts_seek parent offset 950a5dc00: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek d01000: MAC-PARTS: macparts_seek parent offset 8d09000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek ec9000: MAC-PARTS: macparts_seek parent offset 8ed1000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek eca000: MAC-PARTS: macparts_seek parent offset 8ed2000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87e000: MAC-PARTS: macparts_seek parent offset 152886000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87f000: MAC-PARTS: macparts_seek parent offset 152887000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a826000: MAC-PARTS: macparts_seek parent offset 15282e000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a827000:
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?
ATB,
Mark.
On 12/06/16 16:24, Cédric Le Goater wrote:
FYI, I had to specify the path of BootX to get running.
Oh great! Is this something that could be added to the list of paths OpenBIOS searches for an executable on boot? If you can suggest a suitable place in the ordering, the patch to add it is fairly trivial.
It is a pretty standard path :
-prom-env 'boot-device=hd:3,\System\Library\CoreServices\BootX'
Here are some traces below,
Cheers,
C.
============================================================= OpenBIOS 1.1 [Jun 9 2016 11:48] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 1024M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Jun 9 2016 11:48 Trying hd:,\:tbxi...
MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open ',\:tbxi' MAC-PARTS: parstr: <NULL> argstr: \:tbxi parnum: -1 MAC-PARTS: want_bootcode 0 MAC-PARTS: macparts_open -1 MAC-PARTS: mac-parts: counted 4 partitions MAC-PARTS: found partition 1 type: Apple_partition_map with status 3 MAC-PARTS: found partition 2 type: Apple_Free with status 0 MAC-PARTS: found partition 3 type: Apple_HFS with status 40000033 MAC-PARTS: Located Apple OF fallback partition 3 MAC-PARTS: found partition 4 type: Apple_Free with status 0 MAC-PARTS: Selected partition 3 MAC-PARTS: mac-parts: about to probe for fs MAC-PARTS: mac-parts: done fs probe MAC-PARTS: mac-parts: filesystem found on partition 3 with ph fff51010 and args \:tbxi MAC-PARTS: macparts_seek 400: MAC-PARTS: macparts_seek parent offset 8008400: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 948a55c00: MAC-PARTS: macparts_seek parent offset 950a5dc00: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek d01000: MAC-PARTS: macparts_seek parent offset 8d09000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek ec9000: MAC-PARTS: macparts_seek parent offset 8ed1000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek eca000: MAC-PARTS: macparts_seek parent offset 8ed2000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87e000: MAC-PARTS: macparts_seek parent offset 152886000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87f000: MAC-PARTS: macparts_seek parent offset 152887000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a826000: MAC-PARTS: macparts_seek parent offset 15282e000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a827000: MAC-PARTS: macparts_seek parent offset 15282f000: MAC-PARTS: macparts_read search_files(): :tbxi MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open ',\:tbxi' MAC-PARTS: parstr: <NULL> argstr: \:tbxi parnum: -1 MAC-PARTS: want_bootcode 0 MAC-PARTS: macparts_open -1 MAC-PARTS: mac-parts: counted 4 partitions MAC-PARTS: found partition 1 type: Apple_partition_map with status 3 MAC-PARTS: found partition 2 type: Apple_Free with status 0 MAC-PARTS: found partition 3 type: Apple_HFS with status 40000033 MAC-PARTS: Located Apple OF fallback partition 3 MAC-PARTS: found partition 4 type: Apple_Free with status 0 MAC-PARTS: Selected partition 3 MAC-PARTS: mac-parts: about to probe for fs MAC-PARTS: mac-parts: done fs probe MAC-PARTS: mac-parts: filesystem found on partition 3 with ph fff51010 and args \:tbxi MAC-PARTS: macparts_seek 400: MAC-PARTS: macparts_seek parent offset 8008400: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 948a55c00: MAC-PARTS: macparts_seek parent offset 950a5dc00: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek d01000: MAC-PARTS: macparts_seek parent offset 8d09000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek ec9000: MAC-PARTS: macparts_seek parent offset 8ed1000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek eca000: MAC-PARTS: macparts_seek parent offset 8ed2000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87e000: MAC-PARTS: macparts_seek parent offset 152886000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87f000: MAC-PARTS: macparts_seek parent offset 152887000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a826000: MAC-PARTS: macparts_seek parent offset 15282e000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a827000:
Does installation of BootX bless "\System\Library\CoreServices\BootX" as the system folder at all? If not, then it won't be picked up by OpenBIOS. Perhaps on a real Mac the boot command containing the full path to BootX is updated in the NVRAM?
If BootX should always be used where it exists in preference to the blessed system folder, then possibly it should be added to the head of the boot list in arch/ppc/qemu/init.c line 980? Or would this break some boot scenarios?
ATB,
Mark.
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
On 06/12/2016 05:38 PM, Mark Cave-Ayland wrote:
On 12/06/16 16:24, Cédric Le Goater wrote:
FYI, I had to specify the path of BootX to get running.
Oh great! Is this something that could be added to the list of paths OpenBIOS searches for an executable on boot? If you can suggest a suitable place in the ordering, the patch to add it is fairly trivial.
It is a pretty standard path :
-prom-env 'boot-device=hd:3,\System\Library\CoreServices\BootX'
Here are some traces below,
Cheers,
C.
============================================================= OpenBIOS 1.1 [Jun 9 2016 11:48] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 1024M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Jun 9 2016 11:48 Trying hd:,\:tbxi...
MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open ',\:tbxi' MAC-PARTS: parstr: <NULL> argstr: \:tbxi parnum: -1 MAC-PARTS: want_bootcode 0 MAC-PARTS: macparts_open -1 MAC-PARTS: mac-parts: counted 4 partitions MAC-PARTS: found partition 1 type: Apple_partition_map with status 3 MAC-PARTS: found partition 2 type: Apple_Free with status 0 MAC-PARTS: found partition 3 type: Apple_HFS with status 40000033 MAC-PARTS: Located Apple OF fallback partition 3 MAC-PARTS: found partition 4 type: Apple_Free with status 0 MAC-PARTS: Selected partition 3 MAC-PARTS: mac-parts: about to probe for fs MAC-PARTS: mac-parts: done fs probe MAC-PARTS: mac-parts: filesystem found on partition 3 with ph fff51010 and args \:tbxi MAC-PARTS: macparts_seek 400: MAC-PARTS: macparts_seek parent offset 8008400: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 948a55c00: MAC-PARTS: macparts_seek parent offset 950a5dc00: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek d01000: MAC-PARTS: macparts_seek parent offset 8d09000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek ec9000: MAC-PARTS: macparts_seek parent offset 8ed1000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek eca000: MAC-PARTS: macparts_seek parent offset 8ed2000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87e000: MAC-PARTS: macparts_seek parent offset 152886000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87f000: MAC-PARTS: macparts_seek parent offset 152887000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a826000: MAC-PARTS: macparts_seek parent offset 15282e000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a827000: MAC-PARTS: macparts_seek parent offset 15282f000: MAC-PARTS: macparts_read search_files(): :tbxi MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open ',\:tbxi' MAC-PARTS: parstr: <NULL> argstr: \:tbxi parnum: -1 MAC-PARTS: want_bootcode 0 MAC-PARTS: macparts_open -1 MAC-PARTS: mac-parts: counted 4 partitions MAC-PARTS: found partition 1 type: Apple_partition_map with status 3 MAC-PARTS: found partition 2 type: Apple_Free with status 0 MAC-PARTS: found partition 3 type: Apple_HFS with status 40000033 MAC-PARTS: Located Apple OF fallback partition 3 MAC-PARTS: found partition 4 type: Apple_Free with status 0 MAC-PARTS: Selected partition 3 MAC-PARTS: mac-parts: about to probe for fs MAC-PARTS: mac-parts: done fs probe MAC-PARTS: mac-parts: filesystem found on partition 3 with ph fff51010 and args \:tbxi MAC-PARTS: macparts_seek 400: MAC-PARTS: macparts_seek parent offset 8008400: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 948a55c00: MAC-PARTS: macparts_seek parent offset 950a5dc00: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek d01000: MAC-PARTS: macparts_seek parent offset 8d09000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek ec9000: MAC-PARTS: macparts_seek parent offset 8ed1000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek eca000: MAC-PARTS: macparts_seek parent offset 8ed2000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87e000: MAC-PARTS: macparts_seek parent offset 152886000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87f000: MAC-PARTS: macparts_seek parent offset 152887000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a826000: MAC-PARTS: macparts_seek parent offset 15282e000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a827000:
Does installation of BootX bless "\System\Library\CoreServices\BootX" as the system folder at all? If not, then it won't be picked up by OpenBIOS. Perhaps on a real Mac the boot command containing the full path to BootX is updated in the NVRAM?
If BootX should always be used where it exists in preference to the blessed system folder, then possibly it should be added to the head of the boot list in arch/ppc/qemu/init.c line 980? Or would this break some boot scenarios?
the BootX file contains a bootloader text header :
<CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Boot Loader for Mac OS X. </DESCRIPTION> <OS-BADGE-ICONS> 1010 00000000000000000000000000000000 000000000000000000000000F8000000 000000002B73732B0055735500F80000 00000000F5799DF6004F792B0000F800 0000000000F69D4E004F2B000000F800 000000000000559D2A55F500000000F8 000000000000F69D732B0000000000F8 000000000000004F96F50000000000F8 00000000000000799D4E0000000000F8 0000000000002AF8559D0000000000F8 00000000000079F6F59D4E00000000F8 00000000004E4F00005573000000F800 000000004F9D55F5004F9D4FF500F800 0000F800557A56F50055567A2BF80000 000000F8F8000000000000F8F8000000 0000000000F8F8F8F8F8F80000000000
0000000000F7F7F7F7F7F70000000000 000000F7F7F7F7F7F7F7F7F781000000 0000F7F7F99E9EF9F7809E80F7810000 00F7F7F7F8A4C856F77AA4F9F7F78100 00F7F7F7F756C879F77AF9F7F7F78100 F7F7F7F7F7F780C85580F8F7F7F7F781 F7F7F7F7F7F756C89EF9F7F7F7F7F781 F7F7F7F7F7F7F77AC1F8F7F7F7F7F781 F7F7F7F7F7F7F7A4C879F7F7F7F7F781 F7F7F7F7F7F7558180C8F7F7F7F7F781 F7F7F7F7F7F7A456F8C879F7F7F7F781 00F7F7F7F7797AF7F7809EF7F7F78100 00F7F7F77AC880F8F77AC87AF8F78100 000081F780A5FBF8F780FBA5F9810000 0000008181F7F7F7F7F7F78181000000 00000000008181818181810000000000
0000000000FFFFFFFFFFFF0000000000 000000FFFFFFFFFFFFFFFFFFFF000000 0000FFFFFFFFFFFFFFFFFFFFFFFF0000 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 0000FFFFFFFFFFFFFFFFFFFFFFFF0000 000000FFFFFFFFFFFFFFFFFFFF000000 0000000000FFFFFFFFFFFF0000000000 </OS-BADGE-ICONS> <BOOT-SCRIPT> load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go </BOOT-SCRIPT> </CHRP-BOOT>
Then something that looks like a Mach-o ppc exe.
Is that something expected by OpenBIOS ?
C.
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.
On 19/06/16 14:04, Cédric Le Goater wrote:
On 06/12/2016 05:38 PM, Mark Cave-Ayland wrote:
On 12/06/16 16:24, Cédric Le Goater wrote:
FYI, I had to specify the path of BootX to get running.
Oh great! Is this something that could be added to the list of paths OpenBIOS searches for an executable on boot? If you can suggest a suitable place in the ordering, the patch to add it is fairly trivial.
It is a pretty standard path :
-prom-env 'boot-device=hd:3,\System\Library\CoreServices\BootX'
Here are some traces below,
Cheers,
C.
============================================================= OpenBIOS 1.1 [Jun 9 2016 11:48] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 1024M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Jun 9 2016 11:48 Trying hd:,\:tbxi...
MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open ',\:tbxi' MAC-PARTS: parstr: <NULL> argstr: \:tbxi parnum: -1 MAC-PARTS: want_bootcode 0 MAC-PARTS: macparts_open -1 MAC-PARTS: mac-parts: counted 4 partitions MAC-PARTS: found partition 1 type: Apple_partition_map with status 3 MAC-PARTS: found partition 2 type: Apple_Free with status 0 MAC-PARTS: found partition 3 type: Apple_HFS with status 40000033 MAC-PARTS: Located Apple OF fallback partition 3 MAC-PARTS: found partition 4 type: Apple_Free with status 0 MAC-PARTS: Selected partition 3 MAC-PARTS: mac-parts: about to probe for fs MAC-PARTS: mac-parts: done fs probe MAC-PARTS: mac-parts: filesystem found on partition 3 with ph fff51010 and args \:tbxi MAC-PARTS: macparts_seek 400: MAC-PARTS: macparts_seek parent offset 8008400: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 948a55c00: MAC-PARTS: macparts_seek parent offset 950a5dc00: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek d01000: MAC-PARTS: macparts_seek parent offset 8d09000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek ec9000: MAC-PARTS: macparts_seek parent offset 8ed1000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek eca000: MAC-PARTS: macparts_seek parent offset 8ed2000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87e000: MAC-PARTS: macparts_seek parent offset 152886000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87f000: MAC-PARTS: macparts_seek parent offset 152887000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a826000: MAC-PARTS: macparts_seek parent offset 15282e000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a827000: MAC-PARTS: macparts_seek parent offset 15282f000: MAC-PARTS: macparts_read search_files(): :tbxi MAC-PARTS: macparts_probe 4552 ?= 4552 MAC-PARTS: macparts_open ',\:tbxi' MAC-PARTS: parstr: <NULL> argstr: \:tbxi parnum: -1 MAC-PARTS: want_bootcode 0 MAC-PARTS: macparts_open -1 MAC-PARTS: mac-parts: counted 4 partitions MAC-PARTS: found partition 1 type: Apple_partition_map with status 3 MAC-PARTS: found partition 2 type: Apple_Free with status 0 MAC-PARTS: found partition 3 type: Apple_HFS with status 40000033 MAC-PARTS: Located Apple OF fallback partition 3 MAC-PARTS: found partition 4 type: Apple_Free with status 0 MAC-PARTS: Selected partition 3 MAC-PARTS: mac-parts: about to probe for fs MAC-PARTS: mac-parts: done fs probe MAC-PARTS: mac-parts: filesystem found on partition 3 with ph fff51010 and args \:tbxi MAC-PARTS: macparts_seek 400: MAC-PARTS: macparts_seek parent offset 8008400: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 948a55c00: MAC-PARTS: macparts_seek parent offset 950a5dc00: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek d01000: MAC-PARTS: macparts_seek parent offset 8d09000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek ec9000: MAC-PARTS: macparts_seek parent offset 8ed1000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek eca000: MAC-PARTS: macparts_seek parent offset 8ed2000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87e000: MAC-PARTS: macparts_seek parent offset 152886000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a87f000: MAC-PARTS: macparts_seek parent offset 152887000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a826000: MAC-PARTS: macparts_seek parent offset 15282e000: MAC-PARTS: macparts_read MAC-PARTS: macparts_seek 14a827000:
Does installation of BootX bless "\System\Library\CoreServices\BootX" as the system folder at all? If not, then it won't be picked up by OpenBIOS. Perhaps on a real Mac the boot command containing the full path to BootX is updated in the NVRAM?
If BootX should always be used where it exists in preference to the blessed system folder, then possibly it should be added to the head of the boot list in arch/ppc/qemu/init.c line 980? Or would this break some boot scenarios?
the BootX file contains a bootloader text header :
<CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Boot Loader for Mac OS X. </DESCRIPTION> <OS-BADGE-ICONS> 1010 00000000000000000000000000000000 000000000000000000000000F8000000 000000002B73732B0055735500F80000 00000000F5799DF6004F792B0000F800 0000000000F69D4E004F2B000000F800 000000000000559D2A55F500000000F8 000000000000F69D732B0000000000F8 000000000000004F96F50000000000F8 00000000000000799D4E0000000000F8 0000000000002AF8559D0000000000F8 00000000000079F6F59D4E00000000F8 00000000004E4F00005573000000F800 000000004F9D55F5004F9D4FF500F800 0000F800557A56F50055567A2BF80000 000000F8F8000000000000F8F8000000 0000000000F8F8F8F8F8F80000000000
0000000000F7F7F7F7F7F70000000000 000000F7F7F7F7F7F7F7F7F781000000 0000F7F7F99E9EF9F7809E80F7810000 00F7F7F7F8A4C856F77AA4F9F7F78100 00F7F7F7F756C879F77AF9F7F7F78100 F7F7F7F7F7F780C85580F8F7F7F7F781 F7F7F7F7F7F756C89EF9F7F7F7F7F781 F7F7F7F7F7F7F77AC1F8F7F7F7F7F781 F7F7F7F7F7F7F7A4C879F7F7F7F7F781 F7F7F7F7F7F7558180C8F7F7F7F7F781 F7F7F7F7F7F7A456F8C879F7F7F7F781 00F7F7F7F7797AF7F7809EF7F7F78100 00F7F7F77AC880F8F77AC87AF8F78100 000081F780A5FBF8F780FBA5F9810000 0000008181F7F7F7F7F7F78181000000 00000000008181818181810000000000
0000000000FFFFFFFFFFFF0000000000 000000FFFFFFFFFFFFFFFFFFFF000000 0000FFFFFFFFFFFFFFFFFFFFFFFF0000 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 0000FFFFFFFFFFFFFFFFFFFFFFFF0000 000000FFFFFFFFFFFFFFFFFFFF000000 0000000000FFFFFFFFFFFF0000000000
</OS-BADGE-ICONS> <BOOT-SCRIPT> load-base begin dup 6 " </CHRP" $= if 6 + dup 6 " -BOOT>" $= if 8 + true else false then else 1+ false then until ( xcoff-base ) load-size over load-base - - ( xcoff-base xcoff-size ) load-base swap move init-program go </BOOT-SCRIPT> </CHRP-BOOT>
Then something that looks like a Mach-o ppc exe.
Is that something expected by OpenBIOS ?
Yes indeed, the MacOS 9 loader does something very similar - take a look at http://git.qemu.org/?p=openbios.git;a=commitdiff;h=6d4fd191864d49bc56890088b... and also some of the related discussions to this in the archives around that time.
Given that you can type the boot command in directly and it works, then I can only see two things here: i) real BootX overwrites the boot device in NVRAM forcing itself to run or ii) OpenBIOS isn't correctly detecting the BootX directory as blessed. If the answer is i) then the solution is to simply add the path to BootX to the top of the OpenBIOS search list.
ATB,
Mark.
-
Cédric Le Goater -
Mark Cave-Ayland -
Programmingkid -
Segher Boessenkool