Mac OS 9 Lives

Classic Mac OS Hardware => Mac OS 9 on Unsupported Hardware => Topic started by: teroyk on May 31, 2020, 10:20:30 AM

Title: G5 boot test reports and how we should prepare tests
Post by: teroyk on May 31, 2020, 10:20:30 AM
Yes, I know that it is little stupid dream that G5 can boot to Mac OS 9 ever, but...

...are there anybody even tested to boot the first G5 model with Mac OS 9 compatible AGP-card?
I think boot have to do from firewire-drive. Should machine have less than 2 GB memory?
Tester should have some skills to debug where boot stops. Or should first test machine be Xserve G5 cluster node and debug through RS-232?
Can Mac OS 9 boot without graphics-card?

BTW. I find information about IDE/SATA-card that is Mac OS 9 and also PCI-X (for G5) compatible:
http://www.macsense.com/product/storage/sua-100e.html
Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on May 31, 2020, 11:12:39 AM
I think boot have to do from firewire-drive.

sounds the safest for now.

Quote
Should machine have less than 2 GB memory?

i´d guess no. in a G4 it is fine with 2GB istalled, it just ignores the excess.

Quote
Or should first test machine be Xserve G5 cluster node and debug through RS-232?

no idea if a console could tell more than other forms of debugging - or if a console will get any kind of output at all from a non posix OS.

but i think the cluster node would be the coolest machine of all for audio applications or as render server. :)

Quote
Can Mac OS 9 boot without graphics-card?

yes. though i am not sure if this does not eventually depends on the hardware, too. an intel core2duo macmini for example can not boot headless without some trickery at the dvi port. (or at least you can not set a resolution)

i dont find it back, but someone who knows more already explained somewhere that the main issue is that a G5 processor simply has a completely different type of instruction set, so that you basically would have rewrite literally everything.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on May 31, 2020, 12:52:47 PM
i dont find it back, but someone who knows more already explained somewhere that the main issue is that a G5 processor simply has a completely different type of instruction set, so that you basically would have rewrite literally everything.

Actually that cannot be true, because then any of G3/G4  Mac OSX programs cannot work in G5 (or of course in emulation they can work). There can be lot of difference and they can trapped with illegal instruction traps, but still it cannot be completely different type of instruction set.

I have to check it... ...I made fast reading "PowerPC® Microprocessor Family:The Programming Environments Manual for 32 and 64-bit Microprocessors" and I found:
"
An operating system that uses the bridge features does not take full advantage of the 64-bit implementation (for example, it can generate only 32-bit effective addresses).
An operating system that uses the 64-bit bridge architecture should observe the following:
The boot process should do the following: – ClearMSR[SF]. – Initialize the ASR, clearing ASR[V]. – Invalidate all SLB entries.
The operating system should do the following:
– Support only 32-bit applications.
– If any 64-bit instructions are used for example,to modify a PTE or a 64-bi tSPR,en sure either that exceptions cannot occur or that the exception handler saves and restores all 64 bits of the GPRs.
...
"
and some things more, that is not problem. It might be that G5 ROM-boot code start reading disks in 32-bit mode, so it might that bridge feature is default in start.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Protools5LEGuy on May 31, 2020, 01:08:12 PM
For G5 to boot Mac OS 9 there also is needed an Little Endian/ Big Endian converter/wrapper written in openfirmware or Forth or Pascal I guess.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on May 31, 2020, 01:12:13 PM
For G5 to boot Mac OS 9 there also is needed an Little Endian/ Big Endian converter/wrapper written in openfirmware or Forth or Pascal I guess.

Why? G5 is Big Endian too like almost all processor except Z80 and x86.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Protools5LEGuy on May 31, 2020, 03:43:47 PM
You can be sure that I am not an expert on the subject, but I listened somewhere that the way G3 and G4 handle "Code" is different than G5 in that Little Endian/Big Endian Game.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Jubadub on May 31, 2020, 03:58:22 PM
You can be sure that I am not an expert on the subject, but I listened somewhere that the way G3 and G4 handle "Code" is different than G5 in that Little Endian/Big Endian Game.

AFAIK, that's only for virtual machine programs, which make use of endianness switching. G5 can't switch endianness like that (which is why, at same clock speeds etc., VirtualPC is slower on G5s), but that's about it.

In regards to Instruction Set Architecture (ISA), there are no concerns, as well, as the G5 contains a superset of earlier ISA implementations of earlier PPC processors. (Not too many new functions, though.) That's what the IBM docs reveal, anyway, last I checked.

Above all, to my knowledge, the main issue with the G5 is "mere" lack of drivers. Not sure which, though. Motherboard(s)? NorthBridge? G5 CPU recognition itself (just like how OS 8.6 doesn't recognize most G4s, supposedly)?

Anyway, I'm no expert, either. But looking at how other systems (GNU/Linux, BSD, MorphOS) boot into both G4s and G5s, they might be a good start. Also, starting with earlier G5s certainly sounds much wiser than with late G5s, that's for sure.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on May 31, 2020, 07:08:13 PM
funfact: if altivec stuff is run as altivec, it will run slower than on the G4 processor.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Jubadub on June 01, 2020, 02:17:44 AM
funfact: if altivec stuff is run as altivec, it will run slower than on the G4 processor.

At least in comparable configurations, yes (same clock, L2 cache etc.). Else, the G5 outperforms G4 simply due to sheer bruteness.

This means a 7448 G4 overclocked to 2.4 GHz (with some epic cooling solution) would outperform any G5 for AltiVec operations (unless if it's the Quad G5 and the app uses either 3 or 4 cores).
If only the 7448 upgrade was easy to find, and brand-new 7448s affordable...
Probably "easier" to just get OS 9 on G5s already. :P Then Talos.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: MacTron on June 01, 2020, 01:03:57 PM
The main issues to boot Mac Os 9 into a G5 Mac are the motherboard components that Mac Os 9 has no drivers for. The U3 and PCIe just to start with ...
Title: Re: G5 boot test reports and how we should prepare tests
Post by: darthnVader on June 02, 2020, 04:45:42 AM
The main issues to boot Mac Os 9 into a G5 Mac are the motherboard components that Mac Os 9 has no drivers for. The U3 and PCIe just to start with ...

I got the nano kernel log in qemu with kvm and mac99 machine model, but things halt there.

So the G5 cpu is still and issue, likely the lack of BATT registers.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 02, 2020, 08:56:03 AM
The main issues to boot Mac Os 9 into a G5 Mac are the motherboard components that Mac Os 9 has no drivers for. The U3 and PCIe just to start with ...
So the G5 cpu is still and issue, likely the lack of BATT registers.

But I don't mean last G5s with PCIe. I talking about first G5s with AGP and PCI-X. Of course there isn't drivers for motherboard components or is there in something usefull its 1 MB ROM or 3 MB toolbox ROM loaded into RAM?

Oh..it just read just before that I copy paste from PowerPC® Microprocessor Family: The Programming Environments Manual for 32 and 64-bit Microprocessors  :-[
"The bridge features do not conceal the differences in format of the page table, BAT registers, and SDR1 between 32-bit and 64-bit implementations—the operating system must be converted explicitly to use the 64-bit formats."
Good think that manual also says, when talking about BAT:s and memorymanagement: "However, if these features are not supported, attempting to execute these instructions on a 64-bit implementation causes an illegal instruction program exception." so you can catch that and make emulation.
Strange thing is that PowerPC® Microprocessor Family: The Programmer’s Reference Guide from 1995 (from PowerPC 60x age) at page 20 shows 32-bit and 64-bit BAT registers.

Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on June 02, 2020, 11:56:11 AM
the operating system must be converted explicitly to use the 64-bit formats."

hm, and then RAM, next problem.

Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 03, 2020, 12:04:44 AM
the operating system must be converted explicitly to use the 64-bit formats."
hm, and then RAM, next problem.

Actually when using that that bridge feature then RAM isn't problem.
I think Mac OS 9 doesn't try write over 4 GB memory not even 2 GB ;)
More problem comes using virtual memory, but we shut off it anyway.

Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 03, 2020, 10:06:17 AM
BTW. Apple Hardware Test (v2.1.0) for first G5 looks like so Mac OS 9 style:
(removed look under why)
EDIT: and nice picture when running Apple Hardware Test v.2.2.5 with Powermac G4 with 3 GB RAM:
(removed look under why)
EDIT2:  :-[ I remove links, look under why
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Protools5LEGuy on June 03, 2020, 12:23:35 PM
Please, dont use direct "Hot-links" to the garden, or Knezzen will punish you.

It is cool to point to the page, but not cool to link files or pictures.

https://macintoshgarden.org/apps/apple-hardware-test-powermac-g4 (https://macintoshgarden.org/apps/apple-hardware-test-powermac-g4)
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 05, 2020, 08:26:26 AM
Anyway my point with those AHT pictures was that last G4 and first G5 is not so far away that we think, but this is not topic for that,
look this topic if you are interested in more: http://macos9lives.com/smforum/index.php/topic,5537.0.html
Title: Re: G5 boot test reports and how we should prepare tests
Post by: nanopico on June 05, 2020, 12:56:19 PM
I haven't done much with the G5 and OS 9 for a while, but my last attempt I was able to get it fairly far, by disabling a lot of devices in Open Firmware and booting from a CD.  If I remember correctly the point of failure I hit was hardware related as I had disabled so much there was nothing to run the system.   I also recall something with the way the G5 addresses memory even in a 32 bit mode that made OS 9 freak out.

Sorry I can't remember a lot of detail off the top of my head as this was before I had mental breakdown and before I was medicated so I do actually forget some of this stuff and what notes I had got trashed when I was pissed off one evening.    I did find a few tidbits in some backups I was reviewing a couple nights ago.

One thing I do remember for sure was that I got a little over excited about disabling devices in open firmware and almost bricked one of my G5.   I have since acquired a couple extra G5's so I guess I could start poking at this one again.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 06, 2020, 03:47:23 AM
I haven't done much with the G5 and OS 9 for a while, but my last attempt I was able to get it fairly far, by disabling a lot of devices in Open Firmware and booting from a CD.  If I remember correctly the point of failure I hit was hardware related as I had disabled so much there was nothing to run the system.   I also recall something with the way the G5 addresses memory even in a 32 bit mode that made OS 9 freak out.

Do you remember what G5 model it was? I am very sure that booting from CD is not the best device with G5. Firewire might be only possible boot device and that with installed OS. Do you remember how much that G5 had memory? 
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 07, 2020, 02:05:16 AM
The Xserve G5 has a build-to-order option of an ATI RV100 64 MB RAM VGA/PCI graphics card with a VGA connector. The ATI RV100 runs at 64-bit PCI 33 or 66 MHz.

And what else has RV100-chip…ATi Radeon 7000! and that is supported in Mac OS 9!

So can somebody test can you boot Powermac G4 to Mac OS 9 with that card?
or can somebody test can you boot (at least to OSX) Powermac G5 1.6 Ghz with that card?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: darthnVader on June 07, 2020, 12:53:51 PM
The Nano Kernel debugger and message log default to the serial port, but you can get it to also output to the screen, but you have no way to enter the interactive debugger without a serial port.

I think the modem can be put into serial mode for the nano_kernel debugger, but I never figured out how to do that?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: nanopico on June 08, 2020, 10:21:00 AM
I haven't done much with the G5 and OS 9 for a while, but my last attempt I was able to get it fairly far, by disabling a lot of devices in Open Firmware and booting from a CD.  If I remember correctly the point of failure I hit was hardware related as I had disabled so much there was nothing to run the system.   I also recall something with the way the G5 addresses memory even in a 32 bit mode that made OS 9 freak out.

Do you remember what G5 model it was? I am very sure that booting from CD is not the best device with G5. Firewire might be only possible boot device and that with installed OS. Do you remember how much that G5 had memory?

It was a Dual 2.0 GHZ with the 4 memory sockets and PCI-X and it had 2GB of RAM at the time.  it was the only G5 I had at the time.  I know have a 1.6 GHZ PCI G5 which I suspect would be the easiest to get working, but not sure.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 08, 2020, 11:04:37 AM
The Nano Kernel debugger and message log default to the serial port, but you can get it to also output to the screen, but you have no way to enter the interactive debugger without a serial port.

So Xserve G5 2Ghz with serial port will be good choice for debugging. But who has that?
Actually, Powermac G5 1.6Ghz has 56k-modem port, can we change it to serial port?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 08, 2020, 11:33:06 AM
Do you remember what G5 model it was? I am very sure that booting from CD is not the best device with G5. Firewire might be only possible boot device and that with installed OS. Do you remember how much that G5 had memory?

It was a Dual 2.0 GHZ with the 4 memory sockets and PCI-X and it had 2GB of RAM at the time.  it was the only G5 I had at the time.  I know have a 1.6 GHZ PCI G5 which I suspect would be the easiest to get working, but not sure.

Yes 1.6 GHZ PCI would be best. Your setup might have 2 potential problems Dual processor and PCI-X, but I am not 100% sure. Also from IBM PPC Manual "Processors that implement the 64-bit bridge divide the 32-bit address space into sixteen 256-Mbyte segments " so good start would be with one segment, just only 256 MB memory. It also might help that no need for BAT-array(!).
Title: Re: G5 boot test reports and how we should prepare tests
Post by: LarsG5 on June 14, 2020, 03:06:14 PM
No AGP card used in any of the G5 machines is OS9 compatible per se. FX5200 works in a Cube, true, but no 2d/3d acceleration renders it useless anyway. So we would have to resort to PCI video cards, which kinda defeats the whole purpose other than to prove a point...
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 16, 2020, 01:24:34 AM
So we would have to resort to PCI video cards, which kinda defeats the whole purpose other than to prove a point...

But it would be some kind of starting point...
Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on June 16, 2020, 03:52:02 AM
silly qustion but what happens if you put a x4 AGP card in the G5?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: LarsG5 on June 16, 2020, 05:20:05 AM
So we would have to resort to PCI video cards, which kinda defeats the whole purpose other than to prove a point...

But it would be some kind of starting point...

True, but still, it would only be a proof of concept rather than a great breakthrough. Still cool though.

On the other hand, flashing some PC video cards, that are potentially OS9 compatible and use "universal" x4/x8 AGP interface is also an option.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 19, 2020, 12:04:36 PM
silly qustion but what happens if you put a x4 AGP card in the G5?

It's not silly question...has anybody tested?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: LarsG5 on June 19, 2020, 12:50:34 PM
In best case scenario a Mac wouldn't power on, like it happens when you put an x8 card in x4 slot.
In x4 specs, pins 3 and 11 are left unused, but due to power draw of ADC monitors, they decided to supply some additional power via those two pins in x8 specification. Thats why you tape those two ping over when installing an x8 card in an x4 slot - otherwise the machine doesn't power on and simply acts like it's dead.

So yeah, best case scenario: the machine refuses to power on
Worst case scenario: magic blue smoke.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 21, 2020, 12:17:32 AM
So maybe better use PCI for graphics card in the some first tests, but has somebody PowerMac G5 with PCI-slots for test?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: LarsG5 on June 21, 2020, 03:23:20 AM
That's exactly what I pointed out several posts earlier 🤣
It would be just much much easier this way - one less hassle to tackle 🤷🏼‍♂️
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Jubadub on June 22, 2020, 11:45:39 AM
This is a great initiative and pursuit, @teroyk, I'd love to hear more about your attempts and findings. Also, @nanopico, I hope you are doing better by now. And I'm also envious of your G5 collection. :)

So, let's see, to get things started, the ideal setup is:
- 1.6GHz 1st gen single-processor G5;
- A single 256MB RAM stick;
- PCI GPU Card, avoid AGP;
- Booting pre-installed OS 9 via FireWire preferred, at least at first. (Thoughts on USB?)

I was completely unfamiliar about processor-level hardware differences like the BAT registers. Goes to show what I really know about these processors. :) Now I wonder what else might be there that may pose a challenge. At worst, something(s) may have to be emulated or, alternatively, OS 9 itself to be patched.

Also, as I half-jokingly suggest here (http://macos9lives.com/smforum/index.php?topic=5537.msg41383#msg41383), could spoofing machine info (report it as an MDD, G4 processor etc.) have some potential of aiding down the line, I wonder?

So we would have to resort to PCI video cards, which kinda defeats the whole purpose other than to prove a point...

But it would be some kind of starting point...

True, but still, it would only be a proof of concept rather than a great breakthrough. Still cool though.

ROFL, this heavily understates the HUGE breakthrough it would be to boot OS 9 on G5s. 🤣
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 22, 2020, 01:17:21 PM
- A single 256MB RAM stick;

I think memory have to be in pairs with G5 so two 128MB RAM sticks (And if I am right that was the default min. setup for G5 1.6Ghz)

- Booting pre-installed OS 9 via FireWire preferred, at least at first. (Thoughts on USB?)

And maybe via Firewire 800-port, because MDD2003 and some alu-Powerbooks see Firewire 800-port as Firewire 400 port with Mac OS9 and Firewire400 doesn't work, but maybe have to test both.

I was completely unfamiliar about processor-level hardware differences like the BAT registers. Goes to show what I really know about these processors. :) Now I wonder what else might be there that may pose a challenge. At worst, something(s) may have to be emulated or, alternatively, OS 9 itself to be patched.

Actually that BAT-register problem can good thing too, It can be help us to go "G5-side" for debugging time to time and that helps with another problems.

And actually how much Mac OS 9.2.2 use BAT-registers?
Is there little possibility that when Apple prepare for Classic between Mac OS 8.5-9.2.2 they drop use them as much that possible?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: darthnVader on June 23, 2020, 06:31:45 AM
Running Linux with KVM and Qemu will get you a lot further as far as G5 CPU support.

It uses the mac99( G4 AGP Sawtooth ) machine model, so you won't have to go about debugging and disabling all the hardware in the device tree that the Mac OS ROM doesn't know what to do with.

This will allow you to focus on the CPU.

You can check my thread:

http://macos9lives.com/smforum/index.php/topic,4600.msg36426.html#msg36426

I got the nano_kernel boot log, but never debugged any further to see why booting halted at the first line of the log.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 23, 2020, 09:18:47 AM
Running Linux with KVM and Qemu will get you a lot further as far as G5 CPU support.

Yes, but can I emulate with Qemu the Powermac G5 PCI 1.6GHz/256MB  from very beginning from boot from firewire?
And of course that kind of environment can have it's own errors.

I am interested is it started in 64-bit bridge (32-bit compatible) mode ? And what is first thing that crash, is it illegal instruction trap (because use of BAT-register) or what?
If it not start in bridge mode we have to put it in that mode before load OS and maybe setup illegal instruction trap to emulate BATs.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: darthnVader on June 23, 2020, 05:28:30 PM
From what I've read, you have to strip the device tree of major road-blocks like USB, leaving you with no means of I in IO.

I'd assume there could be some way of adding a true serial port to the G5, to overcome the lack of USB, if that's the rout you decide to take, but you are going to strip things way down just to get over the trampoline and to the nonokernel.

At some point you are going to have to go back and rewrite most of the Parcels file drivers, then you'll have to deal with the Mac OS drivers, with, pretty much, no source code.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Jubadub on June 25, 2020, 12:56:36 AM
From what I've read, you have to strip the device tree of major road-blocks like USB, leaving you with no means of I in IO.

I'd assume there could be some way of adding a true serial port to the G5, to overcome the lack of USB, if that's the rout you decide to take, but you are going to strip things way down just to get over the trampoline and to the nonokernel.

At some point you are going to have to go back and rewrite most of the Parcels file drivers, then you'll have to deal with the Mac OS drivers, with, pretty much, no source code.

I'm pretty sure teroyk already knew there will be a rough road ahead. :) The roughness of it will be there regardless of the approach being via QEMU or real G5 hardware, like you pointed out. Disabling stuff just to get to the point it would start from QEMU is a relatively minor point, because that is the "easy" part.

And "no source code" or "pretty much, no source code", not exactly. Again, consulting with/porting over GNU/Linux, BSD and/or even MorphOS drivers & other code for G5s is still a possibility, for anyone serious. (Although even without any source code, it'd still not be impossible, but "just" a lot harder.)

As long as the individual is committed and serious enough about it, there is nothing to stop it from happening. That goes for nearly everyone regarding nearly everything. :)
Title: Re: G5 boot test reports and how we should prepare tests
Post by: darthnVader on June 25, 2020, 04:11:30 AM
From what I've read, you have to strip the device tree of major road-blocks like USB, leaving you with no means of I in IO.

I'd assume there could be some way of adding a true serial port to the G5, to overcome the lack of USB, if that's the rout you decide to take, but you are going to strip things way down just to get over the trampoline and to the nonokernel.

At some point you are going to have to go back and rewrite most of the Parcels file drivers, then you'll have to deal with the Mac OS drivers, with, pretty much, no source code.

I'm pretty sure teroyk already knew there will be a rough road ahead. :) The roughness of it will be there regardless of the approach being via QEMU or real G5 hardware, like you pointed out. Disabling stuff just to get to the point it would start from QEMU is a relatively minor point, because that is the "easy" part.

And "no source code" or "pretty much, no source code", not exactly. Again, consulting with/porting over GNU/Linux, BSD and/or even MorphOS drivers & other code for G5s is still a possibility, for anyone serious. (Although even without any source code, it'd still not be impossible, but "just" a lot harder.)

As long as the individual is committed and serious enough about it, there is nothing to stop it from happening. That goes for nearly everyone regarding nearly everything. :)

Having a working debugger like GDB is pretty much mandatory. 8)
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on June 25, 2020, 12:23:51 PM
Having a working debugger like GDB is pretty much mandatory. 8)

GDB is not option (or is not good debugger anyway (my biased opinion)).

Very beginning of start we have to use Open Firmware debugging, some information might be here: http://www.dialectronics.com/Words/OF_Part_II.shtml
And here some information if somebody want use open firmware debug thru ethernet with telnet connection: https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2023.html
Title: Re: G5 boot test reports and how we should prepare tests
Post by: darthnVader on June 25, 2020, 02:18:12 PM
Having a working debugger like GDB is pretty much mandatory. 8)

GDB is not option (or is not good debugger anyway (my biased opinion)).

Very beginning of start we have to use Open Firmware debugging, some information might be here: http://www.dialectronics.com/Words/OF_Part_II.shtml
And here some information if somebody want use open firmware debug thru ethernet with telnet connection: https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2023.html

I've never been able to get the Nano Kernel log from ethernet in two machine mode, I think it will dump only to serial?

I suppose you maybe, somehow, able to enter into the Nano Kernel interactive debugger, but good luck using it.

By all means, do things the hard way :P
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on July 05, 2020, 04:41:38 AM
I've never been able to get the Nano Kernel log from ethernet in two machine mode, I think it will dump only to serial?
I suppose you maybe, somehow, able to enter into the Nano Kernel interactive debugger, but good luck using it.

By all means, do things the hard way :P

"in this decade and do the other things, not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one we intend to win, and the others, too" J.F.Kennedy
Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on July 05, 2020, 08:00:46 AM
and then he got shot
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on July 06, 2020, 11:18:29 PM
PowerMac G4 developer note from 2003 in page 20:
https://web.archive.org/web/20030701081015/http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G4/PowerMacG4/PowerMacG4.pdf
shows block diagram of Powermac G4 MMD (Firewire800)

Has somebody same kind of block diagram of PowerMac G5 single 1.6 Ghz PCI?

EDIT This file works! is for later G5 single 1.8Ghz PCI model:
http://mirror.informatimago.com/next/developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G5/PowerMacG5_SP/PowerMacG5_SP.pdf
Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on July 07, 2020, 02:50:48 AM
yes, broken.

here is the best place to start

 [[[[[ https://developer.apple.com/library/archive/sitemap.php ]]]]]


.../hardware/developer notes/...

https://developer.apple.com/library/archive/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G5/PowerMacG5_SP/0Preface/Q78_pref.html

Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on July 07, 2020, 03:05:05 AM
https://developer.apple.com/library/archive/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G5/PowerMacG5_SP/0Preface/Q78_pref.html

yes it's for 1.8 Ghz. It seems that it almost more differences between first dual G5 and second single G5 than Powermac G4 dual (firewire800) and first dual G5s.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on July 07, 2020, 04:25:27 AM
oh i missed that and i missed that you already found this exact file under another url. :P

though i would bet that the 1.6 looks the same except for PCI i can not garantee that. (to be exact, i have no clue.)
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on July 07, 2020, 06:29:03 AM
oh i missed that and i missed that you already found this exact file under another url. :P

though i would bet that the 1.6 looks the same except for PCI i can not garantee that. (to be exact, i have no clue.)

You was first I was edit that link when you have posted your links :)
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on July 07, 2020, 08:08:53 AM
If it takes too hard to get memory down to 256 MB, maybe this might help:
Technical Q&A QA1099, Reducing the size of Physical Memory in Open Firmware
https://developer.apple.com/library/archive/qa/qa2001/qa1099.html
go down and there is hint for Mac OS 9 users too.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on July 09, 2020, 09:06:43 AM
First G5s has (P)ATA-interfaces for optical drives. Has anybody try to boot to OSX (or OS 9) with HD from there?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: nanopico on July 10, 2020, 06:48:35 AM
First G5s has (P)ATA-interfaces for optical drives. Has anybody try to boot to OSX (or OS 9) with HD from there?

I do believe all the G5 PowerMacs had PATA for the optical drive.  That was why I had used a custom CD I made to do my tests on my G5 a few years back.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on July 10, 2020, 08:25:13 AM
it is ATA 100 and i see no reason why it wouldnt boot from there when you exchange the optical for a SSD.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: anonymouse on August 29, 2021, 05:56:02 AM
...are there anybody even tested to boot the first G5 model with Mac OS 9 compatible AGP-card?

Would be better boot with Mac OS 9 compatible PCI-card?
There is officially Xserve G5 compatible additional GPU card VillageTronic MDD Pro that has also MacOS9-drivers.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on August 30, 2021, 12:58:41 AM
...are there anybody even tested to boot the first G5 model with Mac OS 9 compatible AGP-card?

Would be better boot with Mac OS 9 compatible PCI-card?
There is officially Xserve G5 compatible additional GPU card VillageTronic MDD Pro that has also MacOS9-drivers.

You mean MPDD Pro?
https://web.archive.org/web/20060721133421/http://www.villagetronic.com/mpdd/mpddpro_appl.html
Title: Re: G5 boot test reports and how we should prepare tests
Post by: anonymouse on August 30, 2021, 05:40:10 AM
You mean MPDD Pro?
https://web.archive.org/web/20060721133421/http://www.villagetronic.com/mpdd/mpddpro_appl.html

Sorry my typo. Yes MPDD Pro. I don't have card or ever seen on, but I think it is secondary display card as VTBook, so it doesn't show anything before extension is loaded. So have to setup Finder menu to 2nd display with another machine. And have to boot machine as without display card. This might not be best option to test, but it might be option.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on November 09, 2023, 06:53:24 AM
Maybe it is time ask again: Has somebody PowerMac G5 1.6 Ghz?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: chrisNova777 on November 12, 2023, 03:47:25 AM
I wouldn't even want a G5 running macos9 even if I could have it.. they take up far too much room + too much power + not enough processing power in return... and bottom line they were engineered to run OS X Panther + Tiger which are fun os to run so just go with it man ;)

they should have just made an ATX form factor Mac. But that what OS X intel hackintoshes are for I guess.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: DieHard on November 12, 2023, 03:03:33 PM
Quote
Yes, I know that it is little stupid dream that G5 can boot to Mac OS 9 ever, but...

I hate to say it, but even though we have made so many advancements in the past, IMO G5 hardware is just never going to yield success when booting to OS9. 

The xServe never got finished and it has way fewer logic board differences (I mean being able to "boot" without most of the hardware working is not really that exciting). I am guessing that even if we get the G5 to boot someday (via some awesome new developement) it will be without any functioning hardware in OS 9.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on November 13, 2023, 06:36:20 AM
Quote
Yes, I know that it is little stupid dream that G5 can boot to Mac OS 9 ever, but...
I am guessing that even if we get the G5 to boot someday (via some awesome new developement) it will be without any functioning hardware in OS 9.

Actually if we get first G5 boot,  it has to see PCI-slots, so hardware in PCI-slots (videocards, soundcards) might work also and as far I know PowerMac G5 1.6Ghz (and only that model) has same PCI-system than PowerMac G4 MDD. Correct me if I am wrong, I haven't seen that model ever, only read some info.

There might be also academic questions..when/where/why MacOS9 boot stops in G5.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Jubadub on November 18, 2023, 08:43:24 PM
@DieHard Even if utterly broken, imagine the excitement of OS 9 booted from a G5. I know I would totally freak out in excitement. Now also consider the XServe G4's availability (and people's general knowledge of their very existence) versus the availability of used G5s, and the amount of attraction such a feat would provide.

If @teroyk gets his hands on an 1.6GHz G5 and try to experiment away, I know I would be excitedly reading about it from the edge of my seat. Just for fun. If @ELN, @nanopico & gang also made a comeback and joined forces, that would be even more exciting, although that might be me asking for too much.

In any case, yeah, I agree with you, we will keep expectations "realistic", but it's still fun to walk the journey. -afro-
Title: Re: G5 boot test reports and how we should prepare tests
Post by: IIO on November 19, 2023, 08:00:21 PM
There might be also academic questions..when/where/why MacOS9 boot stops in G5.

CPU driver? ;)
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Jubadub on November 20, 2023, 06:17:04 AM
There might be also academic questions..when/where/why MacOS9 boot stops in G5.

CPU driver? ;)

Let's find that 1.6GHz G5 and confirm it!
Title: Re: G5 boot test reports and how we should prepare tests
Post by: chokobo on November 20, 2023, 01:53:10 PM
Let's find that 1.6GHz G5 and confirm it!

I have one, but it's currently in pretty deep storage.

(http://)
Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on November 30, 2023, 06:01:03 AM
Let's find that 1.6GHz G5 and confirm it!
I have one, but it's currently in pretty deep storage.

Can you dig it out someday? And take some pictures from inside? And check does it still boot to OSX and check how much memory it has?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: nanopico on December 07, 2023, 12:14:28 PM
I'm trying to go off memory of a few things so bear with me here.
Many of you know I'm not the type to say something is impossible, but the G5 thing would be a tremendous undertaking.

I'll just bring up one point here with the boot code.  The trampoline (second stage boot loader here) loads OS 9 and is the bridge from OpenFirmware to OS 9. (Yes I understand this is not news). 
The equivalent in  OS X is bootx.   I've been disassembling and re-writing the trampoline code over the past few weeks. There are a lot of similarities of bootx and the trampoline code.  Almost to the point where Apple took the trampoline, stripped all code out of it related to parcels and added in code for loading the xnu kernel and called it good (well initially anyway).
So keep that in mind for a moment.
A 64bit PowerPC architecture can run 32bit processes and programs.  When it is run in 32bit mode it still has access to the 64bit address buss and it does some weird things with where it puts stuff regardless of the endianness.   So with the OpenFrimware client interface (used during early boot to transition from OpenFirmware to whatever OS you are starting) there is a specific service provided that takes a 64bit address as a paramter.  This paramter is 64bits regardless if the cpu is 32 or 64 bit.   
To make this service compitble the 64bit address is passed via two 32bit registers. 
Here's the signature from the first available version of bootx
Code: [Select]
CICell Seek(CICell ihandle, long long position)so you have position as a 64bit address;
The method then takes the top half of the address and put it in register GPR7 and the lower half in GPR8 (this is the location where it's expected in call to the open firmware client interface)
So OS X could be booted on a 64bit machine from the get go even if it was only running 32bit code.
No move over to the same function in the trampoline.  It only excepts a 32bit address and always sets the top 32bits to zero.  So GPR7 is always 0
Here's the disassembled code that does this from the trampoline. (sorry I know I'm mixing the c signature above and assembly below)
Code: [Select]
cmpwi          r3, 0                   
beqlr                                   
mflr          r0                       
stw            r0, 8(r1)               
stwu          r1, -0x40(r1)           
addi          r9, r1, 0x38             
mr            r6, r3                   
lwz            r3, -0x1e8(r2)           
mr            r8, r4                   
addi          r3, r3, 0x84
li            r4, 3
li            r5, 1
li            r7, 0 ; r7 is set to zero always this is the upper address
bl            0x20dbec                  ;call openfirmware service "seek"
nop                   
addi          r1, r1, 0x40
lwz            r0, 8(r1)
mtlr          r0
blr

Generally probably not a big deal, but not sure where all the seek method is used and how yet, I would say that there is a reason they fixed this with bootx.
 Sorry maybe I'm rambling, but until we can confidently get the trampoline to complete, then any other thoughts I think are moot at this point.
But again back to the disassembly of the trampoline.  Once i have it ported to c and can compile a bootable system with it then I think we can start thinking about more things and looking at what it might take.

There is also a method loads a lot of cpu properties into a structure to likely hand of to the nanokernel and if a single one is missing it bails immediately.

So okay relevant or not I still think there is a sliver of hope (although just a small sliver)

And I do have a 1.6ghz G5 so I may be able to try some stuff again around the upcoming holidays.  Got some time off work.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: Jubadub on December 09, 2023, 11:24:37 PM
Sorry maybe I'm rambling [...]

Far from it, I loved the insight! It's the sort of post that helps us take an otherwise-unrealistic dream (booting OS 9 on G5 and other 64-bit PPC) towards realized potential in a realistic way (how to get there, what to watch out for, where to start, and what is the current situation now).

The detailed description of the trampoline and how it compares to bootX were both clear and educational.

This may sound like the weirdest question ever, but could we somehow "merge" bootX with the trampoline by hacking bootX in such a way so that once it is done with its job of loading a number of things required for booting, and done preparing a bunch of the data for it, it "passes the batton over" to the trampoline instead of what would normally happen? Or something along those lines? Something like a Frankenstein job between bootX and the trampoline.

It may not be the same as what I posed in my question above, but what I have seen with OS 9 is that if you have a partition OS 9 normally cannot boot with, and you select another partition OS 9 also cannot boot with, you nonetheless can try to boot with one of them, which will then obviously fail, but then the machine tries to seek elsewhere for a valid boot partition, and once it tries to load from the other partition that, by itself, would not boot, it WILL then boot successfully. I saw this happen with the 1.5GHz Mac mini G4 back in 2018, and personally exploited this behavior to get an otherwise-unbootable drive to boot. As if the first attempt loaded some of the data into RAM which, then, was enough for the second attempt to carry things forward with.

By the way, just in case anyone else wants to "join up" and get up to speed with your efforts towards your trampoline pursuits, what tools are you using for inspecting things and writing/assembling/compiling code? MacNosy/MacsBug, ResEdit/Resorcerer, Mac emulators like QEMU/SheepShaver? Retro68 (https://github.com/autc04/Retro68)/MPW/CodeWarrior/Fantasm/Visual Studio Code/VSCodium with PPC (POWER) assembly plug-in (for intelliSense and syntax highlighting)? ELN's many fantastic Mac OS reverse engineering tools with Python 3? Ghidra/Cutter/IDA/radare2/Snowman and/or other disassemblers/decompilers?
Title: Re: G5 boot test reports and how we should prepare tests
Post by: nanopico on December 11, 2023, 06:30:26 AM
This may sound like the weirdest question ever, but could we somehow "merge" bootX with the trampoline by hacking bootX in such a way so that once it is done with its job of loading a number of things required for booting, and done preparing a bunch of the data for it, it "passes the batton over" to the trampoline instead of what would normally happen? Or something along those lines? Something like a Frankenstein job between bootX and the trampoline.

Well I originally thought this may be a workable solution actually as I started down this, but as I got farther in I realized there similarities, but I think enough differences that it might overly complicate things and cause more problems than it solves.

By the way, just in case anyone else wants to "join up" and get up to speed with your efforts towards your trampoline pursuits, what tools are you using for inspecting things and writing/assembling/compiling code? MacNosy/MacsBug, ResEdit/Resorcerer, Mac emulators like QEMU/SheepShaver? Retro68 (https://github.com/autc04/Retro68)/MPW/CodeWarrior/Fantasm/Visual Studio Code/VSCodium with PPC (POWER) assembly plug-in (for intelliSense and syntax highlighting)? ELN's many fantastic Mac OS reverse engineering tools with Python 3? Ghidra/Cutter/IDA/radare2/Snowman and/or other disassemblers/decompilers?

I'm kind of a gluten for punishment so you may find this one out there.  I wrote a disassembler using capstone. 
Then I went through all the code by hand commenting it, and cross referencing references to the data section and I'm manually re-writting every assembly method in c.  Partly because it is the way my brain functions and partly because it forces me to understand every single thing in there.  So the tools are a custom disassembler, a text editor (depending on where I'm working on it it is anything from notepad++, vscode or mpw) a hex editor (again dependent on where I'm working no single one specificly) and then right now the only compiler I've figure out how to easily build it on is gcc.  I'd like to figure out how to compile it in with mrc in mpw eventually but eh.
I like to use hardware for testing so I'll end up testing on hardware when I get far enough. I might try qemu too, but I figure it has to run on hardware eventually, start there.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: ssp3 on December 11, 2023, 07:49:58 AM
I wrote a disassembler using capstone.
Not bad  8)
Quote
 
Then I went through all the code by hand commenting it, and cross referencing references to the data section and I'm manually re-writting every assembly method in c.
Have you tried Hopper? It now supports PPC and it has some sort of pseudo-c decompiler.
Title: Re: G5 boot test reports and how we should prepare tests
Post by: nanopico on December 11, 2023, 08:54:43 AM
Have you tried Hopper? It now supports PPC and it has some sort of pseudo-c decompiler.

No.  Like I said part of this is the way my brain works and using tools like like this makes it more difficult for me to understand the code.  By going through it this way I end up knowing it really well and understanding it.  But that is just me. 

My problem with most decompilers is that if there are no debug symbols then any hints as to method names or variable names is lost so all though you get valid c (or whatever language) you still end up spending a lot of time figuring it out.  So I like to manually walk through it so I understand it and while writing the c I can give things meaningful names so that the c is hopefully easier to read and understand. Just a preference.  I know several people who can use those tools with great success and that's awesome.

Title: Re: G5 boot test reports and how we should prepare tests
Post by: teroyk on December 20, 2023, 04:07:36 AM
What version of "ROM"-file G5 1.6Ghz Recovery disk install to boot drive?