PowerMac G5 running Linux with a PowerPC virtual machine

[DearthnVader]

mind going a bit more in depth what you did there?

in regards to hanging at BootX what CPU are you running exactly?

OpenBios needs this code added to /arch/ppc/qemu/init.c

{
        .iu_version = 0x80030000,
        .name = "PowerPC,G4",
        .icache_size = 0x8000,
        .dcache_size = 0x8000,
        .icache_sets = 0x80,
        .dcache_sets = 0x80,
        .icache_block_size = 0x20,
        .dcache_block_size = 0x20,
        .tlb_sets = 0x40,
        .tlb_size = 0x80,
        .initfn = cpu_g4_init,
    },

That adds support for all 7447a cpus to Openbios.

Then in qemu source edit /qemu/target/ppc/cpu-models.c and add the code:

POWERPC_DEF("7457a_v1.5",CPU_POWERPC_74x7A_v15,                  7455,
"PowerPC 7457A v1.5 (G4)")

Then edit the /qemu/target/ppc/cpu-models.h adding:

CPU_POWERPC_74x7A_v15 = 0x80030105, /* aka D: 1.5 */

That's my cpu 7447a v1.5 ( PVR 80030105 ).

 

[LightBulbFun]

OpenBios needs this code added to /arch/ppc/qemu/init.c

{
        .iu_version = 0x80030000,
        .name = "PowerPC,G4",
        .icache_size = 0x8000,
        .dcache_size = 0x8000,
        .icache_sets = 0x80,
        .dcache_sets = 0x80,
        .icache_block_size = 0x20,
        .dcache_block_size = 0x20,
        .tlb_sets = 0x40,
        .tlb_size = 0x80,
        .initfn = cpu_g4_init,
    },

That adds support for all 7447a cpus to Openbios.

Then in qemu source edit /qemu/target/ppc/cpu-models.c and add the code:

POWERPC_DEF("7457a_v1.5",CPU_POWERPC_74x7A_v15,                  7455,
"PowerPC 7457A v1.5 (G4)")

Then edit the /qemu/target/ppc/cpu-models.h adding:

CPU_POWERPC_74x7A_v15 = 0x80030105, /* aka D: 1.5 */

That's my cpu 7447a v1.5 ( PVR 80030105 ).

very cool this is very nice info to have Ill have to have a play with it (I have a few CPUs in mind i want to try LOL)

thank you

in regards as to why OS X wont boot, does it boot when you use my 604 patched kernel? (because QEMU doing 7448 emulation wont boot OS X without it and im wondering if this is the case here too, although if my kernel enables OS X to boot on the 7447B in QEMU it would be very interesting as the 7447B is officially supported by OS X)

 

[DearthnVader]

604 patched kernel

What is that?

I'm assuming you patched mach_kernel to support the 604, Tiger supports the 7447a v1.5, my PowerBook6,8 shipped with 10.3.7, but 10.3.0 CD won't boot on it, hangs at BooX when doing native boot.

 

[LightBulbFun]

What is that?

I'm assuming you patched mach_kernel to support the 604, Tiger supports the 7447a v1.5, my PowerBook6,8 shipped with 10.3.7, but 10.3.0 CD won't boot on it, hangs at BooX when doing native boot.

oh your using 10.3.0? yeah that wont work for a 7447B (note the CPU in your PowerBook is a 7447B not a 7447A) 10.3.0 only supports up to the PPC970/7447 otherwise the kernel sees an unknown CPU and aborts. (this abort on unknown CPU was introduced with the G5 build of 10.2.8 IIRC) and is why 10.2.8 G5 and up wont boot on a 604 for example

I recommend installing using -cpu 750 then once updated to 10.3.9 using -cpu host if you wish (I recommend running tiger over panther however)


https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/ this is the Kernel I am talking about

 

[DearthnVader]

oh your using 10.3.0? yeah that wont work for a 7447B (note the CPU in your PowerBook is a 7447B not a 7447A) 10.3.0 only supports up to the PPC970/7447 otherwise the kernel sees an unknown CPU and aborts. (this abort on unknown CPU was introduced with the G5 build of 10.2.8 IIRC) and is why 10.2.8 G5 and up wont boot on a 604 for example

I recommend installing using -cpu 750 then once updated to 10.3.9 using -cpu host if you wish (I recommend running tiger over panther however)


https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/ this is the Kernel I am talking about

No I was trying to install Tiger in qemu, but the result is going to be the same no matter what, support for the 7447 in not complete when it comes to BootX.

Likely some magic that got applied to Qemu and the way it deals with tbxi recourses durning the GSOC a few years back. I'm thinking it only got applied to know CPUs like the 604,7400, and 7410, but then I've been wrong before.

I'll try and track it down in the code, as I have time. I've got a few more old PPC Macs coming, so I'll push a few patches to OB/Qemu-PPC. The patches for the 7447a are on the respective lists. Tho I may need to amend them if my cpu is a 7447b, tho /proc/cpuinfo reports 7447a.

 

[LightBulbFun]

No I was trying to install Tiger in qemu, but the result is going to be the same no matter what, support for the 7447 in not complete when it comes to BootX.

Likely some magic that got applied to Qemu and the way it deals with tbxi recourses durning the GSOC a few years back. I'm thinking it only got applied to know CPUs like the 604,7400, and 7410, but then I've been wrong before.

I'll try and track it down in the code, as I have time. I've got a few more old PPC Macs coming, so I'll push a few patches to OB/Qemu-PPC. The patches for the 7447a are on the respective lists. Tho I may need to amend them if my cpu is a 7447b, tho /proc/cpuinfo reports 7447a.

I doubt its the GSOC stuff at play, as QEMU has been able to boot the Darwin kernel for a very long time now (even if back in the day none of the other emulated hardware worked right LOL)

if tiger is having issues on the 7447B then I recommend trying my kernel out if it still wont boot on that then my best guess QEMU is failing to emulate something OS X requires to boot on the 7447A/B I also recommend trying it without KVM to see if KVM is the issue or not (For example OS 9 wont boot when QEMU is using KVM in my experience)

(the 7447A/7447B show up the same in software, the only way to tell them apart is physically look at the markings on the chip)

 

[DearthnVader]

I doubt its the GSOC stuff at play, as QEMU has been able to boot the Darwin kernel for a very long time now (even if back in the day none of the other emulated hardware worked right LOL)

if tiger is having issues on the 7447B then I recommend trying my kernel out if it still wont boot on that then my best guess QEMU is failing to emulate something OS X requires to boot on the 7447A/B I also recommend trying it without KVM to see if KVM is the issue or not (For example OS 9 wont boot when QEMU is using KVM in my experience)

(the 7447A/7447B show up the same in software, the only way to tell them apart is physically look at the markings on the chip)

Thanks, if I can get my Tiger install to be stable, keep having issues with the install going well, and the system boots and runs very good the first time I reboot it, but then I get boot hangs before the window server starts. Cant's seem to track down the reason. I'll test your kernel and see it that resolves the issue, tho if it does, I'll be asking for a diff agienst the Xnu source, so I can track down the cause of the boot hang.

As the idea is to build an emulator that supports the standard install, as much as possible. At least it is for me, once everything works as it should, I'd like to go back and start adding support for more modern things to the PPC's Mac OS's.

Thing like usb2/3 support to OS 9, a Webkit browser for OS 9, and OS X PPC, but really I like to do graphics card related stuff, I've been working on Voodoo2 register level emulation for OS 9 in qemu-ppc, when I'm done with that, I'll take what I learn and try a Rage 128, then maybe a GeForce 4 Ti.

It's really slow going, as I'm just a hacker, not a programer, but I'm retired and have nothing else to do anyway.

 

[AphoticD]

Thanks, if I can get my Tiger install to be stable, keep having issues with the install going well, and the system boots and runs very good the first time I reboot it, but then I get boot hangs before the window server starts. Cant's seem to track down the reason. I'll test your kernel and see it that resolves the issue, tho if it does, I'll be asking for a diff agienst the Xnu source, so I can track down the cause of the boot hang.

As the idea is to build an emulator that supports the standard install, as much as possible. At least it is for me, once everything works as it should, I'd like to go back and start adding support for more modern things to the PPC's Mac OS's.

Thing like usb2/3 support to OS 9, a Webkit browser for OS 9, and OS X PPC, but really I like to do graphics card related stuff, I've been working on Voodoo2 register level emulation for OS 9 in qemu-ppc, when I'm done with that, I'll take what I learn and try a Rage 128, then maybe a GeForce 4 Ti.

It's really slow going, as I'm just a hacker, not a programer, but I'm retired and have nothing else to do anyway.

Very impressive work @DearthnVader .

I’m looking forward to the direction of the ppc multi-tcg accelerator. From what I understand, the multi-tcg could leverage SMP on the host to, in theory, use 2, 4, 8x, etc host CPUs to turbo boost the single CPU support in the mac99 machine, is that right?

On the flip side of the coin, it would be great to see SMP support added to the mac99 machine. I get great results from the pseries machine emulation with KVM on ppc64, with SMP cpus=2. Debian and Fedora VMs feel like they run at native speed (Minus graphics acceleration). As it currently stands, on my G5, Tiger in QEMU mac99 KVM is still lagging massively behind the G5’s single CPU native speed, especially when compared to the speeds achieved in MOL/KVM.

MOL is very usable for speed in Tiger, but is crash happy and unreliable for anything mission critical.

I love the idea of having the G5 running Linux/ppc64 with all of it’s up to date services and underpinnings and then running Tiger (or Leopard) on top of it for working with Xcode 2 (or 3) for PowerPC Mac app development. I’m sure the few Mac oriented owners of the POWER8 or 9 machines would be interested in this too.

Curiously, would there be any way of forwarding OpenGL calls directly to the host system for hardware graphics acceleration? I have no idea how Qemu interfaces with hardware, but I can imagine there would be a need for some kind of abstraction layer, in the same way that the Apple devs enabled 3D acceleration in Classic apps.

 

[XaPHER]

@DearthnVader What's your powerbook's processor identity according to open firmware ( by that of course I mean typing something like dev /cpus/PowerPC,G4@0 .properties and looking at the 32-bit value of processor version ) ? As this is picked from the cpu's SPRs the value shouldn't lie. 7447A or 7447B doesn't matter. As long as the leftmost 16 bits say 0x8003, it is a 7447, has the same microarchitecure as any 7447, same cache functionnality, size and ratio as any 7447, and therefore is a 7447. Don't worry about a suffix.

 

[LightBulbFun]

@DearthnVader What's your powerbook's processor identity according to open firmware ( by that of course I mean typing something like dev /cpus/PowerPC,G4@0 .properties and looking at the 32-bit value of processor version ) ? As this is picked from the cpu's SPRs the value shouldn't lie. 7447A or 7447B doesn't matter. As long as the leftmost 16 bits say 0x8003, it is a 7447, has the same microarchitecure as any 7447, same cache functionnality, size and ratio as any 7447, and therefore is a 7447. Don't worry about a suffix.

the 7447 is 0x8002

the 7447A/B is 0x8003

suffixes can matter quite a bit. they are diffrent CPUs

also its not very hard to get OpenFirmware to lie about the CPU inside the machine, look at all the Firmware patches that enabled 7447/7448 CPUs to work in PowerMac G4s more often then not they masked the CPUs actual PVR

 

[XaPHER]

Then use whatever utility you want ( reggie from CHUD is an example) if you suspect the bootrom of whatever machine to patch the device tree value after fetching it from the PVR. Oh, and PVR doesn't need supervisor privileges to be read AFAIK.

Feel free to provide sources to prove whatever speculation about PVRs between sub-types of 7447 there may be. It would also be nice to see a datasheet from what remains of freescale that explicitly mentions a 7447B. I've been looking for this. No need to be stiff.

Edit: After verification mfspr rX,287 is a priviledged instruction. My bad.

 

[LightBulbFun]

Then use whatever utility you want ( reggie from CHUD is an example) if you suspect the bootrom of whatever machine to patch the device tree value after fetching it from the PVR. Oh, and PVR doesn't need supervisor privileges to be read AFAIK.

Feel free to provide sources to prove whatever speculation about PVRs between sub-types of 7447 there may be. It would also be nice to see a datasheet from what remains of freescale that explicitly mentions a 7447B. I've been looking for this. No need to be stiff.

Edit: After verification mfspr rX,287 is a priviledged instruction. My bad.

theres plenty of documentation out there that tell you what the PVR for a give PPC CPU should be.

and like I have said the 7447/7457 is a diffrent CPU then the 7447A/B

as per the data sheet for the 7447A for example, the 7447A/B supports DFS where as the 7447 do not

and here is an example of an NXP document that mentions the 7447B

https://www.nxp.com/docs/en/reliability-and-quality-information/MC7447AQUAL.pdf

you tell me not to be so stiff, but when you show up and try to almost walk over what I say with information that is plain wrong im not going to take to that very lightly... "Any 7447 is a 7447 dont worry about a suffix"

 

[Gamer9430]

No need to be stiff.

Whoa there partner, you must be new 'round these parts... @LightBulbFun is the breathing form of PPC Wikipedia. He has spent countless hours and days studying every minute detail there is to know about PPC CPUs, chipsets, revisions, versions, where and what they were used in, who made said chips, etc. You just happen to stumble in here, make outlandish claims, and rebuke @LightBulbFun's knowledge. Then you accuse him of being blunt, when you came in here and spewed out misinformation with no sources, then call upon LBF to gather as much information as possible to provide to you to prove YOU wrong, as if you are as all knowing as he is. You can ask any member of this subform who is the most knowledgeable regarding PPC CPUs and such, and it would unanimously be @LightBulbFun. So please, do be careful the next time you come in here and challenge someone as knowledgeable as LBF, 'cause you will catch quite the beating from them...

 

[128keaton]

Whoa there partner, you must be new 'round these parts... @LightBulbFun is the breathing form of PPC Wikipedia. He has spent countless hours and days studying every minute detail there is to know about PPC CPUs, chipsets, revisions, versions, where and what they were used in, who made said chips, etc. You just happen to stumble in here, make outlandish claims, and rebuke @LightBulbFun's knowledge. Then you accuse him of being blunt, when you came in here and spewed out misinformation with no sources, then call upon LBF to gather as much information as possible to provide to you to prove YOU wrong, as if you are as all knowing as he is. You can ask any member of this subform who is the most knowledgeable regarding PPC CPUs and such, and it would unanimously be @LightBulbFun. So please, do be careful the next time you come in here and challenge someone as knowledgeable as LBF, 'cause you will catch quite the beating from them...

Eh I'm barely sure it dinged his ego. Sometimes we all need a bit of a challenge to prove one's self.

New guy may actually BE smart and able to overcome his pride to admit defeat.

Quite a foe!

 

[Gamer9430]

Eh I'm barely sure it dinged his ego. Sometimes we all need a bit of a challenge to prove one's self.

New guy may actually BE smart and able to overcome his pride to admit defeat.

Quite a foe!

I shall abstain from further inflation of LBF's ego, this is his fight after all. Also, given the string of people we've had come in here lately who will argue false information as fact until the cows come home, I'd doubt this guy will either...

 

[XaPHER]

@LightBulbFun Else than the fact every info I brought was plain wrong, the main point I had is still effective: a 7447 remains a 7447 regardless of the complete part number; You quote "Any 7447 is a 7447 dont worry about a suffix" the same way someone would quote someone else for disregarding gender identities. I just meant it like "Suffixes do not alter the unit's architecture and should therefore be a working drop-in replacement from a __software__ viewpoint", nothing more. It was intended as a contrast only.

@Gamer9430 In addition to what I just said, everyone is free contribute to a wiki.

I also keep myself a reserve that skepticism is something very usual on a forum.

Well, I think it's time for not logging in here for another five years as it doesn't really suit me. Thanks for the 7447 parts overview though.

 

[Gamer9430]

I guess I'll be making the check out to a Mr. Keaton, 128? He admitted that his information was invalid, much to my surprise...

 

[LightBulbFun]

@LightBulbFun Else than the fact every info I brought was plain wrong, the main point I had is still effective: a 7447 remains a 7447 regardless of the complete part number; You quote "Any 7447 is a 7447 dont worry about a suffix" the same way someone would quote someone else for disregarding gender identities. I just meant it like "Suffixes do not alter the unit's architecture and should therefore be a working drop-in replacement from a __software__ viewpoint", nothing more. It was intended as a contrast only.

@Gamer9430 In addition to what I just said, everyone is free contribute to a wiki.

I also keep myself a reserve that skepticism is something very usual on a forum.

Well, I think it's time for not logging in here for another five years as it doesn't really suit me. Thanks for the 7447 parts overview though.

one could argue very much so that the 7447A is diffrent from a software point of view since the 7447A has Dynamic frequency stepping as well as a thermal diode for temperature monitoring, im not sure what OS X for example might do if it sees a 7447A and tries to activate DFS when its not actually there (for example if you tried to emulate a 7447A and emulation lacked all the 7447A specific stuff)

(on a side note, IIRC certain PLL multiplier configs would actually disable DFS, it was important in overclocking PowerBooks so your battery life would not go to the dogs LOL)

im happy to discuss technical stuff but as i said in my post above I dont like how you just tried to dismiss what I said.

lets end this on a lighter note

heres some Docs you might find interesting (NXP still actually hosts a surprising number of PowerPC CPU PDFs, its well worth reading through all of them if your into that sort of stuff)

https://www.nxp.com/docs/en/data-sheet/MPC7447AEC.pdf the main data sheet for the 7447A

and heres the the main Data sheet for the 7457 and 7447

https://www.nxp.com/docs/en/data-sheet/MPC7457EC.pdf

 

[gavinstubbs09]

That's like saying a 970FX is the same as a 970MP, yes both called the "G5" but are completely different revisions. "A 970 is a 970" nada

 

[XaPHER]

That's like saying a 970FX is the same as a 970MP, yes both called the "G5" but are completely different revisions. "A 970 is a 970" nada

Your comparison is not on the same scale; I compared divisions of a same chip within an architecture minor redesign [the 7447] while you're stating two different chips minor redesigns (same core architecture, but two cores per die w/ .5µm die shrink, doubles L2 cache). It's more like comparing a 7445 and a 7447.

Anyway, it is getting meaningless to argue about details that don't change in facts however the way we perceive it just like above. Let's not start a spiritual war, please. Let's stop this here. This is tiring. I'm unsubscribing this thread.

 

[DearthnVader]

More and more things are becoming crippled on the 32-bit powerpc kernel. Slice of life I have a gentoo installation on my dual MDD. Definitely keeping SMP support for obvious reasons. However, SMP support since linux-3.4 completely breaks DRI with the radeon driver, so my kernel is compiled with a framebuffer and no hardware graphics acceleration. Big advantage with this is it takes about 25 minutes to compile.

I could compile a non-smp kernel with DRI for my 9600, but it would also necessite to recompile all my system libraries to get hardware acceleration, so no. Not like anything is as slow as debian without proper graphics acceleration as it is right now.

I built the latest stable kernel( 4.15.1 ) and I don't have any trouble with direct rendering on the Radeon 9000.

I just wonder why SMP can't be used with KVM?

 

[XaPHER]

I built the latest stable kernel( 4.15.1 ) and I don't have any trouble with direct rendering on the Radeon 9000.

I just wonder why SMP can't be used with KVM?

Unsure what to say. No matter what I tried to get working video past 3.4 DRI never has been stable for me, with no differences between a 9600 and a 9000. Switching to SMP with my later machines worsened it. I can't even reach a TTY login in the latter case because my screen goes black before booting is finished. Kernel args don't help.

At the same time I'm lazy to investigate further after migrating from debian-based distros to something more workable and customizable like gentoo. This isn't really a concern anymore. Especially when I don't even boot gentoo on a weekly basis.

Several things that are close to a given for i686 and (mainly) amd64 in terms of support for desktop/workstation features are progressively decaying for several other arches, inclusive to 32-bit ppc since its importance in the embedded market has overthrown its desktop use long ago, this is reflected on the linux kernel. I prefer to think things in the "it doesn't work, that was possibly to expect" way than "Crap, nothing does work". It's nice when things occasionally go smoothly, though.

 

[macgeek18]

I would love Linux on my PB G4 12". I may have to try it out and see if I can replace my X61 Thinkpad with the PB.

 

[AphoticD]

I would love Linux on my PB G4 12". I may have to try it out and see if I can replace my X61 Thinkpad with the PB.

I was able to get Ubuntu Mate 16.04 installed and working on my PB 12", but I found it ran much hotter than Leopard or Tiger. It seems like Linux can't quite match Apple's thermal management for the PowerBook G4s, plus the trackpad response is all weird. Just a heads up of course, it is definitely worth a try and ymmv.

Maybe Debian would be a good choice for PowerPC portables?

 

[Dronecatcher]

Maybe Debian would be a good choice for PowerPC portables?

My experience with Debian was it still couldn't cope with the later Powerbook trackpad - tracking far too vague, really kills the experience when you're labouring just to click on something!