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

[nanopico]

hi, I have next to me MacMini 1.42 with Restore OSX 10.4 and of course Classic enviroment for 9.2.2. 

What will be steps to test/hack it to be able to boot in MacOS9? Anyone got success on MacMini?

Start the mini in target disk mode.  Connect it to a mac that supports OS 9 and boot into that.
Format the mini's disk with the OS 9 drivers.  This will erase everything on the disk.
Do an install of OS 9 with the target being the mini.
Copy ELN's ROM over the existing ROM on the mini.
Reboot the mini.

I assume the ROM posted has the CPU version added and compatible machine check code removed to get it to boot.

[tooloudtoowide]

thx, will do it and will back with results

[ry755]

hi, I have next to me MacMini 1.42 with Restore OSX 10.4 and of course Classic enviroment for 9.2.2. 

What will be steps to test/hack it to be able to boot in MacOS9? Anyone got success on MacMini?

Start the mini in target disk mode.  Connect it to a mac that supports OS 9 and boot into that.
Format the mini's disk with the OS 9 drivers.  This will erase everything on the disk.
Do an install of OS 9 with the target being the mini.
Copy ELN's ROM over the existing ROM on the mini.
Reboot the mini.

I assume the ROM posted has the CPU version added and compatible machine check code removed to get it to boot.

Wait, is this going to actually boot it? Or is this just a test?

[ELN]

It’ll freeze, but the log messages I’ve added will tell us where.

[ry755]

It’ll freeze, but the log messages I’ve added will tell us where.

Ok, I guess I'll try that too. I'll have to image backup the Mini first because I've got a lot of games and stuff installed.

[nanopico]

Enjoy

[nanopico]

Also to boot you do need to set the compatible property in open firmware.
If you don't know, I'll put it here so you don't have to go searching.

Hold command option o f during the start up.
When you get to the prompt type the following.

Code: [Select]

dev /
" MacRISC" encode-string " MacRISC2" encode-string encode+ " Power Macintosh" encode-string encode+ " compatible" property
boot
That is all that is needed..

[ry755]

Also to boot you do need to set the compatible property in open firmware.
If you don't know, I'll put it here so you don't have to go searching.

Hold command option o f during the start up.
When you get to the prompt type the following.

Code: [Select]

dev /
" MacRISC" encode-string " MacRISC2" encode-string encode+ " Power Macintosh" encode-string encode+ " compatible" property
boot
That is all that is needed..

Do I need to do this every time I reboot? Or does it save in the NVRAM or something?

[Daniel]

That particular method of doing it needs to be entered every boot. There are ways of sticking it in the NVRAM.

[ELN]

Thanks for the test, nanopico. And thanks to the other people who have checked in.

Well, I made a mistake here. The function at the start of the Expansion Bus Manager is not crashing. Actually, the crash happens just after that function returns, when moving the stack.

Code: [Select]

            BSR.L   CompBootStackOld
            MOVE.L  A0,SP
            SUBA.W  #BootStackSize,A0
            _SetApplLimit

This is the second time that StartInit moves the stack and sizes the system heap zone (in earlier ROM versions it was done only once). The CompBootStack function got split into two cases. This is my interpretation of that function:

Code: [Select]

;________________________________________________________________________________________
;
; Routine:  CompBootStack 5fa
;
; Inputs:   none
;
; Outputs:  A0  -   location of stack pointer at boot time
;
; Trashes:  D0
;
; Function: computes the boot time stack pointer = sysZone + (BufPtr-sysZone)/2 - space for QD
;________________________________________________________________________________________

CompBootStack
            btst    #$06,$240B
            beq.s   CompBootStackOld
            move.l  #$007EFFE0,A0                   ; 8 M - 64 K - 32 b
            rts

CompBootStackOld
            move.l  BufPtr,d0                       ; get top useable memory
            move.l  sysZone,a0                      ; get start system heap
            sub.l   a0,d0                           ; get (top useable - sys heap start)
            lsr.l   #1,d0                           ; divide by two
            add.l   a0,d0                           ; get sys heap + (top - sysHeap)/2
            sub.w   #BootGlobalsSize,d0             ; leave room for QuickDraw stuff.
            andi.w  #$FFF0,d0                       ; force it to be even                                   <SM81>
            move.l  d0,a0
            rts

Here are two new ROMs to probe the crash site. The first just spams the NK log. The second does the same, while calling CompBootStack instead of CompBootStackOld. Both of these files have their COMPATIBLE field set properly, so you might find them a bit easier to run. Here is some reference output from QEMU with 1.75 GB RAM:

Code: [Select]

Reset system - Into the 68K fire: 0002d032 6806c9e8
 *68k: BufPtr = 5fffc000
 *68k: sysZone = 00002800
 *68k: About to call CompBootStackOld...
       ...which returned 2ffff000
 *68k: Now moving stack to there (eek)...
       ...which didnt crash.
 *68k: Now calling SetApplLimit...
       ...which returned successfully.
 *68k: Pushing on with InterC_2560 (no more log messages)


[Protools5LEGuy]

Cool!

[ELN]

Need testers, guys, or this won't go anywhere. I really think that the mini is going to work!

[MacOS Plus]

  It's killing me that I don't have a Mini to help you out with - I'm getting tempted to buy one only for that reason!  It's my hope that anything learned from the Mini project can help with other issues we're having with various other models.  It sucks that if in the end it didn't succeed, I'd be stuck with just a mediocre OS X machine though.

  BTW, do you expect each variant of the G4 Mini to behave equally?  It was unclear to me from what I've read if there were any significant differences other than the speed.  I would prefer to have the fastest model in the series with the larger video DRAM if it doesn't make any other difference.

[ELN]

I think that the 1.5 GHz "stealth upgrade" with the extra VRAM is just as likely to work as the other models.

[androda]

Tested with both of the ROMs posted above: mini-stack-log-rom.hqx, and mini-stack-patch-rom.hqx

https://imgur.com/a/fX9PE

Sadly, no booting.  But the nanoKernel log output is there.

No useful information was tranferred over the debug telnet socket which I opened just in case.  Both times, this is what was printed out:

parsing <CHRP-BOOT>

evaluating <BOOT-SCRIPT>

Loading ELF
AAPL,debug bit settings (-OR- bits together):
       1   = Print general informative messages.
       2   = Print formatted Mac OS tables (except config/universal info).
       4   = Print formatted config info table.
       8   = Dump Mac OS tables (except config/universal info).
      10   = Print node names while copying the device tree.
      20   = Print property info while copying the device tree.
      40   = Print interrupt-related info.
      80   = Print interrupt tree traversal info.
     100   = Print address resolution info.
     200   = Print NV-RAM info.
     400   = Print Mac OS "universal" info.
     800   = Print "special" node info.
    1000   = Load EtherPrintf utility via parcel for post FCode debugging.
    2000   = Print BOOTP/DHCP/BSDP information.
    4000   = Allocate writable ROM aperture.
    8000   = Mark Toolbox image as non-cacheable.
   10000   = Print parcel info while copying the device tree.
   20000   = Print information on device tree data checksums.
 1000000   = Enable the Nanokernel debugger.
 2000000 * = Display the Nanokernel log during boot.
10000000   = Dont attempt to unhibernate system.
40000000   = Halt after end of FCode (useful if outputting to screen).

[ELN]

Darn. Sorry, I’ve had all sorts of trouble producing a boot script that supports all machines. Nanopico, could you help Androda out?

[nanopico]

Darn. Sorry, I’ve had all sorts of trouble producing a boot script that supports all machines. Nanopico, could you help Androda out?

Sure....

I'm not seeing an issue based on what was posted.

androda are you having any issues booting?

[androda]

I thought the point of running those ROMs was to look at the nanokernel logs.

In both cases, the mini did not boot into OS 9.  It just stopped after printing out those lines to the display. I let it sit for several minutes with no continued booting.

If I've misunderstood something about those ROMs, let me know what I can try next.

[nanopico]

No full boot at the moment.
The image you posted has the output so it was "technically" booting.  BUt crashing hard early on.  This is what we need to get past.

[Protools5LEGuy]

nanopico's 666 post!

 

The number of the beast!

https://www.youtube.com/watch?v=LfrENoTJdo4