Hi all,
I've been asked by Mark to report my testings here.
Tested with qemu-for-ppc-2.8 commit 8b0262d0bcb7c697f2db8d6cd731cb478937902a.
Command line: qemu-system-ppc -M mac99 -m 256 -prom-env 'boot-args=-v' -bios foo/openbios-qemu-vga.elf -boot d -prom-env 'auto-boot?=false' -hda foo.qc2 -cdrom DP.iso -nographic -cpu G3
Developer Preview 1: Welcome to OpenBIOS v1.1 built on Jul 31 2016 05:52
0 > boot cd:9,\:tbxi this image is not for this platformNo valid state has been set by load or init-program ok 0 >
Developer Preview 2: Kernel panic, see attachment.
Developer Preview 3: Boots, installer doesn't allow to choose destination drive, doesn't matter if it's empty or not.
Developer Preview 4 and Public Beta: Still waiting for root device
On 04/08/16 15:26, Natalia Portillo wrote:
Hi all,
I've been asked by Mark to report my testings here.
Tested with qemu-for-ppc-2.8 commit 8b0262d0bcb7c697f2db8d6cd731cb478937902a.
Command line: qemu-system-ppc -M mac99 -m 256 -prom-env 'boot-args=-v' -bios foo/openbios-qemu-vga.elf -boot d -prom-env 'auto-boot?=false' -hda foo.qc2 -cdrom DP.iso -nographic -cpu G3
Developer Preview 1: Welcome to OpenBIOS v1.1 built on Jul 31 2016 05:52
0 > boot cd:9,\:tbxi this image is not for this platformNo valid state has been set by load or init-program ok 0 >
Developer Preview 2: Kernel panic, see attachment.
Developer Preview 3: Boots, installer doesn't allow to choose destination drive, doesn't matter if it's empty or not.
Developer Preview 4 and Public Beta: Still waiting for root device
Thanks for comprehensive testing :)
Let's start with the DP 3, 4 and PB being unable to identify the root device. The first step here is to get the macio/dbdma logs from QEMU - please can you enable DEBUG_MACIO in hw/ide/macio.c and DEBUG_DBDMA in hw/misc/macio/mac_dbdma.c and post the logs for either DP 4 or PB somewhere where I can grab them?
Many thanks,
Mark.
Hi Mark,
https://mega.nz/#F!pBhHlahQ!S-Z5KG08pp49fpnKxtlIoA
Does that work for you?
I can add more logs later there.
On 04/08/16 20:22, Mark Cave-Ayland wrote:
On 04/08/16 15:26, Natalia Portillo wrote:
Hi all,
I've been asked by Mark to report my testings here.
Tested with qemu-for-ppc-2.8 commit 8b0262d0bcb7c697f2db8d6cd731cb478937902a.
Command line: qemu-system-ppc -M mac99 -m 256 -prom-env 'boot-args=-v' -bios foo/openbios-qemu-vga.elf -boot d -prom-env 'auto-boot?=false' -hda foo.qc2 -cdrom DP.iso -nographic -cpu G3
Developer Preview 1: Welcome to OpenBIOS v1.1 built on Jul 31 2016 05:52
0 > boot cd:9,\:tbxi this image is not for this platformNo valid state has been set by load or init-program ok 0 >
Developer Preview 2: Kernel panic, see attachment.
Developer Preview 3: Boots, installer doesn't allow to choose destination drive, doesn't matter if it's empty or not.
Developer Preview 4 and Public Beta: Still waiting for root device
Thanks for comprehensive testing :)
Let's start with the DP 3, 4 and PB being unable to identify the root device. The first step here is to get the macio/dbdma logs from QEMU - please can you enable DEBUG_MACIO in hw/ide/macio.c and DEBUG_DBDMA in hw/misc/macio/mac_dbdma.c and post the logs for either DP 4 or PB somewhere where I can grab them?
Many thanks,
Mark.
On 04/08/16 20:22, Mark Cave-Ayland wrote:
Thanks for comprehensive testing :)
Let's start with the DP 3, 4 and PB being unable to identify the root device. The first step here is to get the macio/dbdma logs from QEMU - please can you enable DEBUG_MACIO in hw/ide/macio.c and DEBUG_DBDMA in hw/misc/macio/mac_dbdma.c and post the logs for either DP 4 or PB somewhere where I can grab them?
Thanks for the logs - I think I can see what is going wrong with the public beta, it's failing trying to read the TOC here:
------------ IDE transfer buffer_size: 14 buffer_index: 0 lba: ffffffff size: 14 ------------------------- DBDMA[1a]: writel 0x0000000000000d00 <= 0xd8009000 DBDMA[1a]: channel 0x1a reg 0x0 DBDMA[1a]: status 0x00009400 DBDMA: -> DBDMA_run_bh DBDMA[1a]: channel_run dbdma_cmd 0x55aed8ac1430 req_count 0x0800 command 0x2000 phy_addr 0x010ca000 cmd_dep 0x00000000 res_count 0x0000 xfer_status 0x0000 DBDMA[1a]: start_input DBDMA[1a]: addr 0x10ca000 key 0x0
pmac_ide_atapi_transfer_cb DBDMA[1a]: dbdma_end DBDMA[1a]: conditional_wait DBDMA[1a]: dbdma_cmdptr_save 0x01072000 DBDMA[1a]: xfer_status 0x00008400 res_count 0x0800 DBDMA[1a]: conditional_interrupt DBDMA[1a]: conditional_branch DBDMA[1a]: dbdma_cmdptr_load 0x01072010 DBDMA[1a]: channel_run dbdma_cmd 0x55aed8ac1430 req_count 0x0000 command 0x7000 phy_addr 0x00000000 cmd_dep 0x00000000 res_count 0x0000 xfer_status 0x0000 DBDMA: <- DBDMA_run_bh DBDMA[1a]: writel 0x0000000000000d00 <= 0xa0002000 DBDMA[1a]: channel 0x1a reg 0x0 DBDMA[1a]: status 0x00000000 DBDMA[1a]: readl 0x0000000000000d04 => 0x00000000 DBDMA[1a]: channel 0x1a reg 0x1 DBDMA[1a]: writel 0x0000000000000d00 <= 0xfc000000 DBDMA[1a]: channel 0x1a reg 0x0 DBDMA[1a]: status 0x00000000 DBDMA[1a]: readl 0x0000000000000d04 => 0x00000000 DBDMA[1a]: channel 0x1a reg 0x1 DBDMA[1a]: writel 0x0000000000000d08 <= 0x00000000 DBDMA[1a]: channel 0x1a reg 0x2 DBDMA[1a]: writel 0x0000000000000d0c <= 0x01072000 DBDMA[1a]: channel 0x1a reg 0x3 DBDMA[1a]: dbdma_cmdptr_load 0x01072000
This corresponds to this code in QEMU's hw/ide/macio.c:
if (s->lba == -1) { /* Non-block ATAPI transfer - just copy to RAM */ s->io_buffer_size = MIN(s->io_buffer_size, io->len); dma_memory_write(&address_space_memory, io->addr, s->io_buffer, s->io_buffer_size); ide_atapi_cmd_ok(s); m->dma_active = false; goto done; }
Here the QEMU block code should have already placed the generated TOC into s->io_buffer and DMA the first 14 bytes into RAM but for some reason that's not happening so the code is looping looking for a signature that isn't present.
Zoltan: this is very similar to the related issue you had with your MorphOS tests which this code should have resolved, unless I managed to get something wrong in my last rewrite of the macio code?
ATB,
Mark.
On Thu, 4 Aug 2016, Mark Cave-Ayland wrote:
This corresponds to this code in QEMU's hw/ide/macio.c:
if (s->lba == -1) { /* Non-block ATAPI transfer - just copy to RAM */ s->io_buffer_size = MIN(s->io_buffer_size, io->len); dma_memory_write(&address_space_memory, io->addr, s->io_buffer, s->io_buffer_size); ide_atapi_cmd_ok(s); m->dma_active = false; goto done; }
Here the QEMU block code should have already placed the generated TOC into s->io_buffer and DMA the first 14 bytes into RAM but for some reason that's not happening so the code is looping looking for a signature that isn't present.
Zoltan: this is very similar to the related issue you had with your MorphOS tests which this code should have resolved, unless I managed to get something wrong in my last rewrite of the macio code?
The above code did fix this in MorphOS back then but I haven't tried it recently (no time for it now). But I'd assume other OS-es would also be affected if it broke. Maybe to cross check you could also try OS X DP with a version before your last rewrite.
Regards, BALATON Zoltan
On 04/08/16 22:22, BALATON Zoltan wrote:
On Thu, 4 Aug 2016, Mark Cave-Ayland wrote:
This corresponds to this code in QEMU's hw/ide/macio.c:
if (s->lba == -1) { /* Non-block ATAPI transfer - just copy to RAM */ s->io_buffer_size = MIN(s->io_buffer_size, io->len); dma_memory_write(&address_space_memory, io->addr, s->io_buffer, s->io_buffer_size); ide_atapi_cmd_ok(s); m->dma_active = false; goto done; }
Here the QEMU block code should have already placed the generated TOC into s->io_buffer and DMA the first 14 bytes into RAM but for some reason that's not happening so the code is looping looking for a signature that isn't present.
Zoltan: this is very similar to the related issue you had with your MorphOS tests which this code should have resolved, unless I managed to get something wrong in my last rewrite of the macio code?
The above code did fix this in MorphOS back then but I haven't tried it recently (no time for it now). But I'd assume other OS-es would also be affected if it broke. Maybe to cross check you could also try OS X DP with a version before your last rewrite.
Oh wait - I think the problem is that the status count isn't being set to zero if you take the non-block codepath, and so the driver may consider the request failed if it checks res_count afterwards:
pmac_ide_atapi_transfer_cb DBDMA[1a]: dbdma_end DBDMA[1a]: conditional_wait DBDMA[1a]: dbdma_cmdptr_save 0x01072000 DBDMA[1a]: xfer_status 0x00008400 res_count 0x0800 ^^^^^^ DBDMA[1a]: conditional_interrupt DBDMA[1a]: conditional_branch DBDMA[1a]: dbdma_cmdptr_load 0x01072010 DBDMA[1a]: channel_run
Does the following patch for QEMU help at all?
diff --git a/hw/ide/macio.c b/hw/ide/macio.c index 5a326af..76f97c2 100644 --- a/hw/ide/macio.c +++ b/hw/ide/macio.c @@ -273,6 +273,7 @@ static void pmac_ide_atapi_transfer_cb(void *opaque, int ret) s->io_buffer_size = MIN(s->io_buffer_size, io->len); dma_memory_write(&address_space_memory, io->addr, s->io_buffer, s->io_buffer_size); + io->len = 0; ide_atapi_cmd_ok(s); m->dma_active = false; goto done;
ATB,
Mark.
Ok Mark, Public Beta went farther. Rest same. Logs and screendump uploaded.
On 04/08/16 23:06, Mark Cave-Ayland wrote:
On 04/08/16 22:22, BALATON Zoltan wrote:
On Thu, 4 Aug 2016, Mark Cave-Ayland wrote:
This corresponds to this code in QEMU's hw/ide/macio.c:
if (s->lba == -1) { /* Non-block ATAPI transfer - just copy to RAM */ s->io_buffer_size = MIN(s->io_buffer_size, io->len); dma_memory_write(&address_space_memory, io->addr, s->io_buffer, s->io_buffer_size); ide_atapi_cmd_ok(s); m->dma_active = false; goto done; }
Here the QEMU block code should have already placed the generated TOC into s->io_buffer and DMA the first 14 bytes into RAM but for some reason that's not happening so the code is looping looking for a signature that isn't present.
Zoltan: this is very similar to the related issue you had with your MorphOS tests which this code should have resolved, unless I managed to get something wrong in my last rewrite of the macio code?
The above code did fix this in MorphOS back then but I haven't tried it recently (no time for it now). But I'd assume other OS-es would also be affected if it broke. Maybe to cross check you could also try OS X DP with a version before your last rewrite.
Oh wait - I think the problem is that the status count isn't being set to zero if you take the non-block codepath, and so the driver may consider the request failed if it checks res_count afterwards:
pmac_ide_atapi_transfer_cb DBDMA[1a]: dbdma_end DBDMA[1a]: conditional_wait DBDMA[1a]: dbdma_cmdptr_save 0x01072000 DBDMA[1a]: xfer_status 0x00008400 res_count 0x0800 ^^^^^^ DBDMA[1a]: conditional_interrupt DBDMA[1a]: conditional_branch DBDMA[1a]: dbdma_cmdptr_load 0x01072010 DBDMA[1a]: channel_run
Does the following patch for QEMU help at all?
diff --git a/hw/ide/macio.c b/hw/ide/macio.c index 5a326af..76f97c2 100644 --- a/hw/ide/macio.c +++ b/hw/ide/macio.c @@ -273,6 +273,7 @@ static void pmac_ide_atapi_transfer_cb(void *opaque, int ret) s->io_buffer_size = MIN(s->io_buffer_size, io->len); dma_memory_write(&address_space_memory, io->addr, s->io_buffer, s->io_buffer_size);
io->len = 0; ide_atapi_cmd_ok(s); m->dma_active = false; goto done;ATB,
Mark.
On 04/08/16 23:49, Natalia Portillo wrote:
Ok Mark, Public Beta went farther. Rest same. Logs and screendump uploaded.
Ah great - it's now getting to "kmod_create: ATIR128 (id 1), 23 pages loaded at 0x7663000, header size 0x1000".
So it's failing trying to poke the R128 graphics card, not sure that I can help too much with that part but I can at least send the macio patch upstream - thanks for testing!
ATB,
Mark.
Hi Mark,
It stops there. I'm not sure it stops BECAUSE of that.
In the MEGA folder I added xnu debug output logs.
Last part is: QEMU,VGA 23 00000003 00000000 IONDRVFramebuffer 23 00000003 00000000 NE2000 23 00000003 00000000 mac-io 23 00000003 00000000 Heathrow 23 00000003 00000000 IOATAHDDrive 23 00000003 00000000 IOATAPIDVDDrive 23 00000003 00000000 IOPMrootDomain 22 00000001 00000000 IOPMrootDomain 35 00000001 00000000 IOPMrootDomain 29 00000001 00000000
Also on console it says:
kmod_create: ATIR128 (id 1), 23 pages loaded at 0x7654000, header size 0x1000 config(0): creating Matching service count = 1 config(11087c0): starting on IONDRVFrameBuffer, 10 ATIR128::attach(IONDRVFramebuffer) ATIR128::probe(IONDRVFramebuffer) ATIR128::detach(IONDRVFramebuffer) ATIR128::probe fails config(11087c0): terminating IOHIDUserClient::attach(IOHIDSystem)
I suspect seeing that, it checks for the presence of an ATI Rage128, not found, continues, attaches IOHIDUserClient.kext, crashes there.
To confirm that, I modified the image to remove the ATI kexts, and all references to ATIR128 disappeared and it hangs at IOHIDUerClient::attach(IOHIDSystem).
Logs uploaded as publicbeta_*_debug_8_nok.log
On 05/08/16 07:57, Mark Cave-Ayland wrote:
On 04/08/16 23:49, Natalia Portillo wrote:
Ok Mark, Public Beta went farther. Rest same. Logs and screendump uploaded.
Ah great - it's now getting to "kmod_create: ATIR128 (id 1), 23 pages loaded at 0x7663000, header size 0x1000".
So it's failing trying to poke the R128 graphics card, not sure that I can help too much with that part but I can at least send the macio patch upstream - thanks for testing!
ATB,
Mark.
-
BALATON Zoltan -
Mark Cave-Ayland -
Natalia Portillo