I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
On 11/11/15 15:15, Programmingkid wrote:
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
I've done quite a bit of work on Cormac's tree (primarily to fix CUDA issues that broke OS X among other things) and posted it to the qemu-devel list at https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
The patchset posted works well for me here, and I suspect will fix the issues that you've been seeing. Note that you'll also need the separate OpenBIOS binary mentioned in the link above if you want to try booting OS 9 since one of the OpenBIOS patches hasn't been applied to trunk since it regresses other images.
ATB,
Mark.
On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
On 11/11/15 15:15, Programmingkid wrote:
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
I've done quite a bit of work on Cormac's tree (primarily to fix CUDA issues that broke OS X among other things) and posted it to the qemu-devel list at https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
The patchset posted works well for me here, and I suspect will fix the issues that you've been seeing. Note that you'll also need the separate OpenBIOS binary mentioned in the link above if you want to try booting OS 9 since one of the OpenBIOS patches hasn't been applied to trunk since it regresses other images.
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
On 11.11.15 19:55, Programmingkid wrote:
On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
On 11/11/15 15:15, Programmingkid wrote:
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
I've done quite a bit of work on Cormac's tree (primarily to fix CUDA issues that broke OS X among other things) and posted it to the qemu-devel list at https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
The patchset posted works well for me here, and I suspect will fix the issues that you've been seeing. Note that you'll also need the separate OpenBIOS binary mentioned in the link above if you want to try booting OS 9 since one of the OpenBIOS patches hasn't been applied to trunk since it regresses other images.
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. Unfortunately it still doesn't work ... but hope is still here ;)
Mark, is your complete qemu patch available somewhere? Then I could test 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
TIA, Andreas
On Nov 11, 2015, at 4:32 PM, Andreas Tobler wrote:
On 11.11.15 19:55, Programmingkid wrote:
On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
On 11/11/15 15:15, Programmingkid wrote:
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
I've done quite a bit of work on Cormac's tree (primarily to fix CUDA issues that broke OS X among other things) and posted it to the qemu-devel list at https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
The patchset posted works well for me here, and I suspect will fix the issues that you've been seeing. Note that you'll also need the separate OpenBIOS binary mentioned in the link above if you want to try booting OS 9 since one of the OpenBIOS patches hasn't been applied to trunk since it regresses other images.
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. Unfortunately it still doesn't work ... but hope is still here ;)
On a new world Mac? I'm thinking a mistake has been made. Maybe you mean via-pmu? According to FreeBSD's website all Macintoshes with a built-in USB port are supported. This would only mean new world Macs and they only have a via-pmu - no cuda device.
Mark, is your complete qemu patch available somewhere? Then I could test 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
I'm thinking removing ADB support would fix this problem. Most real new world Macs have no ADB support.
On Wed, 11 Nov 2015, Programmingkid wrote:
On Nov 11, 2015, at 4:32 PM, Andreas Tobler wrote:
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. Unfortunately it still doesn't work ... but hope is still here ;)
On a new world Mac? I'm thinking a mistake has been made. Maybe you mean via-pmu? According to FreeBSD's website all Macintoshes with a built-in USB port are supported. This would only mean new world Macs and they only have a via-pmu - no cuda device.
I think you are right that mac99 should have via-pmu instead of cuda but it is not as simple as renaming it in the device tree because it is a different chip which we have no emulation for so first an emulation should be written. It is probably similar enough to cuda so using cuda instead works as long as the OS in only using the main functions. It is also hard to find a documentation on how via-pmu should behave. I've only found this:
http://mcosre.sourceforge.net/docs/apple_io.html
which is not very clear or detailed. The only hint from it was that pmu99 uses gpio which I've seen OS-es try to access but I don't know anything on that or what should be emulated for it.
Mark, is your complete qemu patch available somewhere? Then I could test 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
I'm thinking removing ADB support would fix this problem. Most real new world Macs have no ADB support.
This may be a good idea to match the hardware we are trying to emulate better but some OSes may depend on ADB for now. I've noticed Finnix had no keyboard in debug mode without ADB (which may be a bug in Finnix, I could not verify if it works on real hardware or has the same problem there).
Regards, BALATON Zoltan
On Nov 11, 2015, at 6:14 PM, BALATON Zoltan wrote:
On Wed, 11 Nov 2015, Programmingkid wrote:
On Nov 11, 2015, at 4:32 PM, Andreas Tobler wrote:
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. Unfortunately it still doesn't work ... but hope is still here ;)
On a new world Mac? I'm thinking a mistake has been made. Maybe you mean via-pmu? According to FreeBSD's website all Macintoshes with a built-in USB port are supported. This would only mean new world Macs and they only have a via-pmu - no cuda device.
I think you are right that mac99 should have via-pmu instead of cuda but it is not as simple as renaming it in the device tree because it is a different chip which we have no emulation for so first an emulation should be written. It is probably similar enough to cuda so using cuda instead works as long as the OS in only using the main functions. It is also hard to find a documentation on how via-pmu should behave. I've only found this:
http://mcosre.sourceforge.net/docs/apple_io.html
which is not very clear or detailed. The only hint from it was that pmu99 uses gpio which I've seen OS-es try to access but I don't know anything on that or what should be emulated for it.
Thank you very much for this information. A quick check of PearPC shows it also uses CUDA, so we can't copy any code for via-pmu.
Mark, is your complete qemu patch available somewhere? Then I could test 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
I'm thinking removing ADB support would fix this problem. Most real new world Macs have no ADB support.
This may be a good idea to match the hardware we are trying to emulate better but some OSes may depend on ADB for now. I've noticed Finnix had no keyboard in debug mode without ADB (which may be a bug in Finnix, I could not verify if it works on real hardware or has the same problem there).
Interesting. Did you use "-usb -device usb-keyboard" to enable usb support in QEMU when running Finnix?
On Thu, 12 Nov 2015, Programmingkid wrote:
On Nov 11, 2015, at 6:14 PM, BALATON Zoltan wrote:
better but some OSes may depend on ADB for now. I've noticed Finnix had no keyboard in debug mode without ADB (which may be a bug in Finnix, I could not verify if it works on real hardware or has the same problem there).
Interesting. Did you use "-usb -device usb-keyboard" to enable usb support in QEMU when running Finnix?
Yes (or more exactly I had a patch always adding usb keyboard instead of adb one to match hardware) and I think it worked once booted fully but with debug I could only type with ADB keyboard. Maybe it's only that ADB driver is compiled in the Finnix kernel while OHCI is not. I did not investigate.
Regards, BALATON Zoltan
On Thu, Nov 12, 2015 at 07:45:40PM +0100, BALATON Zoltan wrote:
Interesting. Did you use "-usb -device usb-keyboard" to enable usb support in QEMU when running Finnix?
Yes (or more exactly I had a patch always adding usb keyboard instead of adb one to match hardware)
Some mac99/pmu99 hardware has an ADB keyboard, fwiw (tibook, for example). The do have built-in USB; that, and being newworld, are not directly related things.
Segher
On Thu, 19 Nov 2015, Segher Boessenkool wrote:
Some mac99/pmu99 hardware has an ADB keyboard, fwiw (tibook, for example). The do have built-in USB; that, and being newworld, are not directly related things.
Maybe, but the PowerMac3,1 we are trying to emulate here does not have ADB AFAIK. Although qemu's mac99 is not a real machine now we should move to being closer to some existing hardware if we want OSes written for that hardware to run.
Regards, BALATON Zoltan
On Nov 20, 2015, at 8:39 AM, BALATON Zoltan wrote:
On Thu, 19 Nov 2015, Segher Boessenkool wrote:
Some mac99/pmu99 hardware has an ADB keyboard, fwiw (tibook, for example). The do have built-in USB; that, and being newworld, are not directly related things.
Maybe, but the PowerMac3,1 we are trying to emulate here does not have ADB AFAIK. Although qemu's mac99 is not a real machine now we should move to being closer to some existing hardware if we want OSes written for that hardware to run.
I use to have the same belief until Mark set me straight. We are only making an emulator of a new world Mac, not a simulator of a PowerMac3,1. This means we might be able to get away with not exactly mirroring a real Mac. The fact that Mac OS 9 can boot up at all does give me hope we are on the right path.
booting into MacOS9 with qemu to the Desktop is now possible, see:
http://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start=250
Some issues, remain, certain extensions crash on boot. On Nov 20, 2015 7:46 AM, "Programmingkid" programmingkidx@gmail.com wrote:
On Nov 20, 2015, at 8:39 AM, BALATON Zoltan wrote:
On Thu, 19 Nov 2015, Segher Boessenkool wrote:
Some mac99/pmu99 hardware has an ADB keyboard, fwiw (tibook, for
example).
The do have built-in USB; that, and being newworld, are not directly related things.
Maybe, but the PowerMac3,1 we are trying to emulate here does not have
ADB AFAIK. Although qemu's mac99 is not a real machine now we should move to being closer to some existing hardware if we want OSes written for that hardware to run.
I use to have the same belief until Mark set me straight. We are only making an emulator of a new world Mac, not a simulator of a PowerMac3,1. This means we might be able to get away with not exactly mirroring a real Mac. The fact that Mac OS 9 can boot up at all does give me hope we are on the right path. -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 11/11/15 21:32, Andreas Tobler wrote:
On 11.11.15 19:55, Programmingkid wrote:
On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
On 11/11/15 15:15, Programmingkid wrote:
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
I've done quite a bit of work on Cormac's tree (primarily to fix CUDA issues that broke OS X among other things) and posted it to the qemu-devel list at https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
The patchset posted works well for me here, and I suspect will fix the issues that you've been seeing. Note that you'll also need the separate OpenBIOS binary mentioned in the link above if you want to try booting OS 9 since one of the OpenBIOS patches hasn't been applied to trunk since it regresses other images.
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
Currently we know that mac99 is a hybrid of several machine types, but it just so happens that the OSs contain a large enough range of drivers for the image to work, as they appear to do here.
From my testing I don't see a problem with CUDA, and while it could be
that via-pmu may help things with OS 9, we need a specific patch to demonstrate this with instructions that can be independently reproduced.
I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. Unfortunately it still doesn't work ... but hope is still here ;)
If it helps, I've just noticed that the OS 9 patchset also fixes NetBSD PPC boot (looking at the CUDA driver I suspect it is likely the I2C parts) so I don't think FreeBSD will be too far off.
From what I've seen of reports from OpenBSD (e.g.
http://virtuallyfun.superglobalmegacorp.com/2015/07/19/gsoc-bringing-macos-9...), my first guess would be that a good starting point would be to check to PCI host bridge properties generated in OpenBIOS.
Mark, is your complete qemu patch available somewhere? Then I could test 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
I've just pushed the rebased version to https://github.com/mcayland/qemu/tree/ppc-os9-upstream for people interested to test further.
ATB,
Mark.
On Nov 11, 2015, at 6:05 PM, Mark Cave-Ayland wrote:
On 11/11/15 21:32, Andreas Tobler wrote:
On 11.11.15 19:55, Programmingkid wrote:
On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
On 11/11/15 15:15, Programmingkid wrote:
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
I've done quite a bit of work on Cormac's tree (primarily to fix CUDA issues that broke OS X among other things) and posted it to the qemu-devel list at https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
The patchset posted works well for me here, and I suspect will fix the issues that you've been seeing. Note that you'll also need the separate OpenBIOS binary mentioned in the link above if you want to try booting OS 9 since one of the OpenBIOS patches hasn't been applied to trunk since it regresses other images.
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
Currently we know that mac99 is a hybrid of several machine types, but it just so happens that the OSs contain a large enough range of drivers for the image to work, as they appear to do here.
Just checked this myself. Mac OS 9 does boot consistently to the "Mac OS 9" startup screen, so you do have a point. I'm surprised.
From my testing I don't see a problem with CUDA, and while it could be that via-pmu may help things with OS 9, we need a specific patch to demonstrate this with instructions that can be independently reproduced.
I will see what I can do.
I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. Unfortunately it still doesn't work ... but hope is still here ;)
If it helps, I've just noticed that the OS 9 patchset also fixes NetBSD PPC boot (looking at the CUDA driver I suspect it is likely the I2C parts) so I don't think FreeBSD will be too far off.
From what I've seen of reports from OpenBSD (e.g. http://virtuallyfun.superglobalmegacorp.com/2015/07/19/gsoc-bringing-macos-9...), my first guess would be that a good starting point would be to check to PCI host bridge properties generated in OpenBIOS.
Mark, is your complete qemu patch available somewhere? Then I could test 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
I've just pushed the rebased version to https://github.com/mcayland/qemu/tree/ppc-os9-upstream for people interested to test further.
I had just spent a lot of tedious effort copying and pasting all 13 patches from the link you sent me. Thank goodness for the git repo.
Just to note, your original set of patches did make a lot of progess. Only patch 8 had problems that required it to be applied by hand. I applied them to QEMU 2.4.1 on Mac OS 10.6.
Will start testing out the new version of patches.
On Nov 11, 2015, at 6:05 PM, Mark Cave-Ayland wrote:
On 11/11/15 21:32, Andreas Tobler wrote:
On 11.11.15 19:55, Programmingkid wrote:
On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
On 11/11/15 15:15, Programmingkid wrote:
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
I've done quite a bit of work on Cormac's tree (primarily to fix CUDA issues that broke OS X among other things) and posted it to the qemu-devel list at https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
The patchset posted works well for me here, and I suspect will fix the issues that you've been seeing. Note that you'll also need the separate OpenBIOS binary mentioned in the link above if you want to try booting OS 9 since one of the OpenBIOS patches hasn't been applied to trunk since it regresses other images.
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
Currently we know that mac99 is a hybrid of several machine types, but it just so happens that the OSs contain a large enough range of drivers for the image to work, as they appear to do here.
From my testing I don't see a problem with CUDA, and while it could be that via-pmu may help things with OS 9, we need a specific patch to demonstrate this with instructions that can be independently reproduced.
I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. Unfortunately it still doesn't work ... but hope is still here ;)
If it helps, I've just noticed that the OS 9 patchset also fixes NetBSD PPC boot (looking at the CUDA driver I suspect it is likely the I2C parts) so I don't think FreeBSD will be too far off.
From what I've seen of reports from OpenBSD (e.g. http://virtuallyfun.superglobalmegacorp.com/2015/07/19/gsoc-bringing-macos-9...), my first guess would be that a good starting point would be to check to PCI host bridge properties generated in OpenBIOS.
Mark, is your complete qemu patch available somewhere? Then I could test 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
I've just pushed the rebased version to https://github.com/mcayland/qemu/tree/ppc-os9-upstream for people interested to test further.
I think I cloned your repo correctly. When I did a 'git log', the first patch was this one:
commit 8aeea0670f83c93e6b9716598123fee98282610e Author: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk Date: Fri Oct 23 11:08:53 2015 +0100
cuda.c: add delay to setting of SR_INT bit
Are the version 2 of your patches suppose to be in this repo?
On 12/11/15 00:42, Programmingkid wrote:
On Nov 11, 2015, at 6:05 PM, Mark Cave-Ayland wrote:
On 11/11/15 21:32, Andreas Tobler wrote:
On 11.11.15 19:55, Programmingkid wrote:
On Nov 11, 2015, at 12:54 PM, Mark Cave-Ayland wrote:
On 11/11/15 15:15, Programmingkid wrote:
I built Cormac O'Brien's QEMU repo for Mac OS 9 and tried to boot my Mac OS 10.4 boot cd. Mac OS 10.4's kernel panics because of a CUDA problem. I did use the mac99 target. Here is the error message:
panic(cpu 0 caller 0x16E786CC): CUDA - TODO CHECK FOR TRANSACTION TYPE AND ERROR
This is the command I used: ./ppc-softmmu/qemu-system-ppc -boot d -cdrom ~/tiger.iso -prom-env boot-args=-v -usb -M mac99
I think there is still something wrong with CUDA. But we might not have to "fix" it. When we use the mac99 target, the PowerMac3,1 Macintosh system is what we are trying to emulate. My sources indicate that the PowerMac3,1 doesn't have a CUDA chip. This chip is used for ADB communications. Using it only on the BeigeG3 target makes sense.
My sources for the PowerMac3,1 system is this link: http://www.everymac.com/systems/apple/powermac_g4/specs/powermac_g4_350_agp....
and this device tree:
PowerMac G4 device tree
ff839ab8: /cpus ff839ce8: /PowerPC,G4@0 ff83a060: /l2-cache ff83ab58: /chosen ff83ace8: /memory@0 ff83af00: /openprom ff83b008: /client-services ff83c1a8: /rom@ff800000 ff83c330: /boot-rom@fff00000 ff83c4a8: /macos ff83c528: /options ff83c5a8: /aliases ff83cec8: /packages ff83cf30: /deblocker ff83d798: /disk-label ff83e198: /obp-tftp ff8439f0: /mac-parts ff844850: /mac-files ff847540: /hfs-plus-files ff84c1c8: /fat-files ff84def8: /iso-9660-files ff84eb00: /bootinfo-loader ff8507a0: /xcoff-loader ff8511b8: /pe-loader ff851b90: /elf-loader ff8531c0: /usb-hid-class ff8554d8: /usb-ms-class ff8576a8: /sbp2-disk ff858ac0: /ata-disk ff859cd8: /atapi-disk ff85b348: /bootpath-search ff861b68: /terminal-emulator ff861c00: /psuedo-hid ff861c88: /keyboard ff862308: /mouse ff862820: /multiboot ff86e7f0: /diagnostics ff86e858: /tools-node ff8704b8: /rtas ff8706b8: /nvram@fff04000 ff871180: /uni-n@f8000000 ff8713c8: /i2c@f8001000 ff871b10: /cereal ff8721c0: /pci@f0000000 ff898cd0: /uni-north-agp@b ff898f40: /ATY,Rage128Ps@10 ff873268: /pci@f2000000 ff8742d8: /pci-bridge@d ff876368: /mac-io@7 ff8773a0: /interrupt-controller@40000 ff877548: /gpio@50 ff877630: /extint-gpio1 ff8777c8: /programmer-switch ff877900: /escc-legacy@12000 ff877af8: /ch-a@12004 ff877c78: /ch-b@12000 ff877df8: /escc@13000 ff878000: /ch-a@13020 ff8789a8: /ch-b@13000 ff8792c0: /davbus@14000 ff879540: /sound ff879c40: /timer@15000 ff879da8: /via-pmu@16000 ff87ccf0: /rtc ff87d3e0: /power-mgt ff8bf378: /usb-power-mgt ff87d648: /i2c@18000 ff87ded8: /cereal ff87e5a0: /ata-4@1f000 ff880318: /disk ff8809e8: /ata-3@20000 ff882760: /disk ff882da8: /ata-3@21000 ff884b20: /disk ff8864c8: /ethernet@4 ff888690: /usb@8 ff88dd50: /usb@9 ff8be3f0: /hub@1 ff8be580: /keyboard@1 ff893410: /firewire@a ff8752e8: /pci@f4000000 ff8bb128: /ethernet@f
I've done quite a bit of work on Cormac's tree (primarily to fix CUDA issues that broke OS X among other things) and posted it to the qemu-devel list at https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05556.html.
The patchset posted works well for me here, and I suspect will fix the issues that you've been seeing. Note that you'll also need the separate OpenBIOS binary mentioned in the link above if you want to try booting OS 9 since one of the OpenBIOS patches hasn't been applied to trunk since it regresses other images.
It looks like you are saying you wish to keep the CUDA device. Mac OS 9 is most likely hard coded to expect via-pmu instead of via-cuda on the mac99 target. Moving on to via-pmu might make QEMU more compatible with Mac OS 9. I will still try your patches. Do you have a repo that I could just clone? It is a lot less error prone than patches.
Currently we know that mac99 is a hybrid of several machine types, but it just so happens that the OSs contain a large enough range of drivers for the image to work, as they appear to do here.
From my testing I don't see a problem with CUDA, and while it could be that via-pmu may help things with OS 9, we need a specific patch to demonstrate this with instructions that can be independently reproduced.
I'd like to keep the CUDA too, FreeBSD PowerPC (32-bit) relies on it. Unfortunately it still doesn't work ... but hope is still here ;)
If it helps, I've just noticed that the OS 9 patchset also fixes NetBSD PPC boot (looking at the CUDA driver I suspect it is likely the I2C parts) so I don't think FreeBSD will be too far off.
From what I've seen of reports from OpenBSD (e.g. http://virtuallyfun.superglobalmegacorp.com/2015/07/19/gsoc-bringing-macos-9...), my first guess would be that a good starting point would be to check to PCI host bridge properties generated in OpenBIOS.
Mark, is your complete qemu patch available somewhere? Then I could test 32-bit PowerPC on FreeBSD which still hangs on adb... up to now.
I've just pushed the rebased version to https://github.com/mcayland/qemu/tree/ppc-os9-upstream for people interested to test further.
I think I cloned your repo correctly. When I did a 'git log', the first patch was this one:
commit 8aeea0670f83c93e6b9716598123fee98282610e Author: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk Date: Fri Oct 23 11:08:53 2015 +0100
cuda.c: add delay to setting of SR_INT bitAre the version 2 of your patches suppose to be in this repo?
V2 was applied to master, so you should now be good with a standard QEMU checkout and the custom OpenBIOS binary included in the cover letter.
ATB,
Mark.
-
Alfonso Gamboa -
Andreas Tobler -
BALATON Zoltan -
Mark Cave-Ayland -
Programmingkid -
Segher Boessenkool