Mac OS 9 booting on: Mac mini G4 (Detailed Posts)

[macStuff]

pretty sure if it was solved we would all be well-aware of the big news.

[MacTron]

the ppc mac mini?? its basically like an MDD in a smaller box minus the windtunnel + minus about 100lbs!!

The PPC Mac Mini is basically an "iBook in a Box"

http://www.everymac.com/systems/apple/mac_mini/specs/mac_mini_g4_1.42.html

You still trust this web ? LOL

[ELN]

I have at long long last reversed the 68k code that the mini crashes on. But I can't get my hands on one for a reasonable price to start testing. Does anyone in Australia have one that they could send my way?

[Philgood]

Get together !
ELN has to be helped! !!!

[ELN]

While the Trampoline bootloader and the NanoKernel start just fine on the mini, the 68k Start Manager subsequently hangs. I want to know exactly where and why. Now Nanopico and I have successfully tested patching the 68k ROM to print some debug output via the NanoKernel window.

Here is a ROM with about 30 debug messages inserted into the StartMgr. Would a few people mind testing this on a mini and posting a photo of the debug output? No Open Firmware commands should be required. Just boot from a FireWire drive, or a Mac in Target Disk Mode.

For comparison, here some abridged NK log output from a booting Mac:

Code: [Select]

...
Reset system - Into the 68K fire: 0002d032 6806c9e8
 VMAllocateMemory - creating area at 0x69000000 00080000
 CreateArea [ 69000000 6907ffff ] ID 00170001 placed ... created
*68k: initGestalt
*68k: FiddleWithEmulator
*68k: InitIntHandler
*68k: InitRSRCMgr
*68k: INTERC_1690_CODEREGISTER
*68k: INTERC_15C0_CODEPREPARE2
*68k: EXPANSIONBUSMGRFIRSTFUNC
Extend free pool: phys 0x7ff2d000  virt 0x00000000  count: 1
*68k: INTERC_2A80_ETHERPRINTFLIB
*68k: ENABLEONESECINTS
*68k: ENABLE60HZINTS
*68k: RSETKMAP
*68k: INTERC_2BC0_DEBUGPRINT
*68k: INITDEVICEDISPATCH
*68k: INITSCSIMGR
*68k: INITEXPANSIONMGR
*68k: INTERC_1980_DRIVERS
*68k: INITADB
*68k: INTERC_1910_USBFAMILYEXPERTLIB
*68k: INITBCSCREEN
*68k: TEGLOBALINIT
*68k: ENABLESLOTINTS
*68k: INITFASTERINVALS
*68k: INTERC_2780_FIREWIRE
*68k: INTERC_2A20_SCSITARGETMODE
*68k: INITSCSIBOOT
*68k: ATAMGR_5DAE0
*68k: ATAMGR_5DDE0
*68k: FINDSTARTUPDEVICE
...


[nanopico]

Initial output from the latest ROM.
It does in fact require OF commands to boot

These may seem very familiar

Code: [Select]

dev /
" PowerMac 10,1" encode-string " MacRISC3" encode-string encode+ " MacRISC" encode-string encode+ " Power Macintosh" encode-string encode+ " compatibility" property

dev /cpus/PowerPC,G4
80010201 encode-int " cpu-version" property

So here's the thing now. And this is probably going to put a huge wall in the way.
So going through this, I realized something and did some checking.
The one thing that the other G4 systems have that the mini does not is ADB.
Yes there are no physical connectors on anything past the B&W G3 but, they all have a virtual bus via the PMU that is mapped from the usb ports.  I have suspected the PMU in the mini (being the only one that is not used in any other G4) would be a problem.  The mini has no ADB emulation in it at all so the 68K emulator and other managers will choke because they will not be able to find it.  There was a reason the virtual bus was there and it was exactly to support anything older than OS X which does not require this.  The G5's will sit in the exact same position as well.
So ultimately the mini is the first system that was really OS X only. 
Now this doesn't mean we can't work around it, but we are now talking about firmware level virtual device drivers. 

So long story short, I wouldn't hold your breath on the mini (i have been wrong before so don't hold me to this) as it would probably be a while before there is any possibility that it could boot and run.

[ELN]

The code being executed, sans hacky debug code: https://github.com/elliotnunn/mac-rom/blame/master/OS/StartMgr/StartInit.a

[Daniel]

Later stages of boot can handle usb devices from pci cards not integrated with the PMU, right? What happens if we patch the ADB manager to always report that there are 0 adb devices connected?

[nanopico]

Later stages of boot can handle usb devices from pci cards not integrated with the PMU, right? What happens if we patch the ADB manager to always report that there are 0 adb devices connected?

Yes and no.
No devices are required to be present, but the bus is expected to be.
I believe (and I could be very wrong on this one) the ADB manager would also need to be patched to not check for the bus and implement a sudo/virtual bus.  There would be the Start Manager as well which is apparently checking for the bus.

[Daniel]

Looking at the code, the routine InitADB (in ADBMgr.a ) loads a routine from the function table ProductInfo.ADBDebugUtilPtr. The ProductInfo structure appears to contain important info that can vary between machines. So we would have to look at the ADB routines for a few machines to write do-nothing versions of all relevent routines. Then we can create a ProductInfo structure for the Mac Mini (and possibly other machines).

Does the 9serve have ADB? I see no reason why Apple would put ADB emulation in it.

[nanopico]

Looking at the code, the routine InitADB (in ADBMgr.a ) loads a routine from the function table ProductInfo.ADBDebugUtilPtr. The ProductInfo structure appears to contain important info that can vary between machines. So we would have to look at the ADB routines for a few machines to write do-nothing versions of all relevent routines. Then we can create a ProductInfo structure for the Mac Mini (and possibly other machines).

Does the 9serve have ADB? I see no reason why Apple would put ADB emulation in it.

I'm thinking along the same line so we are on the same page.
The other machines all use a PMU that is used in at least one supported machine. So it wouldn't be a matter of adding it if it's not needed. It's just a mater of using the same chip.
The interesting thing is that i have not seen the mini's PMU used in anything else.

[MacOS Plus]

Does the 9serve have ADB? I see no reason why Apple would put ADB emulation in it.

  Is there any way I can test for this on mine?  There may be a chance it was part of the Rev.1 motherboard and left out of the subsequent revisions.  I can at least check the Rev.1 for you.  The working theory in discussion here suggests that it would have it since it will boot OS 9 with minor help.  (I still remain suspicious that the Rev.1 machine had the FW800 parts omitted from the component pads as part of a halted plan to support OS9.  We'll probably never know for sure.  There's so little that doesn't work on OS 9 with it.  You may have read my recent post about the serial port - http://macos9lives.com/smforum/index.php/topic,3902.0.html)

[Daniel]

Does the 9serve have ADB? I see no reason why Apple would put ADB emulation in it.

  Is there any way I can test for this on mine?  There may be a chance it was part of the Rev.1 motherboard and left out of the subsequent revisions.  I can at least check the Rev.1 for you.  The working theory in discussion here suggests that it would have it since it will boot OS 9 with minor help.  (I still remain suspicious that the Rev.1 machine had the FW800 parts omitted from the component pads as part of a halted plan to support OS9.  We'll probably never know for sure.  There's so little that doesn't work on OS 9 with it.  You may have read my recent post about the serial port - http://macos9lives.com/smforum/index.php/topic,3902.0.html)

Probably not. I have no clue how to check the type of PMU and what firmware is on it.

As for designing it to work with OS 9, that could be why they didn't use a new PMU chip. After they decided OS9 shouldn't work on it they probably just kept the same PMU.

[nanopico]

Does the 9serve have ADB? I see no reason why Apple would put ADB emulation in it.

  Is there any way I can test for this on mine?  There may be a chance it was part of the Rev.1 motherboard and left out of the subsequent revisions.  I can at least check the Rev.1 for you.  The working theory in discussion here suggests that it would have it since it will boot OS 9 with minor help.  (I still remain suspicious that the Rev.1 machine had the FW800 parts omitted from the component pads as part of a halted plan to support OS9.  We'll probably never know for sure.  There's so little that doesn't work on OS 9 with it.  You may have read my recent post about the serial port - http://macos9lives.com/smforum/index.php/topic,3902.0.html)

Probably not. I have no clue how to check the type of PMU and what firmware is on it.

As for designing it to work with OS 9, that could be why they didn't use a new PMU chip. After they decided OS9 shouldn't work on it they probably just kept the same PMU.

Apple's tech notes and developer documentation outlines chips used on all the PPC machines (well almost all of them).
I had create a spreadsheet that outlined all of this. I can't find the thread/post regarding that. (Hint if anyone else can find it can you post a link?)
So know the chips used in all the machines is fairly easy.

As for determining which one.
Go into open firmware and list all the devices.  In there you will see a virtual bus (I can't remember the name off the top of my head). I did just check the iMac I have here at work and it does not list it, but it does list a pseudo-hid with the same devices I saw in the virtual bus.  So you can look for both of those.

[ELN]

Looking for this?

https://github.com/elliotnunn/toolboxtoolbox/wiki/Custom-IC-Chips-Used-in-G3's-and-G4's

Anyone keen to test this ROM build out? It will tell us where the mini is crashing with better resolution than before. I want to know this before I take a deep dive into the Expansion Bus Mgr. Some reference output:

Code: [Select]

Reset system - Into the 68K fire: 0002d032 6806c9e8
 VMAllocateMemory - creating area at 0x69000000 00080000
 CreateArea [ 69000000 6907ffff ] ID 00170001 placed ... created
*68k: EXPANSIONBUSMGRFIRSTFUNC
*68k: InterC_2560
*68k: InterC_2090_PowerMgr


[MacOS Plus]

The complete OF device tree for the Xserve Rev.1 can be viewed in an older post of mine here:

http://macos9lives.com/smforum/index.php/topic,1964.msg20383.html#msg20383

The block diagram shown in the following post indicates PMU99, same as every other G4 machine in ELN's linked table:

http://macos9lives.com/smforum/index.php/topic,1964.msg9985.html#msg9985

[nanopico]

Looking for this?

https://github.com/elliotnunn/toolboxtoolbox/wiki/Custom-IC-Chips-Used-in-G3's-and-G4's

Anyone keen to test this ROM build out? It will tell us where the mini is crashing with better resolution than before. I want to know this before I take a deep dive into the Expansion Bus Mgr. Some reference output:

Code: [Select]

Reset system - Into the 68K fire: 0002d032 6806c9e8
 VMAllocateMemory - creating area at 0x69000000 00080000
 CreateArea [ 69000000 6907ffff ] ID 00170001 placed ... created
*68k: EXPANSIONBUSMGRFIRSTFUNC
*68k: InterC_2560
*68k: InterC_2090_PowerMgr


Yup that is the one I put together.

[nanopico]

Results. Fyi for those trying.
Uh ou still need to change the compatible property to boot.

[ELN]

Oh darn. It is definitely hanging on EXPANSIONBUSMGRFIRSTFUNC (my name). I'll start poking into the Expansion Bus Mgr. Unfortunately, there is no "System 7.1" source to compare it to. But the ExpansionBusDispatch trap will be a good starting point.

[nanopico]

As I have two G4 mini's I'm more than willing to fuck with OpenFirmware on one and only one in the event I brick it like has happened in the past.