Author Topic: G5 qemu attempts.  (Read 14373 times)

Offline Daniel

  • Gold Member (200+ Posts)
  • *****
  • Posts: 269
  • Programmer, Hacker, Thinker
Re: G5 qemu attempts.
« Reply #150 on: October 20, 2018, 02:55:03 PM »
I recently read the 64-bit PowerPC spec. You are not supposed to use rfi on those systems. Use rfid instead. Any instruction that writes to a 64-bit register will have a "d" at the end of it.

Offline powermax

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 80
  • Hobbyist programmer
Re: G5 qemu attempts.
« Reply #151 on: October 20, 2018, 03:07:42 PM »
I recently read the 64-bit PowerPC spec. You are not supposed to use rfi on those systems. Use rfid instead. Any instruction that writes to a 64-bit register will have a "d" at the end of it.

Thank you. That explains the issue. We don't even need BAT to shoot ourselves to the dark side of the moon :o

Offline powermax

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 80
  • Hobbyist programmer
Re: G5 qemu attempts.
« Reply #152 on: October 20, 2018, 03:46:44 PM »
I recently read the 64-bit PowerPC spec. You are not supposed to use rfi on those systems. Use rfid instead. Any instruction that writes to a 64-bit register will have a "d" at the end of it.

Thank you. That explains the issue. We don't even need BAT to shoot ourselves to the dark side of the moon :o

I'm curious what happens when attempting to execute "rfi" on a real G5. Unfortunately, neither 970fx manual nor 970mp manual describe this case. My feeling is that "rfi" should be treated as an illegal instruction and trigger the program exception.

What QEMU does (jumping to 0x104) cannot be called a predicable behavior...

Offline Daniel

  • Gold Member (200+ Posts)
  • *****
  • Posts: 269
  • Programmer, Hacker, Thinker
Re: G5 qemu attempts.
« Reply #153 on: October 20, 2018, 05:17:13 PM »
I recently read the 64-bit PowerPC spec. You are not supposed to use rfi on those systems. Use rfid instead. Any instruction that writes to a 64-bit register will have a "d" at the end of it.

Thank you. That explains the issue. We don't even need BAT to shoot ourselves to the dark side of the moon :o

I'm curious what happens when attempting to execute "rfi" on a real G5. Unfortunately, neither 970fx manual nor 970mp manual describe this case. My feeling is that "rfi" should be treated as an illegal instruction and trigger the program exception.

What QEMU does (jumping to 0x104) cannot be called a predicable behavior...
The PowerPC 64-bit OEA doesn't even mention rfi at all. It only talks about rfid. I guess changing this is yet another thing we have to do to get the G5 working.

Offline Naiw

  • Veteran Member (100+ Posts)
  • ****
  • Posts: 116
  • new to the forums
Re: G5 qemu attempts.
« Reply #154 on: October 21, 2018, 02:21:00 AM »
Unfortunately, that RTASFairyDust function in the Mac OS ROM's exception table trys to clear the BATs before jumping into the NK. Even if the RelocationEngine finishes correctly, the loaded Mac OS ROM will have crashed before a single instruction in the NK is executed.

Is that going to be a problem on the 970, ELN stated that it does have BAT registers?
Neither have BATs.

Neither the 970, 970fx, nor the 970mp have BAT?

Correct, none of the "G5s" have BAT registers, nor do they follow the PowerPC specification (the absence of pseudo little endian mode is the most well known divergation)

It doesn't matter what data sheets or general PowerPC docs say, the 970 and it's siblings are not PPC compliant outside of UISA.

Offline powermax

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 80
  • Hobbyist programmer
Re: G5 qemu attempts.
« Reply #155 on: October 21, 2018, 03:57:48 AM »
Correct, none of the "G5s" have BAT registers, nor do they follow the PowerPC specification (the absence of pseudo little endian mode is the most well known divergation)

It doesn't matter what data sheets or general PowerPC docs say, the 970 and it's siblings are not PPC compliant outside of UISA.

Well, this implies that all supervisor-level code must be redesigned for G5 and provided as switchable alternative to the existing PowerPC32 code in order to run on newer hardware. Fortunately, the amount of supervisor-level code in MacOS9 isn't large compared to the XNU kernel. The only component allowed to be executed as supervisor is the Nanokernel. All others run either under emulation or in user mode (including the emulator itself)...

Offline Naiw

  • Veteran Member (100+ Posts)
  • ****
  • Posts: 116
  • new to the forums
Re: G5 qemu attempts.
« Reply #156 on: October 21, 2018, 06:43:03 AM »
Correct, none of the "G5s" have BAT registers, nor do they follow the PowerPC specification (the absence of pseudo little endian mode is the most well known divergation)

It doesn't matter what data sheets or general PowerPC docs say, the 970 and it's siblings are not PPC compliant outside of UISA.

Well, this implies that all supervisor-level code must be redesigned for G5 and provided as switchable alternative to the existing PowerPC32 code in order to run on newer hardware. Fortunately, the amount of supervisor-level code in MacOS9 isn't large compared to the XNU kernel. The only component allowed to be executed as supervisor is the Nanokernel. All others run either under emulation or in user mode (including the emulator itself)...

Yes. And add to that basically no peripheral would work on the G5 even if the nanokernel is fixed.

Mac OS certainly don't know how to deal with PCI-X or PCIe either so it's a long road ahead if going that path.

I think it would be more interesting doing something similar to Classic but with Linux and a nanokernel shim (but at the same time MacOnLinux is there already)

Offline ELN

  • Gold Member (200+ Posts)
  • *****
  • Posts: 291
  • new to the forums
Re: G5 qemu attempts.
« Reply #157 on: October 21, 2018, 07:46:48 AM »
I stand corrected about the 970 having BATs. For some reason I though that Amit Singh had made that claim in Mac OS X Internals. Oops!

Offline powermax

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 80
  • Hobbyist programmer
Re: G5 qemu attempts.
« Reply #158 on: October 21, 2018, 09:41:45 AM »
I think it would be more interesting doing something similar to Classic but with Linux and a nanokernel shim (but at the same time MacOnLinux is there already)

Classic have had a lot of performance and compatibility related issues. I remember not being able to use DAW software under Classic at all. I doubt we could do it better than Apple...

Offline darthnVader

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 520
  • New Member
Re: G5 qemu attempts.
« Reply #159 on: October 21, 2018, 09:46:18 AM »
I stand corrected about the 970 having BATs. For some reason I though that Amit Singh had made that claim in Mac OS X Internals. Oops!

No worries, we all have selective memory sometimes ;D

If we want OS 9 to run on the G5 CPU we're going to have to find a way to patch 'rfi', not a small task.

Unfortunately outside my wheel house, but at least we have some understanding of what we need to do. 'rfi'>BAT patches. That's further along than we were when this thread started. I know I learned a lot, and hopefully we can come up with some ideas on how to move forward with this, maybe on day we'll get over the hump, as it were.

Thanks for everyone's input, very interesting stuff.

Offline Naiw

  • Veteran Member (100+ Posts)
  • ****
  • Posts: 116
  • new to the forums
Re: G5 qemu attempts.
« Reply #160 on: October 21, 2018, 12:37:22 PM »
I think it would be more interesting doing something similar to Classic but with Linux and a nanokernel shim (but at the same time MacOnLinux is there already)

Classic have had a lot of performance and compatibility related issues. I remember not being able to use DAW software under Classic at all. I doubt we could do it better than Apple...

I would claim that the performance issues related to Classic was more to do with the fact Classic was a second class citizen in the Mac OS X installation- if OS X prioritized the Classic process it probably wouldn't been that bad. (as well as the rootless mode, window doublebuffering hacks etc that basically only made it usable for word processors and a like applications that basically only used Toolbox (Quickdraw/Quicktime etc especially) calls for everything, a lot of applications on OS 9 however had their own implementations of blitting routines etc and those broke on Classic because of the stupid double buffering hack Apple used- which of course was necessary to allow windows to overlap without artifacts when run in a rootless window.
As for audio etc yes, the lack of hardware access of course caused issues there- but that's something that could have been solved if Apple wanted to (QEMU, VMWare etc supported it for ages) PCI passthrough etc is not a technical impossibility even without an IOMMU on the PCI buss, it's just not secure- but anyone who cares about security wouldn't run Mac OS 9 to start with.

Compatibility would be tricky regardless of solution, especially on everything but the first G5 (PCI-X; PCI-X can run in PCI compatibility mode as far as I know- so I think it's theoretically plausible to have it work with OS 9 with some efforts... but then again I never really looked into the specification at detail so it's mostly a guess), the PCIe on the other hand that the majority of the G5s used are completely different beast however and even if someone magically would manage to get PCIe working, it's not compatible with PCI so no PCI card drivers etc would work (which means no ASIO or similar).

While the alternative would be to leverage the device layer support on another kernel such as Linux would give a lot of this "for free", In fact MacOnLinux already has higher compatibility than Classic ever had- unfortunately MacOnLinux was never ported to the G5 (and I believe the original implementation is extremely dated so it's unlikely it would even work with recent linux kernels), I know there was efforts porting MacOnLinux to use KVM instead of it's own hypervisor implementation- but I guess that essentially would leave us up to the point we are right now- with QEMU and KVM, ie. The bootstrap/nanokernel is unable to boot due to supervisor differences on the G5.

Anyway it's just my two cents, getting the kernel started and Mac OS to boot at all is of course beneficial in all scenarios, regardless of what path one may take after that.

Offline ELN

  • Gold Member (200+ Posts)
  • *****
  • Posts: 291
  • new to the forums
Re: G5 qemu attempts.
« Reply #161 on: October 21, 2018, 03:28:32 PM »
FWIW, if someone can get me a Trampoline that just lumps over the line to start the NanoKernel, then I can go nuts patching the NanoKernel. Progress might be swift. Excellent work all and especially darth! (Maybe this will help if you ever want to go back to graphics drivers, or maybe the kernel?)

Offline ELN

  • Gold Member (200+ Posts)
  • *****
  • Posts: 291
  • new to the forums
Re: G5 qemu attempts.
« Reply #162 on: October 22, 2018, 04:05:08 AM »
I suppose Id better get back onto the legacy NanoKernel reversal!

Offline Daniel

  • Gold Member (200+ Posts)
  • *****
  • Posts: 269
  • Programmer, Hacker, Thinker
Re: G5 qemu attempts.
« Reply #163 on: October 22, 2018, 04:12:50 AM »
It's a pity we can't work on all of our thousand projects at once.

Offline powermax

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 80
  • Hobbyist programmer
Re: G5 qemu attempts.
« Reply #164 on: October 22, 2018, 07:50:07 AM »
I think it would be more interesting doing something similar to Classic but with Linux and a nanokernel shim (but at the same time MacOnLinux is there already)

Classic have had a lot of performance and compatibility related issues. I remember not being able to use DAW software under Classic at all. I doubt we could do it better than Apple...

I would claim that the performance issues related to Classic was more to do with the fact Classic was a second class citizen in the Mac OS X installation- if OS X prioritized the Classic process it probably wouldn't been that bad. (as well as the rootless mode, window doublebuffering hacks etc that basically only made it usable for word processors and a like applications that basically only used Toolbox (Quickdraw/Quicktime etc especially) calls for everything, a lot of applications on OS 9 however had their own implementations of blitting routines etc and those broke on Classic because of the stupid double buffering hack Apple used- which of course was necessary to allow windows to overlap without artifacts when run in a rootless window.
As for audio etc yes, the lack of hardware access of course caused issues there- but that's something that could have been solved if Apple wanted to (QEMU, VMWare etc supported it for ages) PCI passthrough etc is not a technical impossibility even without an IOMMU on the PCI buss, it's just not secure- but anyone who cares about security wouldn't run Mac OS 9 to start with.

Compatibility would be tricky regardless of solution, especially on everything but the first G5 (PCI-X; PCI-X can run in PCI compatibility mode as far as I know- so I think it's theoretically plausible to have it work with OS 9 with some efforts... but then again I never really looked into the specification at detail so it's mostly a guess), the PCIe on the other hand that the majority of the G5s used are completely different beast however and even if someone magically would manage to get PCIe working, it's not compatible with PCI so no PCI card drivers etc would work (which means no ASIO or similar).

While the alternative would be to leverage the device layer support on another kernel such as Linux would give a lot of this "for free", In fact MacOnLinux already has higher compatibility than Classic ever had- unfortunately MacOnLinux was never ported to the G5 (and I believe the original implementation is extremely dated so it's unlikely it would even work with recent linux kernels), I know there was efforts porting MacOnLinux to use KVM instead of it's own hypervisor implementation- but I guess that essentially would leave us up to the point we are right now- with QEMU and KVM, ie. The bootstrap/nanokernel is unable to boot due to supervisor differences on the G5.

Anyway it's just my two cents, getting the kernel started and Mac OS to boot at all is of course beneficial in all scenarios, regardless of what path one may take after that.

Thank you for this exhaustive answer. At first glance, I don't see any major software-side roadblock in updating MOL for G5 except the time constraint. Someone willing to undertake this task, will have to understand MOL's code first and that requires a lot of time.

To my knowledge, PCI cards cannot be plugged into PCIe slots. That means we cannot use pre-G5 hardware with G5 machines unless I missing something (?)

IIUC, we had a possibility to build a transition layer between legacy software and newer hardware on top of MOL, right?

I think MOL deserves a separate thread. What do you think about moving the MOL-related discussion to elsewhere? What's the right place for that? Software development?

Offline refinery

  • Gold Member (200+ Posts)
  • *****
  • Posts: 215
Re: G5 qemu attempts.
« Reply #165 on: October 25, 2018, 03:09:18 PM »

To my knowledge, PCI cards cannot be plugged into PCIe slots. That means we cannot use pre-G5 hardware with G5 machines unless I missing something (?)


only the final generation of G5s used PCIe (970MP series), the others were all PCI-X.
There are actually hardware adapters which allow you to plug one into the other or vice versa, but ive no idea how well they would work on a PPC machine.
G4/MDD 1.42 (9), G4/GB 500DP (X), Beige G3 400 (upgraded) (9), PBG4Ti 1Ghz (X), PBG3WS 300 (9)

got my mind on my scsi and my scsi on my mind

Offline ELN

  • Gold Member (200+ Posts)
  • *****
  • Posts: 291
  • new to the forums
Re: G5 qemu attempts.
« Reply #166 on: October 25, 2018, 04:17:27 PM »
OS 9s communication with the PCI bus controller is well abstracted using a pluggable module called the PCICyclesLib, which I think actually exposes part of the interface that belongs to the Expansion Bus Manager. So write a new PCICyclesLib to wang the ?K2 and we should be good.

Offline darthnVader

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 520
  • New Member
Re: G5 qemu attempts.
« Reply #167 on: October 25, 2018, 06:46:08 PM »

To my knowledge, PCI cards cannot be plugged into PCIe slots. That means we cannot use pre-G5 hardware with G5 machines unless I missing something (?)


only the final generation of G5s used PCIe (970MP series), the others were all PCI-X.
There are actually hardware adapters which allow you to plug one into the other or vice versa, but ive no idea how well they would work on a PPC machine.

I have a PCI-E to PCI adepter, they are pretty transparent to the host, should work in just about any system.

We also used GPU's that had a PCI-E to AGP bridge, and they are transparent  to the host.

Likely OS 9 would just treat PCI-E slots as PCI. I pasted a PCI Firewire card in the PCI-E adepter to Qemu-PPC and it worked fine in 9.2.2 and 10.4 with my Firewire devices.

Offline darthnVader

  • Platinum Member (500+ Posts)
  • *****
  • Posts: 520
  • New Member
Re: G5 qemu attempts.
« Reply #168 on: June 01, 2019, 04:54:00 AM »
I got some new hardware( G5 Quad ), so I wanted to get back to this.......

Have a look at this from KVM-pr in Qemu.

Code: [Select]
qemu-system-ppc' -enable-kvm  -hda '/media/jam/d9d5c74c-a218-45c6-9d7f-8d8274228955/Tiger.img' -cpu g4 -M mac99 -m  1536  -prom-env "aapl,debug=3013FFF" -cdrom ~/OS9.iso -prom-env 'auto-boot?=false'
Am I getting the NanoKernel?

Offline ELN

  • Gold Member (200+ Posts)
  • *****
  • Posts: 291
  • new to the forums
Re: G5 qemu attempts.
« Reply #169 on: June 01, 2019, 05:27:08 AM »
Yep. Nice!

Offline Jubadub

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 90
  • New Member
Re: G5 qemu attempts.
« Reply #170 on: September 04, 2019, 08:03:23 AM »
It's amazing to see the progress you guys made with G5, QEMU and Mac OS 9. That stuff about PCI/PCIe adapters + device detection had me blown away, as well. I wouldn't have thought QEMU OS 9 would have seen the FireWire devices just like that.

Also grats on acquiring the G5 Quad, darthnvader, it's one of the loveliest machines I have ever used. But that machine and all the other G5s desperately need some native OS 9 love! I see myself using the Mac mini G4 a lot more than my Quad simply because it has OS 9. This needs to change... And you guys have made some really nice discoveries and progress to that end.

Offline ELN

  • Gold Member (200+ Posts)
  • *****
  • Posts: 291
  • new to the forums
Re: G5 qemu attempts.
« Reply #171 on: September 07, 2019, 05:12:00 PM »
Just the encouragement we need! ;)

Offline teroyk

  • Enthusiast Member (25+ Posts)
  • ***
  • Posts: 96
  • new to the forums
Re: G5 qemu attempts.
« Reply #172 on: September 09, 2019, 02:19:21 AM »
Good work! Please document well what your findings right now, it might open whole new world for G5 hardware. Although I try to not get involved in before January 2021  ;)
I bought my first new Mac when OS X 10.1 released. And I bought that Mac because it had Mac OS 9 too. And I bought my first 68k Mac when Apple stopped PPC Macs.